根据摩尔定律，计算机的性能将继续飙升，因为计算基础设施的相关成本将随着时间的推移继续下降。具体到CPU，已经从简单的单核系统发展到多核系统，缓存性能也有了飞跃性的提升。随着多核 CPU 的出现，计算机现在可以同时运行多个任务。并且，随着硬件开发的多项提升带来的显着效率提升，软件层面的多线程编程已经成为必然趋势。然而，多线程编程也带来了一些数据安全问题。
随着所有这些趋势的发展，业界已经认识到，当存在安全漏洞时，也必须有相应的防护措施。顺应这种趋势，虚拟“锁”被发明出来，以解决线程的安全问题。在这篇文章中，我们将研究多年来出现的 Java 中几种典型的 JVM 级锁。
1、synchronized
synchronized 关键字是 Java 中经典且非常典型的锁。事实上，它也是最常用的一种。在 JDK 1.6 之前，“synchronized”是一个相当“重量级”的锁。不过随着Java的更新升级，这个锁也在不断的优化。如今，这把锁变得不那么“沉重”了。而且，事实上，在某些场景下，它的性能甚至优于典型的轻量级锁。而且在带有synchronized关键字的方法和代码块中，同一时刻只允许一个线程访问特定的代码段，防止多个线程并发修改同一块数据。
1.1）锁升级
在JDK 1.5（含）之前，synchronized关键字的底层实现比较重，因此被称为“重量级锁”。不过在JDK 1.5之后，对“synchronized”锁进行了各种改进，变得不那么重量级了。因此，实现方法就是锁升级过程。我们先看看JDK 1.5之后“同步”锁是怎么实现的。说到同步锁的原理，首先要了解Java对象在内存中的布局。
如上图所示，创建一个对象后，该对象在JVM HotSpot虚拟机的Java内存中的存储布局可以分为三种。
1）对象头
该区域存储的信息分为两部分。
- 对象本身的运行时数据（MarkWord）：该数据存储hashCode、垃圾收集（GC）世代年龄、锁类型标志、偏向锁线程的ID、指向LockRecord的Compare and Swap（CAS）锁指针的线程，除了其他信息。 synchronized锁的机制与这部分（MarkWord）高度相关。 MarkWord 的最低三位表示锁定状态。对于这三个位，其中一个是偏向锁定位，另外两个是普通锁定位。
- 对象的类指针（Class Pointer）：对象的指针是指向其类元数据的指针。 JVM 使用它来确定实例的类。
2）实例数据区
该区域存放对象的有效信息，如对象中所有字段的内容。
3）对齐填充
JVM HotSpot的实现规定对象的起始地址必须是8字节的整数倍。也就是说，64位操作系统一次读取的数据是64位的整数倍，即8个字节。因此，HotSpot 进行“对齐”以高效地读取对象。如果对象的实际内存大小不是 8 字节的整数倍，HotSpot 会将对象“填充”为 8 字节的整数倍。因此，对齐和填充区域的大小是动态的。
1.2）synchronized锁升级
当线程进入synchronized状态并尝试获取锁时，synchronized锁的升级过程如下。
总结一下，同步锁的升级顺序是：偏向锁>轻量级锁>重量级锁。The detailed triggering of lock upgrade in each step is as follows.
1）Biased Lock：（偏向锁）
在 JDK 1.8 中，默认是轻量级锁。但是，通过设置 -XX:BiasedLockingStartupDelay = 0，在同步对象后立即附加偏向锁。当线程处于偏向锁状态时，MarkWord记录当前线程的ID。
2）Upgrading to the Lightweight Lock：（升级到轻量级锁）
当下一个线程竞争偏向锁时，系统首先检查MarkWord中存储的线程ID是否与本线程的ID一致。如果不是，系统立即撤销偏向锁，升级为轻量级锁。每个线程在自己的线程栈中生成一个LockRecord（LR）。然后，每个线程通过CAS操作（自旋）将锁对象头中的MarkWord设置为指向自己LR的指针。如果一个线程成功设置了MarkWord，那么该线程就获得了锁。因此，为“同步”执行的 CAS 操作是通过 HotSpot 的 bytecodeInterpreter.cpp 文件中的 C++ 代码完成的。
3）Upgrading to the Heavyweight Lock：（升级到重量级锁）
如果锁竞争加剧，比如线程自旋数或者自旋线程数超过了一个阈值，这个阈值是JVM自己控制的，对于1.6以后的JDK版本，锁升级为重量级锁。然后，重量级锁向操作系统申请资源。
同时，该线程也被挂起，进入操作系统内核态的等待队列，等待操作系统对其进行调度，映射回用户态。在重量级锁中，需要从内核态转换到用户态，这个过程需要比较长的时间，这也是它被定性为“重量级”的原因之一。
1.3）其他：
1）可重入性：
synchronized锁内部有一个强制原子性的锁机制，就是可重入锁。当一个线程使用synchronized方法时，会调用该对象的另一个synchronized方法。即线程获得对象锁后，一旦再次请求该对象锁，该线程总能获得该锁。在Java中，线程获取对象锁的操作是基于线程的，而不是基于调用的。
synchrnoized块、语句中所对应的对象头中的MarkWord记录了锁的线程持有者和计数器。当一个线程请求成功后，JVM记录持有锁的线程，并将计数置为1。此时，如果有另一个线程请求锁，则该线程必须等待。
当持有锁的线程再次请求锁时，可以再次获得锁，计数随之递增。当线程退出同步方法或块时，计数会递减。最后，如果计数为 0，则释放锁。
2）Pessimistic Lock (Mutex and Exclusive Lock)：（悲观锁（互斥和排他锁））
synchronized锁是悲观锁，更确切地说是排他锁。换句话说，如果当前线程获得了锁，任何其他需要锁的线程都必须等待。锁竞争继续，直到持有锁的线程释放锁。
2、ReentrantLock
ReentrantLock 和synchronized类似，但其实现方式与同步锁有较大区别。具体来说，它是基于经典的AbstractQueueSyncronized（AQS）实现的。 AQS是基于volatile和CAS实现的。 AQS维护volatile类型的state变量来统计重入锁的重入尝试次数。同样，加锁和释放锁也是基于这个变量。 ReentrantLock提供了一些synchronized锁所没有的额外特性，所以比synchronized锁要好。
2.1）ReentrantLock特性：
1）可重入：
ReentrantLock 和 synchronized 关键字一样，都是支持重入的锁。但是，它们的实现方法略有不同。 ReentrantLock通过AQS的状态来判断资源是否已经被锁定。对于同一个线程，如果被锁定，状态值加1，如果被解锁，状态值减1。注意解锁只对当前独占线程有效，否则会出现异常。如果状态值为0，则解锁成功。
2）手动加锁、解锁：
synchronized 关键字自动锁定和解锁。相比之下，ReentrantLock 需要 lock() 和 unlock() 方法以及 try/finally 语句块来手动锁定和解锁。
3）lock timeout：
synchronized 关键字不能设置锁定超时时间。如果在获取锁的线程中发生死锁，其他线程将保持阻塞状态。 ReentrantLock 提供了 tryLock 方法，可以为获得锁的线程设置超时时间。如果超过超时时间，则跳过该线程，不执行任何操作，从而防止死锁。
4）Fair and Unfair Locks
synchronized 关键字是一种非公平锁，第一个抢到锁的线程先运行。通过在ReentrantLock的构造方法中设置true或false，可以实现公平锁和非公平锁。如果设置为true，线程需要遵循“先到先得”的规则。每次线程要获取锁时，都会构造一个线程节点，然后追加到双向链表的“尾部”进行排队，等待队列中的前一个节点释放锁资源。
5）可中断：
ReentrantLock 中的 lockInterruptibly() 方法允许线程在被阻塞时响应中断。比如线程t1通过lockInterruptibly()方法获得了一个ReentrantLock，运行了一个long task。其他线程可以使用interrupt()方法立即中断线程t1的运行，获得线程t1的ReentrantLock。但是，ReentrantLock的lock()方法或者有synchronized锁的线程是不会响应其他线程的interrupt()方法的，直到这个方法主动释放锁。
2.2）ReentrantReadWriteLock
ReentrantReadWriteLock（读写锁）其实就是两把锁，一把是WriteLock（写锁），一把是ReadLock（读锁）。读写锁的规则是：read-read non-exclusive, read-write exclusive, and write-write exclusive。在一些实际场景中，读的频率远高于写的频率。如果使用普通锁进行并发控制，读写互斥，效率低下。
为了优化这种场景下的运行效率，读写锁应运而生。总的来说，独占锁的低效率来源于高并发下临界区的激烈竞争，导致线程上下文切换。当并发不是很高的时候，读写锁的效率可能会低于排他锁，因为需要额外维护。因此，您需要根据实际情况选择合适的锁具。
ReentrantReadWriteLock也是基于AQS实现的。 ReentrantLock 和 ReentrantReadWriteLock 的区别在于后者具有共享锁和排它锁的属性。读写锁中的加锁和解锁是基于Sync的，继承自AQS。主要由AQS中的state和node中的waitState变量实现。
读写锁的实现与普通互斥锁的主要区别在于需要分别记录读锁状态和写锁状态，等待队列需要区别对待这两种锁操作。在ReentrantReadWriteLock中，AQS中的int型状态分为高16位和低16位分别记录读锁和写锁状态，如下图。
1）The WriteLock (Write Lock) Is a Pessimistic Lock (Exclusive Lock or Mutex)
通过计算state&((1<<16)-1)，将state的高16位全部擦除。因此，状态的低位记录了写锁的重入次数。
下面是获取写锁的源码。
/**
* 获取写锁
Acquires the write lock.
* 如果此时没有任何线程持有写锁或者读锁，那么当前线程执行CAS操作更新status，
* 若更新成功，则设置读锁重入次数为1，并立即返回
* <p>Acquires the write lock if neither the read nor write lock
* are held by another thread
* and returns immediately, setting the write lock hold count to
* one.
* 如果当前线程已经持有该写锁，那么将写锁持有次数设置为1，并立即返回
* <p>If the current thread already holds the write lock then the
* hold count is incremented by one and the method returns
* immediately.
* 如果该锁已经被另外一个线程持有，那么停止该线程的CPU调度并进入休眠状态，
* 直到该写锁被释放，且成功将写锁持有次数设置为1才表示获取写锁成功
* <p>If the lock is held by another thread then the current
* thread becomes disabled for thread scheduling purposes and
* lies dormant until the write lock has been acquired, at which
* time the write lock hold count is set to one.
*/
public void lock() {
sync.acquire(1);
}
/**
* 该方法为以独占模式获取锁，忽略中断
* 如果调用一次该"tryAcquire"方法更新status成功，则直接返回，代表抢锁成功
* 否则，将会进入同步队列等待，不断执行"tryAcquire"方法尝试CAS更新status状态，直到成功抢到锁
* 其中"tryAcquire"方法在NonfairSync(公平锁)中和FairSync(非公平锁)中都有各自的实现
*
* Acquires in exclusive mode, ignoring interrupts. Implemented
* by invoking at least once {@link #tryAcquire},
* returning on success. Otherwise the thread is queued, possibly
* repeatedly blocking and unblocking, invoking {@link
* #tryAcquire} until success. This method can be used
* to implement method {@link Lock#lock}.
*
* @param arg the acquire argument. This value is conveyed to
* {@link #tryAcquire} but is otherwise uninterpreted and
* can represent anything you like.
*/
public final void acquire(int arg) {
if (!tryAcquire(arg) &&
acquireQueued(addWaiter(Node.EXCLUSIVE), arg))
selfInterrupt();
}
protected final boolean tryAcquire(int acquires) {
/*
* Walkthrough:
* 1、如果读写锁的计数不为0，且持有锁的线程不是当前线程，则返回false
* 1. If read count nonzero or write count nonzero
* and owner is a different thread, fail.
* 2、如果持有锁的计数不为0且计数总数超过限定的最大值，也返回false
* 2. If count would saturate, fail. (This can only
* happen if count is already nonzero.)
* 3、如果该锁是可重入或该线程在队列中的策略是允许它尝试抢锁，那么该线程就能获取锁
* 3. Otherwise, this thread is eligible for lock if
* it is either a reentrant acquire or
* queue policy allows it. If so, update state
* and set owner.
*/
Thread current = Thread.currentThread();
//获取读写锁的状态
int c = getState();
//获取该写锁重入的次数
int w = exclusiveCount(c);
//如果读写锁状态不为0，说明已经有其他线程获取了读锁或写锁
if (c != 0) {
//如果写锁重入次数为0，说明有线程获取到读锁，根据"读写锁互斥"原则，返回false
//或者如果写锁重入次数不为0，且获取写锁的线程不是当前线程，根据"写锁独占"原则，返回false
// (Note: if c != 0 and w == 0 then shared count != 0)
if (w == 0 || current != getExclusiveOwnerThread())
return false;
//如果写锁可重入次数超过最大次数（65535），则抛异常
if (w + exclusiveCount(acquires) > MAX_COUNT)
throw new Error("Maximum lock count exceeded");
//到这里说明该线程是重入写锁，更新重入写锁的计数(+1)，返回true
// Reentrant acquire
setState(c + acquires);
return true;
}
//如果读写锁状态为0,说明读锁和写锁都没有被获取，会走下面两个分支：
//如果要阻塞或者执行CAS操作更新读写锁的状态失败，则返回false
//如果不需要阻塞且CAS操作成功，则当前线程成功拿到锁，设置锁的owner为当前线程，返回true
if (writerShouldBlock() ||
!compareAndSetState(c, c + acquires))
return false;
setExclusiveOwnerThread(current);
return true;
}Source code for releasing the write lock:
/*
* Note that tryRelease and tryAcquire can be called by
* Conditions. So it is possible that their arguments contain
* both read and write holds that are all released during a
* condition wait and re-established in tryAcquire.
*/
protected final boolean tryRelease(int releases) {
//若锁的持有者不是当前线程，抛出异常
if (!isHeldExclusively())
throw new IllegalMonitorStateException();
//写锁的可重入计数减掉releases个
int nextc = getState() - releases;
//如果写锁重入计数为0了，则说明写锁被释放了
boolean free = exclusiveCount(nextc) == 0;
if (free)
//若写锁被释放，则将锁的持有者设置为null，进行GC
setExclusiveOwnerThread(null);
//更新写锁的重入计数
setState(nextc);
return free;
}2）The ReadLock (Read Lock) Is a Shared Lock (Optimistic Lock)
通过计算无符号补零的状态>>>16，引入了 16 个附加位。所以state的高位记录了写锁的重入次数。
获取读锁的过程比获取写锁稍微复杂一些。首先系统判断写锁的计数是否为0，当前线程没有持有排他锁。如果是，系统直接返回结果。如果不是，系统检查读线程是否需要阻塞，读锁数量是否小于阈值，设置状态比较是否成功。
如果当前不存在读取锁，则设置第一个读取线程的 firstReader 和 firstReaderHoldCount。如果当前线程是第一个读取线程，则 firstReaderHoldCount 值递增。否则，设置当前线程对应的HoldCounter对象的值。更新成功后，当前线程的重入计数记录在当前线程副本中的firstReaderHoldCount的readHolds（ThreadLocal类型）中。这是为了实现JDK 1.6中新增的getReadHoldCount()方法。该方法可以获得当前线程重新进入共享锁的次数。即状态中记录了多个线程的总重入次数。
引入这个方法让代码复杂了很多，但是原理还是很简单的：如果只有一个线程，则不需要使用ThreadLocal，直接将重入计数存储在firstReaderHoldCount成员变量中即可。当另一个线程发生时，需要使用ThreadLocal变量，readHolds。每个线程都有自己的副本，用来保存自己的重入计数。
下面是获取读锁的源码：
/**
* 获取读锁
* Acquires the read lock.
* 如果写锁未被其他线程持有，执行CAS操作更新status值，获取读锁后立即返回
* <p>Acquires the read lock if the write lock is not held by
* another thread and returns immediately.
*
* 如果写锁被其他线程持有，那么停止该线程的CPU调度并进入休眠状态，直到该读锁被释放
* <p>If the write lock is held by another thread then
* the current thread becomes disabled for thread scheduling
* purposes and lies dormant until the read lock has been acquired.
*/
public void lock() {
sync.acquireShared(1);
}
/**
* 该方法为以共享模式获取读锁，忽略中断
* 如果调用一次该"tryAcquireShared"方法更新status成功，则直接返回，代表抢锁成功
* 否则，将会进入同步队列等待，不断执行"tryAcquireShared"方法尝试CAS更新status状态，直到成功抢到锁
* 其中"tryAcquireShared"方法在NonfairSync(公平锁)中和FairSync(非公平锁)中都有各自的实现
* (看这注释是不是和写锁很对称)
* Acquires in shared mode, ignoring interrupts. Implemented by
* first invoking at least once {@link #tryAcquireShared},
* returning on success. Otherwise the thread is queued, possibly
* repeatedly blocking and unblocking, invoking {@link
* #tryAcquireShared} until success.
*
* @param arg the acquire argument. This value is conveyed to
* {@link #tryAcquireShared} but is otherwise uninterpreted
* and can represent anything you like.
*/
public final void acquireShared(int arg) {
if (tryAcquireShared(arg) < 0)
doAcquireShared(arg);
}
protected final int tryAcquireShared(int unused) {
/*
* Walkthrough:
* 1、如果已经有其他线程获取到了写锁，根据"读写互斥"原则，抢锁失败，返回-1
* 1.If write lock held by another thread, fail.
* 2、如果该线程本身持有写锁，那么看一下是否要readerShouldBlock，如果不需要阻塞，
* 则执行CAS操作更新state和重入计数。
* 这里要注意的是，上面的步骤不检查是否可重入(因为读锁属于共享锁，天生支持可重入)
* 2. Otherwise, this thread is eligible for
* lock wrt state, so ask if it should block
* because of queue policy. If not, try
* to grant by CASing state and updating count.
* Note that step does not check for reentrant
* acquires, which is postponed to full version
* to avoid having to check hold count in
* the more typical non-reentrant case.
* 3、如果因为CAS更新status失败或者重入计数超过最大值导致步骤2执行失败
* 那就进入到fullTryAcquireShared方法进行死循环，直到抢锁成功
* 3. If step 2 fails either because thread
* apparently not eligible or CAS fails or count
* saturated, chain to version with full retry loop.
*/
//当前尝试获取读锁的线程
Thread current = Thread.currentThread();
//获取该读写锁状态
int c = getState();
//如果有线程获取到了写锁 ，且获取写锁的不是当前线程则返回失败
if (exclusiveCount(c) != 0 &&
getExclusiveOwnerThread() != current)
return -1;
//获取读锁的重入计数
int r = sharedCount(c);
//如果读线程不应该被阻塞，且重入计数小于最大值，且CAS执行读锁重入计数+1成功，则执行线程重入的计数加1操作，返回成功
if (!readerShouldBlock() &&
r < MAX_COUNT &&
compareAndSetState(c, c + SHARED_UNIT)) {
//如果还未有线程获取到读锁，则将firstReader设置为当前线程，firstReaderHoldCount设置为1
if (r == 0) {
firstReader = current;
firstReaderHoldCount = 1;
} else if (firstReader == current) {
//如果firstReader是当前线程，则将firstReader的重入计数变量firstReaderHoldCount加1
firstReaderHoldCount++;
} else {
//否则说明有至少两个线程共享读锁，获取共享锁重入计数器HoldCounter
//从HoldCounter中拿到当前线程的线程变量cachedHoldCounter，将此线程的重入计数count加1
HoldCounter rh = cachedHoldCounter;
if (rh == null || rh.tid != getThreadId(current))
cachedHoldCounter = rh = readHolds.get();
else if (rh.count == 0)
readHolds.set(rh);
rh.count++;
}
return 1;
}
//如果上面的if条件有一个都不满足，则进入到这个方法里进行死循环重新获取
return fullTryAcquireShared(current);
}
/**
* 用于处理CAS操作state失败和tryAcquireShared中未执行获取可重入锁动作的full方法(补偿方法？)
* Full version of acquire for reads, that handles CAS misses
* and reentrant reads not dealt with in tryAcquireShared.
*/
final int fullTryAcquireShared(Thread current) {
/*
* 此代码与tryAcquireShared中的代码有部分相似的地方，
* 但总体上更简单，因为不会使tryAcquireShared与重试和延迟读取保持计数之间的复杂判断
* This code is in part redundant with that in
* tryAcquireShared but is simpler overall by not
* complicating tryAcquireShared with interactions between
* retries and lazily reading hold counts.
*/
HoldCounter rh = null;
//死循环
for (;;) {
//获取读写锁状态
int c = getState();
//如果有线程获取到了写锁
if (exclusiveCount(c) != 0) {
//如果获取写锁的线程不是当前线程，返回失败
if (getExclusiveOwnerThread() != current)
return -1;
// else we hold the exclusive lock; blocking here
// would cause deadlock.
} else if (readerShouldBlock()) {//如果没有线程获取到写锁，且读线程要阻塞
// Make sure we're not acquiring read lock reentrantly
//如果当前线程为第一个获取到读锁的线程
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");
//如果执行CAS操作成功将读写锁的重入计数加1，则对当前持有这个共享读锁的线程的重入计数加1，然后返回成功
if (compareAndSetState(c, c + SHARED_UNIT)) {
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;
}
}
}接下来是释放读锁的源码：
/**
* Releases in shared mode. Implemented by unblocking one or more
* threads if {@link #tryReleaseShared} returns true.
*
* @param arg the release argument. This value is conveyed to
* {@link #tryReleaseShared} but is otherwise uninterpreted
* and can represent anything you like.
* @return the value returned from {@link #tryReleaseShared}
*/
public final boolean releaseShared(int arg) {
if (tryReleaseShared(arg)) {//尝试释放一次共享锁计数
doReleaseShared();//真正释放锁
return true;
}
return false;
}
/**
*此方法表示读锁线程释放锁。
*首先判断当前线程是否为第一个读线程firstReader，
*若是，则判断第一个读线程占有的资源数firstReaderHoldCount是否为1，
若是，则设置第一个读线程firstReader为空，否则，将第一个读线程占有的资源数firstReaderHoldCount减1；
若当前线程不是第一个读线程，
那么首先会获取缓存计数器（上一个读锁线程对应的计数器 ），
若计数器为空或者tid不等于当前线程的tid值，则获取当前线程的计数器，
如果计数器的计数count小于等于1，则移除当前线程对应的计数器，
如果计数器的计数count小于等于0，则抛出异常，之后再减少计数即可。
无论何种情况，都会进入死循环，该循环可以确保成功设置状态state
*/
protected final boolean tryReleaseShared(int unused) {
// 获取当前线程
Thread current = Thread.currentThread();
if (firstReader == current) { // 当前线程为第一个读线程
// assert firstReaderHoldCount > 0;
if (firstReaderHoldCount == 1) // 读线程占用的资源数为1
firstReader = null;
else // 减少占用的资源
firstReaderHoldCount--;
} else { // 当前线程不为第一个读线程
// 获取缓存的计数器
HoldCounter rh = cachedHoldCounter;
if (rh == null || rh.tid != getThreadId(current)) // 计数器为空或者计数器的tid不为当前正在运行的线程的tid
// 获取当前线程对应的计数器
rh = readHolds.get();
// 获取计数
int count = rh.count;
if (count <= 1) { // 计数小于等于1
// 移除
readHolds.remove();
if (count <= 0) // 计数小于等于0，抛出异常
throw unmatchedUnlockException();
}
// 减少计数
--rh.count;
}
for (;;) { // 死循环
// 获取状态
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;
}
}
/**真正释放锁
* Release action for shared mode -- signals successor and ensures
* propagation. (Note: For exclusive mode, release just amounts
* to calling unparkSuccessor of head if it needs signal.)
*/
private void doReleaseShared() {
/*
* Ensure that a release propagates, even if there are other
* in-progress acquires/releases. This proceeds in the usual
* way of trying to unparkSuccessor of head if it needs
* signal. But if it does not, status is set to PROPAGATE to
* ensure that upon release, propagation continues.
* Additionally, we must loop in case a new node is added
* while we are doing this. Also, unlike other uses of
* unparkSuccessor, we need to know if CAS to reset status
* fails, if so rechecking.
*/
for (;;) {
Node h = head;
if (h != null && h != tail) {
int ws = h.waitStatus;
if (ws == Node.SIGNAL) {
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;
}
}通过分析可以看出，当一个线程持有读锁时，这个线程是无法获取到写锁的，因为无论是否持有读锁，如果当前读锁被占用，它获取写锁的尝试都会失败通过当前线程。
接下来，当一个线程持有写锁时，该线程可以继续获取读锁。在获取读锁的过程中，如果写锁被占用，只有当前线程占用了写锁，才能获取到读锁。
3、LongAdder
在高并发场景下，直接对Integer类型的整数进行i++并不能保证操作的原子性，导致线程安全问题。为此，我们在juc中使用了AtomicInteger，它是一个提供原子操作的Integer类。在内部，线程安全是通过 CAS 实现的。但是，当大量线程同时访问一个锁时，由于大量线程未能执行CAS操作，就会发生自旋。
导致CPU资源消耗过大，执行效率低下。 Doug Lea 对此并不满意，于是他在 JDK 1.8 中对 CAS 进行了优化，并提供了 LongAdder，它基于 CAS 段锁的思想。
LongAdder是基于CAS和volatile实现的，由Unsafe提供。 LongAdder 的 Striped64 父类中维护了一个基变量和一个Cell数组。当多个线程对一个变量进行操作时，首先对这个基变量进行CAS操作。当检测到其他线程时，将使用元胞数组。例如，当即将更新 base 时，检测到更多的线程。即casBase方法更新基值失败，自动使用cell数组，每个线程对应一个cell，在每个线程中对cell进行CAS操作。
这样就可以在多个值之间分担单个值的更新压力，降低单个值的“热度”。也减少了大量线程的自旋，提高并发效率，分散并发压力。这种段锁需要额外的内存单元，但是在高并发场景下成本几乎可以忽略不计。段锁是一种杰出的优化方法。 juc中的ConcurrentHashMap也是基于段锁来保证读写的线程安全。