java多线程
- 一、java多线程
- 1. JAVA 线程实现/创建方式
- 2.线程的线程生命周期(状态)
- 3.多线程常用的方法
- 4.线程切换
- 5. 线程池
- 5.1jdk创建线程池的方法
- 5.2 拒绝策略
- 二、JAVA 锁
- 1. 锁的分类
- 2. 锁粗化/锁消除
- 三、CAS的主要原理：
- 四、AQS原理
- 1. AbstractQueuedSynchronizer#acquire
- tryAcquire（需各自重写）
- 以java.util.concurrent.locks.ReentrantLock.FairSync#tryAcquire为例
- 以java.util.concurrent.locks.ReentrantReadWriteLock.Sync#tryAcquire为例
- addWaiter
- acquireQueued
- selfInterrupt
- 2. AbstractQueuedSynchronizer#release
- tryRelease （需各自重写）
- unparkSuccessor
- 2. AbstractQueuedSynchronizer#acquireShared
- tryAcquireShared （需各自重写）
- fullTryAcquireShared
- doAcquireShared
- 2. AbstractQueuedSynchronizer#releaseShared
- tryReleaseShared（需各自重写）
- doReleaseShared
- 五、CountDownLatch、CyclicBarrier、Semaphore
一、java多线程
可以多个线程执行一个或者多个不同的任务。
1. JAVA 线程实现/创建方式
实现方式 | 优点 | 缺点 |
extends Thread | 继承了Thread类，就无法再继承其它类 | |
implements Runnable | 可以继承其他类 | 不可以抛出异常，没有返回值 |
implements Callable | 可以抛出异常,通过FutureTask获取到线程是否完成、线程是否取消、线程执行结果，也可以取消线程的执行 |
2.线程的线程生命周期(状态)
- 新建状态（ NEW）
new 一个线程后 - 就绪状态（ RUNNABLE）
调用线程start方法，但是还没有分配CPU 执行 - 运行状态（ RUNNING）
执行run或者call方法时 - 阻塞状态（ BLOCKED）
- 阻塞状态是指线程因为某种原因放弃了 cpu 使用权，暂时停止运行。 等待阻塞（ o.wait->等待对列） ：
- 运行(running)的线程执行 o.wait()方法， JVM 会把该线程放入等待队列(waitting queue) 中。
- 同步阻塞(lock->锁池) 运行(running)的线程在获取对象的同步锁时，若该同步锁被别的线程占用，则 JVM 会把该线 程放入锁池(lock pool)中。 其他阻塞(sleep/join) 运行(running)的线程执行 Thread.sleep(long ms)或 t.join()方法，或者发出了 I/O 请求时， JVM 会把该线程置为阻塞状态。当 sleep()状态超时、join()等待线程终止或者超时、或者 I/O 处理完毕时，线程重新转入可运行(runnable)状态。
- 线程死亡（ DEAD）
- 正常结束
run()或 call()方法执行完成，线程正常结束。- 异常结束
线程抛出一个未捕获的 Exception 或 Error。- 调用 stop
直接调用该线程的 stop()方法来结束该线程—该方法通常容易导致死锁，不推荐使用。
3.多线程常用的方法
Thread.currentThead()获取 当前线程对象
Thread.sleep（）：在指定的毫秒数内让当前正在执行的线程休眠（暂停执行）。休眠的线程进入阻塞状态。
Thread.yield（）：调用yield方法的线程，会礼让其他线程先运行。（大概率其他线程先运行，小概率自己还会运行）
Thread.interrupt()：中断线程
getPriority（）：获取当前线程的优先级
setPriority（）：设置当前线程的优先级
注意：线程优先级高，被CPU调度的概率大，但不代表一定会运行，还有小概率运行优先级低的线程
isAlive（）：判断线程是否处于活动状态 （线程调用start后，即处于活动状态）
join（）：调用join方法的线程强制执行，其他线程处于阻塞状态，等该线程执行完后，其他线程再执行。有可能被外界中断产生InterruptedException 中断异常。wait（）：导致线程等待，进入堵塞状态。该方法要在同步方法或者同步代码块中才使用的
notify（）：唤醒当前线程，进入运行状态。该方法要在同步方法或者同步代码块中才使用的
notifyAll（）：唤醒所有等待的线程。该方法要在同步方法或者同步代码块中才使用的
4.线程切换
5. 线程池
使用线程池最直接的好处就是：线程可以重复利用、减少创建和销毁线程所带来的系统资源的开销，提升性能（节省线程创建的时间开销，使程序响应更快）。
线程池执行
https://www.jianshu.com/p/902933d398cd
5.1jdk创建线程池的方法
方法 | 创建方法 | 参数含义 | 备注 |
Executors. newFixedThreadPool() | 1.创建固定长度线程池，2最多允许存在创建时长度，3使用无边界队列，4使用默认策略 有多的任务被提交过来若等待池满了，则不再加入队列等待（由于使用无界队列，不可能发生）， | ||
Executors. newCachedThreadPool() | 1. 核心线程数为0,2.最多允许Integer.MAX_VALUE线程，3.使用SynchronousQueue阻塞队列（队列中基本不会有数据，一旦存在就好使用以存在线程或者新建线程去运行），4使用默认策略但是由于队列原因不可能触发，6.所有线程若60s 不运行就销毁该线程主线程提交任务速度远远大于CachedThreadPool的处理速度，会不断地创建新线程来执行任务，这样有可能会导致系统耗尽CPU和内存资源 | ||
Executors. newScheduledThreadPool() | —————————————————————————————— | ||
Executors. newSingleThreadExecutor() | 主要为了保证顺序执行，类似newFixedThreadPool(1)，区别在于不可改变大小 |
ThreadPoolExecutor
- int corePoolSize
核心线程池数 keepAliveTime时间后不操作会剩下的线程数
CPU密集型：核心线程数 = CPU核数 + 1
IO密集型：核心线程数 = CPU核数 * 2或者 核心线程数 = CPU核数 / （1-阻塞系数）- int maximumPoolSize
最多的线程数- long keepAliveTime
非核心线程不工作时存活时间（allowCoreThreadTimeOut为true 核心线程也会计算存活时间）- TimeUnit unit
时间单位- BlockingQueue workQueue
缓存队列
- ArrayBlockingQueue
底层采用数组的 有界队列，创建后无法修改队列长度，空队列获取值或者满队列塞值会阻塞- LinkedBlockingDeque
使用链表实现的双向队列- DelayedWorkQueue
优先级队列DelayedWorkQueue，保证添加到队列中的任务，会按照任务的延时时间进行排序，延时时间少的任务首先被获取。- DelayQueue
一个支持延时获取元素的无界阻塞队列。内部用 PriorityQueue 实现- LinkedBlockingQueue
使用链实现的单向队列- PriorityBlockingQueue
按照自己实现的compare优先级排序的队列 PriorityQueue 的线程安全版本，创建指定初始大小会自动扩容，获取空队列时会阻塞- SynchronousQueue
读线程和写线程需要同步，一个读线程匹配一个写线程（写入操作需要等待读取操作才会返回，读取操作同样需要等待写入操作才会返回）。- LinkedTransferQueue
LinkedTransferQueue是 SynchronousQueue 和 LinkedBlockingQueue 的合体，性能比 LinkedBlockingQueue 更高（没有锁操作），比 SynchronousQueue能存储更多的元素
- ThreadFactory threadFactory
创建线程的工厂- RejectedExecutionHandler handler
拒绝策略（线程池满了之后会使用到）
- AbortPolicy
丢弃任务并抛出RejectedExecutionException异常- CallerRunsPolicy
由调用线程处理该任务- DiscardOldestPolicy
丢弃任务，但是不抛出异常- DiscardPolicy
丢弃队列最前面的任务，然后重新提交被拒绝的任务
5.2 拒绝策略
二、JAVA 锁
悲观乐观 | 公平非公平 | 独占共享 | 可重入 | 实现 | |
ReentrantLock | 悲观 | 初始化可配 | 独占 | 可重入 | 依赖AQS和CAS |
ReentrantReadWriteLock | 写悲观读乐观 | 可公平 | 写独享，读共享 | 可重入 | 通过AQS来实现 |
StampedLock | 写读乐观 | 不可重入 | 利用CLH队列进行线程的管理，通过同步状态值来表示锁的状态和类型。 | ||
synchronized | 悲观锁 | 非公平锁 | 独占 | 可重入 | 依赖JVM monitorenter和monitorexit ,ACC_SYNCHRONIZED区分同步块，同步方法 |
1. 锁的分类
产生死锁的必要条件：
- 互斥条件：进程要求对所分配的资源进行排它性控制，即在一段时间内某资源仅为一进程所占用。
- 请求和保持条件：当进程因请求资源而阻塞时，对已获得的资源保持不放。
- 不剥夺条件：进程已获得的资源在未使用完之前，不能剥夺，只能在使用完时由自己释放。
- 环路等待条件：在发生死锁时，必然存在一个进程–资源的环形链。 ||||
悲观锁 | 每次执行前都认为其他线程会修改数据，故会直接上锁，让别人无法操作 | synchronized通过JVM控制实现。 通过AQS和CAS实现 |
乐观锁 | 每次执行前都认为其他线程不会修改数据，故不上锁，等执行后若当前值与（预期值操作前的值）一致则直接更新，不一致则获取最新数据后再次执行 | CAS(Compare And Swap)乐观锁的实现方式之一 |
优点 | 缺点 | |||
公平锁 | 获取不到锁的时候，会自动加入队列，等待线程释放后，队列的第一个线程获取锁 | new Lock实例时可自定义为公平锁 | 所有的线程都能得到资源，不会饿死在队列中 | 吞吐量会下降很多，队列里面除了第一个线程，其他的线程都会阻塞，cpu唤醒阻塞线程的开销会很大 |
非公平锁 | 获取不到锁的时候，会自动加入队列，等待线程释放锁后所有等待的线程同时去竞争 | 1. synchronized非公平锁。 2. new Lock实例时可自定义为公平锁 | 可以减少CPU唤醒线程的开销，整体的吞吐效率会高点，CPU也不必取唤醒所有线程，会减少唤起线程的数量 | 线程饥饿 |
###########优点########### | ###########缺点########### | 原理 | |||
独占锁 | 也叫排他锁，是指该锁一次只能被一个线程所持有 | ReentrantLock ReentrantReadWriteLock中WriteLock | AQS | ||
共享锁 | 可被多个线程所持有 | ReentrantReadWriteLock中ReadLock | 可保证并发读非常高效 | AQS |
###########优点########### | ###########缺点########### | 原理 | |||
可重入锁 | 与多线程并发执行的线程安全不同，可重入强调对单个线程执行时重新进入同一个子程序仍然是安全的 | ReentrantLock和synchronized都是可重入锁 | 一定情况下避免死锁 | 手动开启和释放的次数需要一致 | 每一个锁关联一个线程持有者和计数器，当计数器为 0 时表示该锁没有被任何线程持有，那么任何线程都可能获得该锁而调用相应的方法；当某一线程请求成功后，JVM会记下锁的持有线程，并且将计数器置为 1；此时其它线程请求该锁，则必须等待；而该持有锁的线程如果再次请求这个锁，就可以再次拿到这个锁，同时计数器会递增；当线程退出同步代码块时，计数器会递减，如果计数器为 0，则释放该锁。 |
###########优点########### | ###########缺点########### | 原理 | |||
自旋锁 | 线程执行一个忙循环（自旋）来等待一个即将结束的线程 | atomic包下都通过自选实现 synchronized通过JVM参数可开启自旋 | 避免了线程挂起和再次唤醒的开销 | 可能自旋不成功拜拜浪费空间与时间 | CAS |
自适应自旋 | 尝试一定次数自旋会终止 | 不会无线等待 |
无锁状态 | ||
偏向锁 | Mark Word里面是当前线程的ID或者修改为当前线程id成功 表示当前线程处于偏向锁 | |
轻量级锁 | 修改为当前线程id失败，则说明发生竞争，撤销偏向锁，进而升级为轻量级锁(使用CAS将对象头的Mark Word替换为锁记录指针成功则以成功变为轻量级锁，不成功则进行自旋，如果自旋成功则依然处于轻量级状态。) | |
重量级锁 | 如果自旋失败，则升级为重量级锁。 |
分段锁
分段锁其实是一种锁的设计，并不是具体的一种锁，对于ConcurrentHashMap而言，其并发的实现就是通过分段锁的形式来实现高效的并发操作。我们以ConcurrentHashMap来说一下分段锁的含义以及设计思想，ConcurrentHashMap中的分段锁称为Segment，它即类似于HashMap（JDK7与JDK8中HashMap的实现）的结构，即内部拥有一个Entry数组，数组中的每个元素又是一个链表；同时又是一个ReentrantLock（Segment继承了ReentrantLock)。
当需要put元素的时候，并不是对整个hashmap进行加锁，而是先通过hashcode来知道他要放在那一个分段中，然后对这个分段进行加锁，所以当多线程put的时候，只要不是放在一个分段中，就实现了真正的并行的插入。
但是，在统计size的时候，可就是获取hashmap全局信息的时候，就需要获取所有的分段锁才能统计。分段锁的设计目的是细化锁的粒度，当操作不需要更新整个数组的时候，就仅仅针对数组中的一项进行加锁操作。
2. 锁粗化/锁消除
锁消除是指虚拟机即时编译器在运行时，对一些代码上要求同步，但是被检测到不可能存在共享数据竞争的锁进行消除。锁消除的主要判定依据来源于逃逸分析的数据支持，如果判断在一段代码中，堆上的所有数据都不会逃逸出去从而被其他线程访问到，那就可以把它们当做栈上数据对待，认为它们是线程私有的，同步加锁自然就无须进行。
如果一系列的连续操作都对同一个对象反复加锁和解锁，甚至加锁操作是出现在循环体中的，那即使没有线程竞争，频繁地进行互斥同步操作也会导致不必要的性能损耗。如果虚拟机探测到有这样一串零碎的操作都对同一个对象加锁，将会把加锁同步的范围扩展（粗化）到整个操作序列的外部
检测Mark Word里面是不是当前线程的ID，如果是，表示当前线程处于偏向锁 如果不是，则使用CAS将当前线程的ID替换Mard
Word，如果成功则表示当前线程获得偏向锁，置偏向标志位1 如果失败，则说明发生竞争，撤销偏向锁，进而升级为轻量级锁。
当前线程使用CAS将对象头的Mark Word替换为锁记录指针，如果成功，当前线程获得锁
如果失败，表示其他线程竞争锁，当前线程便尝试使用自旋来获取锁。 如果自旋成功则依然处于轻量级状态。 如果自旋失败，则升级为重量级锁。
三、CAS的主要原理：
- 要借助volatile原语（保证可见性可防止重排序）
- 借助C来调用CPU底层指令实现的。（使用CPU的锁保证原子性）
CAS缺点
- ABA问题。Java 提供了 AtomicStampedReference 工具类，通过为引用建立类似版本号（stamp）的方式，来保证 CAS 的正确性。
- 循环时间长开销大。提供自适应自旋锁，也可以自己控制自旋次数
- 只能保证一个共享变量的原子操作。封装成对象
四、AQS原理
private transient volatile Node head;
private transient volatile Node tail;
//同步状态值state代表获取锁的线程加锁的次数，如果线程获取锁，那么state加1变为1。如果线程释放锁，那么state减1变为0。
private volatile int state;Node 中 的waitStatus
//常量：表示节点的线程是已被取消的
static final int CANCELLED = 1;
//常量：表示当前节点的后继节点的线程需要被唤醒
static final int SIGNAL = -1;
//常量：表示线程正在等待某个条件
static final int CONDITION = -2;
//常量：表示下一个共享模式的节点应该无条件的传播下去
static final int PROPAGATE = -3;1. AbstractQueuedSynchronizer#acquire
public final void acquire(int arg) {
if (!tryAcquire(arg) &&
acquireQueued(addWaiter(Node.EXCLUSIVE), arg))
selfInterrupt();
}tryAcquire（需各自重写）
以java.util.concurrent.locks.ReentrantLock.FairSync#tryAcquire为例
protected final boolean tryAcquire(int acquires) {
final Thread current = Thread.currentThread();
int c = getState();
//无锁
if (c == 0) {
//是否有其他线程正在排队（公平性判断、非公平的不需要hasQueuedPredecessors判断）
if (!hasQueuedPredecessors() &&
compareAndSetState(0, acquires)) {
setExclusiveOwnerThread(current);
return true;
}
}
//如果独占锁的拥有者是自身（重入锁）次数+1
else if (current == getExclusiveOwnerThread()) {
int nextc = c + acquires;
if (nextc < 0)
throw new Error("Maximum lock count exceeded");
setState(nextc);
return true;
}
return false;
}以java.util.concurrent.locks.ReentrantReadWriteLock.Sync#tryAcquire为例
protected final boolean tryAcquire(int acquires) {
Thread current = Thread.currentThread();
int c = getState();
//获取当前写锁的数量
int w = exclusiveCount(c);
//当前同步状态state != 0，说明已经有其他线程获取了读锁或写锁
if (c != 0) {
//如果写锁状态为0说明读锁此时被占用返回false；
//如果写锁状态不为0且写锁没有被当前线程持有返回false
if (w == 0 || current != getExclusiveOwnerThread())
return false;
//判断重入次数是否大于 65535
if (w + exclusiveCount(acquires) > MAX_COUNT)
throw new Error("Maximum lock count exceeded");
// Reentrant acquire
setState(c + acquires);
return true;
}
//是否有线程等待，有则false
//没有线程等待 或者无需等待（非公平锁） 贼cas增加计数
if (writerShouldBlock() ||
!compareAndSetState(c, c + acquires))
return false;
//设置当前线程拥有锁
setExclusiveOwnerThread(current);
return true;
}addWaiter
尝试加锁失败时加入等待
执行完addWaiter后，一定会将当前线程加入到waiter链
private Node addWaiter(Node mode) {
Node node = new Node(Thread.currentThread(), mode);
Node pred = tail;
如果当前waiter链已经有元素
if (pred != null) {
node.prev = pred;
if (compareAndSetTail(pred, node)) {
pred.next = node;
return node;
}
}
//添加元素
enq(node);
return node;
}private Node enq(final Node node) {
for (;;) {
Node t = tail;
if (t == null) { // Must initialize
if (compareAndSetHead(new Node()))
tail = head;
} else {
node.prev = t;
if (compareAndSetTail(t, node)) {
t.next = node;
return t;
}
}
}
}acquireQueued
final boolean acquireQueued(final Node node, int arg) {
boolean failed = true;
try {
boolean interrupted = false;
for (;;) {
final Node p = node.predecessor();
//当前节点的上一节点为头结点且当前节点获取锁成功
if (p == head && tryAcquire(arg)) {
setHead(node);
p.next = null; // help GC
failed = false;
return interrupted;
}
//需要暂停线程；暂停线程并保存中断信号
if (shouldParkAfterFailedAcquire(p, node) &&
parkAndCheckInterrupt())
interrupted = true;
}
} finally {
if (failed)
cancelAcquire(node);
}
}selfInterrupt
2. AbstractQueuedSynchronizer#release
public final boolean release(int arg) {
if (tryRelease(arg)) {
Node h = head;
if (h != null && h.waitStatus != 0)
unparkSuccessor(h);
return true;
}
return false;
}tryRelease （需各自重写）
以Sync为例
protected final boolean tryRelease(int releases) {
int c = getState() - releases;
//线程拥有者不是当前线程 异常
if (Thread.currentThread() != getExclusiveOwnerThread())
throw new IllegalMonitorStateException();
boolean free = false;
//重入为0 时 线程拥有者置为null
if (c == 0) {
free = true;
setExclusiveOwnerThread(null);
}
//设置重入次数，返回是否成功
setState(c);
return free;
}unparkSuccessor
private void unparkSuccessor(Node node) {
int ws = node.waitStatus;
//当前节点状态小于0 则直接设置为0
if (ws < 0)
compareAndSetWaitStatus(node, ws, 0);
Node s = node.next;
//当前节点的后继节点为空或者状态为1时，从尾节点直到到最前面waitStatus<=0的非head Node
if (s == null || s.waitStatus > 0) {
s = null;
for (Node t = tail; t != null && t != node; t = t.prev)
if (t.waitStatus <= 0)
s = t;
}
if (s != null)
LockSupport.unpark(s.thread);
}2. AbstractQueuedSynchronizer#acquireShared
public final void acquireShared(int arg) {
if (tryAcquireShared(arg) < 0)
doAcquireShared(arg);
}tryAcquireShared （需各自重写）
以 ReentrantReadWriteLock.ReadLock
java.util.concurrent.locks.ReentrantReadWriteLock.Sync#tryAcquireShared 为例
（1）获取写状态：S&0x0000FFFF:将高16位全部抹去
（2）获取读状态： S>>>16:无符号补0，右移16位
（3）写状态加1： S+1
（4）读状态加1： S+（1<<16）即S + 0x00010000
protected final int tryAcquireShared(int unused) {
Thread current = Thread.currentThread();
int c = getState();
//写状态不为0 且 当前线程不是锁的持有者 加锁失败
if (exclusiveCount(c) != 0 &&
getExclusiveOwnerThread() != current)
return -1;
//获取读锁
int r = sharedCount(c);
//没有线程等待或者无需等待 且 读锁不超过最大值 且CAS成功
if (!readerShouldBlock() &&
r < MAX_COUNT &&
compareAndSetState(c, c + SHARED_UNIT)) {
//没有读锁
if (r == 0) {
// 设置第一个读线程,占用的资源数为1
firstReader = current;
firstReaderHoldCount = 1;
} else if (firstReader == current) {
//重入线程
firstReaderHoldCount++;
} else {
//其他线程
HoldCounter rh = cachedHoldCounter;
// 计数器为空或者计数器的tid不为当前正在运行的线程的tid
if (rh == null || rh.tid != getThreadId(current))
// 获取当前线程对应的计数器
cachedHoldCounter = rh = readHolds.get();
else if (rh.count == 0)
readHolds.set(rh);
rh.count++;
}
return 1;
}
return fullTryAcquireShared(current);
}fullTryAcquireShared
final int fullTryAcquireShared(Thread current) {
HoldCounter rh = null;
for (;;) {
// 获取状态
int c = getState();
// 写线程数量不为0
if (exclusiveCount(c) != 0) {
// 不为当前线程
if (getExclusiveOwnerThread() != current)
return -1;
}
// 写线程数量为0并且读线程被阻塞
else if (readerShouldBlock()) {
//当前线程是第一个线程
if (firstReader == current) {
// assert firstReaderHoldCount > 0;
}
else {
// 计数器不为空
if (rh == null) {
rh = cachedHoldCounter;
if (rh == null || rh.tid != getThreadId(current)) {
rh = readHolds.get();
if (rh.count == 0)
readHolds.remove();
}
}
if (rh.count == 0)
return -1;
}
}
// 读锁数量为最大值，抛出异常
if (sharedCount(c) == MAX_COUNT)
throw new Error("Maximum lock count exceeded");
// 比较并且设置成功
if (compareAndSetState(c, c + SHARED_UNIT)) {
// 读线程数量为0
if (sharedCount(c) == 0) {
// 设置第一个读线程
firstReader = current;
firstReaderHoldCount = 1;
}
//重入
else if (firstReader == current) {
firstReaderHoldCount++;
}
//设置锁
else {
if (rh == null)
rh = cachedHoldCounter;
if (rh == null || rh.tid != getThreadId(current))
rh = readHolds.get();
else if (rh.count == 0)
readHolds.set(rh);
rh.count++;
cachedHoldCounter = rh; // cache for release
}
return 1;
}
}
}doAcquireShared
private void doAcquireShared(int arg) {
// 增加到链表末尾
final Node node = addWaiter(Node.SHARED);
boolean failed = true;
try {
boolean interrupted = false;
for (;;) {
//获取上一节点
final Node p = node.predecessor();
if (p == head) {
//当前节点的前驱结点获取资源
int r = tryAcquireShared(arg);
if (r >= 0) {
// 前驱节点成功获取到之后 唤醒他之后的节点
setHeadAndPropagate(node, r);
p.next = null; // help GC
if (interrupted)
selfInterrupt();
failed = false;
return;
}
}
//前驱界定啊不是头结点 则进行等待
if (shouldParkAfterFailedAcquire(p, node) &&
parkAndCheckInterrupt())
interrupted = true;
}
} finally {
if (failed)
cancelAcquire(node);
}
}2. AbstractQueuedSynchronizer#releaseShared
public final boolean releaseShared(int arg) {
if (tryReleaseShared(arg)) {
doReleaseShared();
return true;
}
return false;
}tryReleaseShared（需各自重写）
protected final boolean tryReleaseShared(int unused) {
Thread current = Thread.currentThread();
//当前为头结点
if (firstReader == current) {
// assert firstReaderHoldCount > 0;
if (firstReaderHoldCount == 1)
firstReader = null;
else
firstReaderHoldCount--;
}
//非头结点
else {
HoldCounter rh = cachedHoldCounter;
//获取当前线程的计数器
if (rh == null || rh.tid != getThreadId(current))
rh = readHolds.get();
int count = rh.count;
//小于1 删除计数器
if (count <= 1) {
readHolds.remove();
//小于0 提示异常
if (count <= 0)
throw unmatchedUnlockException();
}
//对应计数器减1
--rh.count;
}
for (;;) {
//读锁 总的计数器减1
int c = getState();
int nextc = c - SHARED_UNIT;
if (compareAndSetState(c, nextc))
// Releasing the read lock has no effect on readers,
// but it may allow waiting writers to proceed if
// both read and write locks are now free.
return nextc == 0;
}
}doReleaseShared
private void doReleaseShared() {
for (;;) {
//获取头结点
Node h = head;
if (h != null && h != tail) {
int ws = h.waitStatus;
if (ws == Node.SIGNAL) {
//头结点 状态修改为 0 未成功 则继续循环
if (!compareAndSetWaitStatus(h, Node.SIGNAL, 0))
continue; // loop to recheck cases
//唤醒头节点
unparkSuccessor(h);
}
//
else if (ws == 0 &&
!compareAndSetWaitStatus(h, 0, Node.PROPAGATE))
continue; // loop on failed CAS
}
if (h == head) // loop if head changed
break;
}
}五、CountDownLatch、CyclicBarrier、Semaphore
