深入理解显式锁(Lock)和AQS(AbstractQueuedSynchronizer)（超详细）
显式锁和AQS
- 显式锁
- Lock
- 特性
- 使用范式
- API
- ReentrantLock（可重入锁）
- 锁的可重入
- 锁的公平和非公平
- API
- Condition
- 使用范式
- API
- LockSupport
- CLH(队列锁)
- 原理
- 扩展
- AQS（队列同步器）
- 学习AQS的必要性
- AQS使用方式和其中的设计模式
- 使用方式
- 模板方法模式
- AQS中的方法
- 模板方法
- 可以重写的方法
- 访问或修改同步状态的方法
- AQS中的节点（Node）
- 入队和出队
- 独占式同步状态获取与释放
- 获取
- 释放
- 总结
- 共享式同步状态获取与释放
- Condition的实现
- Lock的实现
- ReentrantLock的实现
- 锁的可重入
- 公平和非公平
- 源码分析
- ReentrantReadWriteLock的实现
- 读写状态的设计
- 写锁的获取与释放
- 锁的升降级
显式锁
Lock
接口，实现类：ReentrantLock ， ReentrantReadWriteLock.ReadLock ， ReentrantReadWriteLock.WriteLock
有了synchronized为什么还要Lock？
Java程序是靠synchronized关键字实现锁功能的，使用synchronized关键字将会隐式地获取锁，但是它将锁的获取和释放固化了，也就是先获取再释放。
特性
- 尝试非阻塞地获取锁：当前线程尝试获取锁，如果这一时刻没有被其他线程获取到，则成果获取并持有。
- 能被中断的获取锁：与synchronized不同，获取到锁的线程能够响应中断，当获取到锁的线程被中断时，中断异常将会被抛出，同事锁会被释放。
- 超时获取锁：在指定的截止时间之前获取锁，如果截止时间到了仍无法获取锁，则返回。
使用范式
Lock lock = ...;
lock.lock();
try{
//业务
}finally{
lock.unlock();
}
在finally块中释放锁，目的是保证在获取到锁之后，最终能够被释放。
不要将获取锁的过程写在try块中，因为如果在获取锁（自定义锁的实现）时发生了异常，异常抛出的同时，也会导致锁无故释放。
API
void lock()
获得锁。
void lockInterruptibly()
获取锁定，除非当前线程是 interrupted 。
Condition newCondition()
返回一个新Condition绑定到该实例Lock实例。
boolean tryLock()
只有在调用时才可以获得锁。
boolean tryLock(long time, TimeUnit unit)
如果在给定的等待时间内是空闲的，并且当前的线程尚未得到 interrupted，则获取该锁。
void unlock()
释放锁。
ReentrantLock（可重入锁）
锁的可重入
简单地讲就是：“同一个线程对于已经获得到的锁，可以多次继续申请到该锁的使用权”。而synchronized关键字隐式的支持重进入，比如一个synchronized修饰的递归方法，在方法执行时，执行线程在获取了锁之后仍能连续多次地获得该锁。ReentrantLock在调用lock()方法时，已经获取到锁的线程，能够再次调用lock()方法获取锁而不被阻塞。
锁的公平和非公平
如果在时间上，先对锁进行获取的请求一定先被满足，那么这个锁是公平的，反之，是不公平的。公平的获取锁，也就是等待时间最长的线程最优先获取锁，也可以说锁获取是顺序的。 ReentrantLock提供了一个构造函数，能够控制锁是否是公平的。事实上，公平的锁机制往往没有非公平的效率高。
在激烈竞争的情况下,非公平锁的性能高于公平锁的性能的一个原因是:在恢复一个被挂起的线程与该线程真正开始运行之间存在着严重的延迟。假设线程A持有一个锁,并且线程B请求这个锁。由于这个锁已被线程A持有,因此B将被挂起。当A释放锁时,B将被唤醒,因此会再次尝试获取锁。与此同时,如果C也请求这个锁,那么C很可能会在B被完全唤醒之前获得、使用以及释放这个锁。这样的情况是一种“双赢”的局面:B获得锁的时刻并没有推迟,C更早地获得了锁,并且吞吐量也获得了提高。
API
构造方法：
ReentrantLock()
创建一个 ReentrantLock的实例。
ReentrantLock(boolean fair)
根据给定的公平政策创建一个 ReentrantLock的实例。
其他方法：
int getHoldCount()
查询当前线程对此锁的暂停数量。
protected Thread getOwner()
返回当前拥有此锁的线程，如果不拥有，则返回 null 。
protected Collection< Thread > getQueuedThreads()
返回包含可能正在等待获取此锁的线程的集合。
int getQueueLength()
返回等待获取此锁的线程数的估计。
protected Collection< Thread > getWaitingThreads(Condition condition)
返回包含可能在与此锁相关联的给定条件下等待的线程的集合。
int getWaitQueueLength(Condition condition)
返回与此锁相关联的给定条件等待的线程数的估计。
boolean hasQueuedThread(Thread thread)
查询给定线程是否等待获取此锁。
boolean hasQueuedThreads()
查询是否有线程正在等待获取此锁。
boolean hasWaiters(Condition condition)
查询任何线程是否等待与此锁相关联的给定条件。
boolean isFair()
如果此锁的公平设置为true，则返回 true 。
boolean isHeldByCurrentThread()
查询此锁是否由当前线程持有。
boolean isLocked()
查询此锁是否由任何线程持有。
void lock()
获得锁。
void lockInterruptibly()
获取锁定，除非当前线程是 interrupted 。
Condition newCondition()
返回Condition用于这种用途实例Lock实例。
String toString()
返回一个标识此锁的字符串以及其锁定状态。
boolean tryLock()
只有在调用时它不被另一个线程占用才能获取锁。
boolean tryLock(long timeout, TimeUnit unit)
如果在给定的等待时间内没有被另一个线程 占用 ，并且当前线程尚未被 保留，则获取该锁（ interrupted） 。
void unlock()
尝试释放此锁。
Condition
接口，实现类：AbstractQueuedLongSynchronizer.ConditionObject ， AbstractQueuedSynchronizer.ConditionObject
任意一个Java对象，都拥有一组监视器方法（定义在java.lang.Object上），主要包括wait()、wait(long timeout)、notify()以及notifyAll()方法，这些方法与synchronized同步关键字配合，可以实现等待/通知模式。Condition接口也提供了类似Object的监视器方法，与Lock配合可以实现等待/通知模式。
使用范式
Lock lock = new ReentrantLock();
Condition condition = lock.newCondition();
public void conditionWait{
lock.lock();
try {
condition.await();
//业务
}finally {
lock.unlock();
}
}
public void conditionSignal{
lock.lock();
try {
//业务
condition.signal();
}finally {
lock.unlock();
}
}
示例：
import java.util.concurrent.locks.Condition;
import java.util.concurrent.locks.Lock;
import java.util.concurrent.locks.ReentrantLock;
/**
*类说明：快递实体类
*/
public class ExpressCond {
public final static String CITY = "ShangHai";
private int km;/*快递运输里程数*/
private String site;/*快递到达地点*/
private Lock kmLock = new ReentrantLock();
private Lock siteLock = new ReentrantLock();
private Condition kmCond = kmLock.newCondition();
private Condition siteCond = siteLock.newCondition();
public ExpressCond(int km, String site) {
this.km = km;
this.site = site;
}
/* 变化公里数，然后通知处于wait状态并需要处理公里数的线程进行业务处理*/
public void changeKm(){
kmLock.lock();
try{
this.km = 101;
kmCond.signal();
}finally {
kmLock.unlock();
}
}
/* 变化地点，然后通知处于wait状态并需要处理地点的线程进行业务处理*/
public void changeSite(){
siteLock.lock();
try {
this.site = "BeiJing";
siteCond.signal();//通知其他在锁上等待的线程
}finally {
siteLock.unlock();
}
}
/*当快递的里程数大于100时更新数据库*/
public void waitKm(){
kmLock.lock();
try{
while(this.km<100){
try {
kmCond.await();
System.out.println("Check Site thread["
+Thread.currentThread().getId()
+"] is be notified");
} catch (InterruptedException e) {
e.printStackTrace();
}
}
}finally {
kmLock.unlock();
}
System.out.println("the Km is "+this.km+",I will change db");
}
/*当快递到达目的地时通知用户*/
public void waitSite(){
siteLock.lock();
try {
while(this.site.equals(CITY)) {
try {
siteCond.await();//当前线程进行等待
System.out.println("check Site thread["+Thread.currentThread().getName()
+"] is be notify");
} catch (InterruptedException e) {
e.printStackTrace();
}
}
}finally {
siteLock.unlock();
}
System.out.println("the site is "+this.site+",I will call user");
}
}
/**
*类说明：测试Lock和Condition实现等待通知
*/
public class TestCond {
private static ExpressCond express = new ExpressCond(0,ExpressCond.CITY);
/*检查里程数变化的线程,不满足条件，线程一直等待*/
private static class CheckKm extends Thread{
@Override
public void run() {
express.waitKm();
}
}
/*检查地点变化的线程,不满足条件，线程一直等待*/
private static class CheckSite extends Thread{
@Override
public void run() {
express.waitSite();
}
}
public static void main(String[] args) throws InterruptedException {
for(int i=0;i<3;i++){
new CheckSite().start();
}
for(int i=0;i<3;i++){
new CheckKm().start();
}
Thread.sleep(1000);
express.changeKm();
Thread.sleep(5000);
System.out.println("***********************");
express.changeSite();
}
}
结果：
API
void await()
导致当前线程等到发信号或 interrupted 。
boolean await(long time, TimeUnit unit)
使当前线程等待直到发出信号或中断，或指定的等待时间过去。
long awaitNanos(long nanosTimeout)
使当前线程等待直到发出信号或中断，或指定的等待时间过去。
void awaitUninterruptibly()
使当前线程等待直到发出信号。
boolean awaitUntil(Date deadline)
使当前线程等待直到发出信号或中断，或者指定的最后期限过去。
void signal()
唤醒一个等待线程。
void signalAll()
唤醒所有等待线程。
LockSupport
LockSupport定义了一组的公共静态方法，这些方法提供了最基本的线程阻塞和唤醒功能，而LockSupport也成为构建同步组件的基础工具。
LockSupport定义了一组以park开头的方法用来阻塞当前线程，以及unpark(Thread thread)方法来唤醒一个被阻塞的线程。LockSupport增加了park(Object blocker)、parkNanos(Object blocker,long nanos)和parkUntil(Object blocker,long deadline)3个方法，用于实现阻塞当前线程的功能，其中参数blocker是用来标识当前线程在等待的对象（以下称为阻塞对象），该对象主要用于问题排查和系统监控。
CLH(队列锁)
Java中的AQS是CLH队列锁的一种变体实现，要学AQS，先了解CLH。
CLH队列锁即Craig, Landin, and Hagersten locks。三个人的名字。
CLH队列锁也是一种基于链表的可扩展、高性能、公平的自旋锁，申请线程仅仅在本地变量上自旋，它不断轮询前驱的状态，假设发现前驱释放了锁就结束自旋。
原理
当一个线程需要获取锁时：
- 创建一个的QNode，将其中的locked设置为true表示需要获取锁，myPred表示对其前驱结点的引用
- 线程A对tail域调用getAndSet方法，使自己成为队列的尾部，同时获取一个指向其前驱结点的引用myPred
线程B需要获得锁，同样的流程再来一遍
- 线程就在前驱结点的locked字段上旋转，直到前驱结点释放锁(前驱节点的锁值 locked == false)
- 当一个线程需要释放锁时，将当前结点的locked域设置为false，同时回收前驱结点
如上图所示，前驱结点释放锁，线程A的myPred所指向的前驱结点的locked字段变为false，线程A就可以获取到锁。
CLH队列锁的优点是空间复杂度低（如果有n个线程，L个锁，每个线程每次只获取一个锁，那么需要的存储空间是O（L+n），n个线程有n个myNode，L个锁有L个tail）。CLH队列锁常用在SMP体系结构下。
扩展
SMP(Symmetric Multi-Processor)，即对称多处理器结构，指server中多个CPU对称工作，每一个CPU訪问内存地址所需时间同样。其主要特征是共享，包括对CPU，内存，I/O等进行共享。SMP的长处是可以保证内存一致性。缺点是这些共享的资源非常可能成为性能瓶颈。随着CPU数量的添加，每一个CPU都要訪问同样的内存资源，可能导致内存訪问冲突，可能会导致CPU资源的浪费。经常使用的PC机就属于这样的。
非一致存储访问，将CPU分为CPU模块，每个CPU模块由多个CPU组成，并且具有独立的本地内存、I/O槽口等，模块之间可以通过互联模块相互访问，访问本地内存（本CPU模块的内存）的速度将远远高于访问远地内存(其他CPU模块的内存)的速度，这也是非一致存储访问的由来。NUMA（Non Uniform Memory Access） 较好地解决SMP的扩展问题，当CPU数量增加时，因为访问远地内存的延时远远超过本地内存，系统性能无法线性增加。
CLH唯一的缺点是在NUMA系统结构下性能很差，但是在SMP系统结构下该法还是非常有效的。解决NUMA系统结构的思路是MCS队列锁。
AQS（队列同步器）
学习AQS的必要性
队列同步器AbstractQueuedSynchronizer（以下简称同步器或AQS），是用来构建锁或者其他同步组件的基础框架，它使用了一个int成员变量表示同步状态，通过内置的FIFO队列来完成资源获取线程的排队工作。并发包的大师（Doug Lea）期望它能够成为实现大部分同步需求的基础。
AQS使用方式和其中的设计模式
使用方式
AQS的主要使用方式是继承，子类通过继承AQS并实现它的抽象方法来管理同步状态，在AQS里由一个int型的state来代表这个状态，在抽象方法的实现过程中免不了要对同步状态进行更改，这时就需要使用同步器提供的3个方法（getState()、setState(int newState)和compareAndSetState(int expect,int update)）来进行操作，因为它们能够保证状态的改变是安全的。
在实现上，子类推荐被定义为自定义同步组件的静态内部类，AQS自身没有实现任何同步接口，它仅仅是定义了若干同步状态获取和释放的方法来供自定义同步组件使用，同步器既可以支持独占式地获取同步状态，也可以支持共享式地获取同步状态，这样就可以方便实现不同类型的同步组件（ReentrantLock、ReentrantReadWriteLock和CountDownLatch等）。
同步器是实现锁（也可以是任意同步组件）的关键，在锁的实现中聚合同步器。可以这样理解二者之间的关系：
锁是面向使用者的，它定义了使用者与锁交互的接口（比如可以允许两个线程并行访问），隐藏了实现细节；
同步器面向的是锁的实现者，它简化了锁的实现方式，屏蔽了同步状态管理、线程的排队、等待与唤醒等底层操作。锁和同步器很好地隔离了使用者和实现者所需关注的领域。
实现者需要继承同步器并重写指定的方法，随后将同步器组合在自定义同步组件的实现中，并调用同步器提供的模板方法，而这些模板方法将会调用使用者重写的方法。
模板方法模式
同步器的设计基于模板方法模式。模板方法模式的意图是，定义一个操作中的算法的骨架，而将一些步骤的实现延迟到子类中。模板方法使得子类可以不改变一个算法的结构即可重定义该算法的某些特定步骤。我们最常见的就是Spring框架里的各种Template。
点击这里了解模板方法模式。
AQS中的方法
模板方法
实现自定义同步组件时，将会调用同步器提供的模板方法
void acquire(int arg)
独占式获取同步状态，如果当前线程获取同步状态成功，则由该方法返回。否则，将会进入同步队列等待，该方法会调用重写的tryAcquire(int arg)方法。
void acquireInterruptibly(int arg)
与acquire(int arg) 相比，该方法响应中断。当前线程未获取到同步状态面进入同步队列中，如果当前线程被中断，则该方法会抛出InterruptedException并返回。
void acquireShared(int arg)
共享式获取同步状态，如果当前线程未获取同步状态，将会进入同步队列等待。与独占式获取的主要区别是在同一时刻可以有多个线程获取到同步状态。
void acquireSharedInterruptibly(int arg)
与acquireShared(int arg)相比，该方法响应中断。
boolean tryAcquireNanos(int arg, long nanosTimeout)
与tryAcquire(int arg)相比增加了超时限制。
boolean tryAcquireSharedNanos(int arg, long nanosTimeout)
与tryAcquireShared(int arg)相比增加了超时限制。
boolean release(int arg)
独占式释放同步状态。该方法会在释放同步状态之后，将同步队列中第一个节点包含的线程唤醒。
boolean releaseShared(int arg)
共享式释放同步状态。
Collection< Thread > getQueuedThreads()
返回一个包含可能正在等待获取的线程的集合。 因为在构建此结果时，实际的线程集可能会动态更改，所以返回的集合只是尽力而为的估计。 返回的集合的元素没有特定的顺序。 该方法旨在便于构建提供更广泛监控设施的子类。
可以重写的方法
protected boolean tryAcquire(int arg)
独占式获取同步状态，实现该方法需要查询当前状态并判断同步状态是否符合预期，然后再进行CAS设置同步状态。
protected int tryAcquireShared(int arg)
共享式获取同步状态，返回 大于等于0的值，表示获取成功，反之，获取失败。
protected boolean tryRelease(int arg)
独占式释放同步状态。等待获取同步状态的线程将有机会获取同步状态。
protected boolean tryReleaseShared(int arg)
共享式释放同步状态。
protected boolean isHeldExclusively()
当前同步器是否在独享模式下被线程占用，一般该方法表示是否被当前线程独占。
访问或修改同步状态的方法
重写同步器指定的方法时，需要使用同步器提供的如下3个方法来访问或修改同步状态。
protected int getState()
获取当前同步状态。
protected void setState(int newState)
设置当前同步状态。
protected boolean compareAndSetState(int expect, int update)
使用CAS设置当前状态，该方法能够保证状态设置的原子性。
AQS中的节点（Node）
既然说Java中的AQS是CLH队列锁的一种变体实现，毫无疑问，作为队列来说，必然要有一个节点的数据结构来保存我们前面所说的各种域，比如前驱节点，节点的状态等，这个数据结构就是AQS中的内部类Node。作为这个数据结构应该关心些什么信息？
1、线程信息，肯定要知道我是哪个线程；
2、队列中线程状态，既然知道是哪一个线程，肯定还要知道线程当前处在什么状态，是已经取消了“获锁”请求，还是在“”等待中”，或者说“即将得到锁”
3、前驱和后继线程，因为是一个等待队列，那么也就需要知道当前线程前面的是哪个线程，当前线程后面的是哪个线程（因为当前线程释放锁以后，理当立马通知后继线程去获取锁）。
所以这个Node类是这么设计的：
线程的2种等待模式
SHARED：表示线程以共享的模式等待锁（如ReadLock）
EXCLUSIVE：表示线程以互斥的模式等待锁（如ReetrantLock），互斥就是一把锁只能由一个线程持有，不能同时存在多个线程使用同一个锁。
线程（节点）在队列中的状态枚举
CANCELLED：值为1，表示线程的获锁请求已经“取消”
SIGNAL：值为-1，表示后继节点需要被唤醒，也就是正在阻塞
CONDITION：值为-2，表示线程等待某一个条件（Condition）被满足
PROPAGATE：值为-3，当线程处在“SHARED”模式时，该字段才会被使用上，释放共享资源时需要通知其他节点
初始化Node对象时，默认为0
成员变量
waitStatus：该int变量表示线程在队列中的状态，其值就是上述提到的CANCELLED、SIGNAL、CONDITION、PROPAGATE
prev：该变量类型为Node对象，表示该节点的前一个Node节点（前驱）
next：该变量类型为Node对象，表示该节点的后一个Node节点（后继）
thread：该变量类型为Thread对象，表示该节点的代表的线程
nextWaiter：该变量类型为Node对象，表示等待condition条件的Node节点
当前线程获取同步状态失败时，同步器会将当前线程以及等待状态等信息构造成为一个节点（Node）并将其加入同步队列，同时会阻塞当前线程，当同步状态释放时，会把首节点中的线程唤醒，使其再次尝试获取同步状态。同步队列中的节点（Node）用来保存获取同步状态失败的线程引用、等待状态以及前驱和后继节点。
head和tail
AQS还拥有首节点（head）和尾节点（tail）两个引用，一个指向队列头节点，而另一个指向队列尾节点。
注意：因为首节点head是不保存线程信息的节点，仅仅是因为数据结构设计上的需要，在数据结构上，这种做法往往叫做“空头节点链表”。对应的就有“非空头结点链表”。
入队和出队
节点加入到同步队列
当一个线程成功地获取了同步状态（或者锁），其他线程将无法获取到同步状态，也就是获取同步状态失败，AQS会将这个线程以及等待状态等信息构造成为一个节点（Node）并将其加入同步队列的尾部。而这个加入队列的过程必须要保证线程安全，因此同步器提供了一个基于CAS的设置尾节点的方法：compareAndSetTail(Node expect,Node update)，它需要传递当前线程“认为”的尾节点和当前节点，只有设置成功后，当前节点才正式与之前的尾节点建立关联。
首节点的变化
首节点是获取同步状态成功的节点，首节点的线程在释放同步状态时，将会唤醒后继节点，而后继节点将会在获取同步状态成功时将自己设置为首节点。设置首节点是通过获取同步状态成功的线程来完成的，由于只有一个线程能够成功获取到同步状态，因此设置头节点的方法并不需要使用CAS来保证，它只需要将首节点设置成为原首节点的后继节点并断开原首节点的next引用即可。
独占式同步状态获取与释放
获取
通过调用同步器的acquire(int arg)方法可以获取同步状态，主要完成了同步状态获取、节点构造、加入同步队列以及在同步队列中自旋等待的相关工作，其主要逻辑是：
public final void acquire(int arg) {
if (!tryAcquire(arg) &&
acquireQueued(addWaiter(Node.EXCLUSIVE), arg))
selfInterrupt();
}
首先调用自定义同步器实现的tryAcquire(int arg)方法，该方法需要保证线程安全的获取同步状态。
如果同步状态获取失败（tryAcquire返回false），则构造同步节点（独占式Node.EXCLUSIVE，同一时刻只能有一个线程成功获取同步状态）并通过addWaiter(Node node)方法将该节点加入到同步队列的尾部，
最后调用acquireQueued(Node node,int arg)方法，使得该节点以“死循环”的方式获取同步状态。如果获取不到则阻塞节点中的线程，而被阻塞线程的唤醒主要依靠前驱节点的出队或阻塞线程被中断来实现。
addWaiter(Node node)方法中
private Node addWaiter(Node mode) {
Node node = new Node(Thread.currentThread(), mode);
// Try the fast path of enq; backup to full enq on failure
Node pred = tail;
if (pred != null) {
node.prev = pred;
if (compareAndSetTail(pred, node)) {
pred.next = node;
return node;
}
}
enq(node);
return node;
}
将当前线程包装成Node后，队列不为空的情况下，先尝试把当前节点加入队列并成为尾节点，如果不成功或者队列为空进入enq(final Node 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;
}
}
}
}
在enq(final Node node)方法中，同步器通过“死循环”来保证节点的正确添加，这个死循环中，做了两件事，第一件，如果队列为空，初始化队列，new出一个空节点，并让首节点（head）和尾节点（tail）两个引用都指向这个空节点（这个空节点代表第一个获取同步状态的线程，它在CAS成功后就获得了同步状态，没有加入队列）；第二件事，把当前节点加入队列。
在“死循环”中只有通过CAS将节点设置成为尾节点之后，当前线程才能从该方法返回，否则，当前线程不断地尝试设置。
节点进入同步队列之后，观察acquireQueued(Node node,int arg)方法
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);
}
}
其实就是一个自旋的过程，每个节点（或者说每个线程）都在自省地观察，当条件满足，获取到了同步状态，就可以从这个自旋过程中退出；否则会阻塞节点的线程，直到下一次其它线程释放同步状态会唤醒此线程，继续自旋。
在acquireQueued(final Node node,int arg)方法中，当前线程在“死循环”中尝试获取同步状态，而只有前驱节点是头节点才能够尝试获取同步状态，这是为什么？原因有两个。
第一，头节点是成功获取到同步状态的节点，而头节点的线程释放了同步状态之后，将会唤醒其后继节点，后继节点的线程被唤醒后需要检查自己的前驱节点是否是头节点。
第二，维护同步队列的FIFO原则。
当前线程获取到同步状态后，让首节点（head）这个引用指向自己所在节点。当同步状态获取成功后，当前线程就从acquire方法返回了。如果同步器实现的是锁，那就代表当前线程获得了锁。
//判断当前线程是否应该阻塞
private static boolean shouldParkAfterFailedAcquire(Node pred, Node node) {
int ws = pred.waitStatus;
//如果前一个节点状态为SIGNAL，-1，代表当前阻塞，需要唤醒
if (ws == Node.SIGNAL)
/*
* This node has already set status asking a release
* to signal it, so it can safely park.
*/
return true;
//如果前一个节点状态为CANCELLED，1，需要不断往前找，直到找到不为1的
if (ws > 0) {
/*
* Predecessor was cancelled. Skip over predecessors and
* indicate retry.
*/
do {
node.prev = pred = pred.prev;
} while (pred.waitStatus > 0);
pred.next = node;
} else {
/*
* waitStatus must be 0 or PROPAGATE. Indicate that we
* need a signal, but don't park yet. Caller will need to
* retry to make sure it cannot acquire before parking.
*/
//如果前一个节点状态为初始状态，0 或 PROPAGATE，-3
//就把它设置成 SIGNAL，-1
compareAndSetWaitStatus(pred, ws, Node.SIGNAL);
}
return false;
}
初始化队列时创建的空节点，节点状态为初始状态，0，就是在这里的 compareAndSetWaitStatus 被设置成了-1。如果前面拿到同步状态的线程还没释放，下一次再进这里就会阻塞。
private final boolean parkAndCheckInterrupt() {
//调用本地方法
LockSupport.park(this);
return Thread.interrupted();
}
在这个方法，当前线程阻塞。以后被前面一个节点唤醒，也是从这里唤醒。
释放
当前线程获取同步状态并执行了相应逻辑之后，就需要释放同步状态，使得后续节点能够继续获取同步状态。通过调用同步器的release(int arg)方法可以释放同步状态，该方法在释放了同步状态之后，会唤醒其后继节点（进而使后继节点重新尝试获取同步状态）。
public final boolean release(int arg) {
if (tryRelease(arg)) {
Node h = head;
if (h != null && h.waitStatus != 0)
unparkSuccessor(h);
return true;
}
return false;
}
该方法执行时，会唤醒首节点（head）所指向节点的后继节点线程，unparkSuccessor(Node node)方法使用LockSupport来唤醒处于等待状态的线程。
而在unparkSuccessor中，
private void unparkSuccessor(Node node) {
int ws = node.waitStatus;
if (ws < 0)
compareAndSetWaitStatus(node, ws, 0);
Node s = node.next;
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);
}
这段代码的意思，一般情况下，被唤醒的是head指向节点的后继节点线程，如果这个后继节点处于被cancel状态，（开发者的思路可能是这样的：head指向节点的后继节点处于cancel状态时，后续的节点cancel的几率都比较大）先从尾开始遍历，找到最前面且没有被cancel的节点。
总结
在获取同步状态时，同步器维护一个同步队列，获取状态失败的线程都会被加入到队列中并在队列中进行自旋；移出队列（或停止自旋）的条件是前驱节点为头节点且成功获取了同步状态。在释放同步状态时，同步器调用tryRelease(int arg)方法释放同步状态，然后唤醒head指向节点的后继节点。
共享式同步状态获取与释放
共享式获取与独占式获取最主要的区别在于同一时刻能否有多个线程同时获取到同步状态。以读写为例，如果一个程序在进行读操作，那么这一时刻写操作均被阻塞，而读操作能够同时进行。写操作要求对资源的独占式访问，而读操作可以是共享式访问。
public final void acquireShared(int arg) {
if (tryAcquireShared(arg) < 0)
doAcquireShared(arg);
}
在acquireShared(int arg)方法中，同步器调用tryAcquireShared(int arg)方法尝试获取同步状态，tryAcquireShared(int arg)方法返回值为int类型，当返回值大于等于0时，表示能够获取到同步状态。因此，在共享式获取的自旋过程中，成功获取到同步状态并退出自旋的条件就是tryAcquireShared(int arg)方法返回值大于等于0。
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);
}
}
可以看到，在doAcquireShared(int arg)方法的自旋过程中，如果当前节点的前驱为头节点时，尝试获取同步状态，如果返回值大于等于0，表示该次获取同步状态成功，将此节点设置为头结点并传播。
该方法在释放同步状态之后，将会唤醒后续处于等待状态的节点。对于能够支持多个线程同时访问的并发组件（比如Semaphore），它和独占式主要区别在于tryReleaseShared(int arg)方法必须确保同步状态（或者资源数）线程安全释放，一般是通过循环和CAS来保证的，因为释放同步状态的操作会同时来自多个线程。
private void setHeadAndPropagate(Node node, int propagate) {
Node h = head; // Record old head for check below
setHead(node);
if (propagate > 0 || h == null || h.waitStatus < 0 ||
(h = head) == null || h.waitStatus < 0) {
Node s = node.next;
if (s == null || s.isShared())
doReleaseShared();
}
}
Condition的实现
等待队列是一个FIFO的队列，在队列中的每个节点都包含了一个线程引用，该线程就是在Condition对象上等待的线程，如果一个线程调用了Condition.await()方法，那么该线程将会释放锁、构造成节点加入等待队列并进入等待状态。事实上，节点的定义复用了同步器中节点的定义，也就是说，同步队列和等待队列中节点类型都是同步器的静态内部类。
一个Condition包含一个等待队列，Condition拥有首节点（firstWaiter）和尾节点（lastWaiter）。当前线程调用Condition.await()方法，将会以当前线程构造节点，并将节点从尾部加入等待队列。Condition拥有首尾节点的引用，而新增节点只需要将原有的尾节点nextWaiter指向它，并且更新尾节点即可。上述节点引用更新的过程并没有使用CAS保证，原因在于调用await()方法的线程必定是获取了锁的线程，也就是说该过程是由锁来保证线程安全的。
Lock（更确切地说是同步器）拥有一个同步队列和多个等待队列。
调用Condition的await()方法（或者以await开头的方法），会使当前线程进入等待队列并释放锁，同时线程状态变为等待状态。当从await()方法返回时，当前线程一定获取了Condition相关联的锁。
如果从队列（同步队列和等待队列）的角度看await()方法，当调用await()方法时，相当于同步队列的首节点（获取了锁的节点）移动到Condition的等待队列中（只是相当于，实际上是2个节点）。调用该方法的线程成功获取了锁的线程，也就是同步队列中的首节点，该方法会将当前线程构造成节点并加入等待队列中，然后释放同步状态，唤醒同步队列中的后继节点，然后当前线程会进入等待状态。当等待队列中的节点被唤醒，则唤醒节点的线程开始尝试获取同步状态。如果不是通过其他线程调用Condition.signal()方法唤醒，而是对等待线程进行中断，则会抛出InterruptedException。
public final void await() throws InterruptedException {
if (Thread.interrupted())
throw new InterruptedException();
//新建节点，插入等待队列队尾
Node node = addConditionWaiter();
//更改AQS状态（重入次数）为0；唤醒同步队列的下一个节点，由下一个节点获取同步状态时将节点从同步队列删除。
//运行正常的话，其实用不到node参数
int savedState = fullyRelease(node);
int interruptMode = 0;
//如果不在同步队列。具体实现不能看方法名，见后文。
while (!isOnSyncQueue(node)) {
//阻塞，挂起
//等待别的线程唤醒，移除等待队列，加入同步队列，退出循环
LockSupport.park(this);
if ((interruptMode = checkInterruptWhileWaiting(node)) != 0)
break;
}
//获取同步状态成功，成为头结点 或 阻塞
if (acquireQueued(node, savedState) && interruptMode != THROW_IE)
interruptMode = REINTERRUPT;
if (node.nextWaiter != null) // clean up if cancelled
unlinkCancelledWaiters();
if (interruptMode != 0)
reportInterruptAfterWait(interruptMode);
}
private Node addConditionWaiter() {
Node t = lastWaiter;
// If lastWaiter is cancelled, clean out.
if (t != null && t.waitStatus != Node.CONDITION) {
unlinkCancelledWaiters();
t = lastWaiter;
}
//新建节点，加入尾部
Node node = new Node(Thread.currentThread(), Node.CONDITION);
if (t == null)
firstWaiter = node;
else
t.nextWaiter = node;
lastWaiter = node;
return node;
}
final int fullyRelease(Node node) {
boolean failed = true;
try {
//可以看到，并没有用到入参node
int savedState = getState();
//这里也用不到入参
if (release(savedState)) {
failed = false;
return savedState;
} else {
throw new IllegalMonitorStateException();
}
} finally {
if (failed)
node.waitStatus = Node.CANCELLED;
}
}
final boolean isOnSyncQueue(Node node) {
//第一次进行while判断，必返回false，进入循环。此时跟在不在同步队列上没关系，所以不能只看方法名。
if (node.waitStatus == Node.CONDITION || node.prev == null)
return false;
//如果又有节点加入了同步队列，node有了尾结点
if (node.next != null) // If has successor, it must be on queue
return true;
/*
* node.prev can be non-null, but not yet on queue because
* the CAS to place it on queue can fail. So we have to
* traverse from tail to make sure it actually made it. It
* will always be near the tail in calls to this method, and
* unless the CAS failed (which is unlikely), it will be
* there, so we hardly ever traverse much.
*/
//从尾结点开始找
return findNodeFromTail(node);
}
如图所示，同步队列的首节点并不会直接加入等待队列，而是通过addConditionWaiter()方法把当前线程构造成一个新的节点并将其加入等待队列中。
调用Condition的signal()方法，会将在等待队列中等待时间最长的节点（首节点）移到同步队列尾部，并唤醒。这时节点是开始自旋，依旧要在同步队列中排队，而不是直接获取同步状态。
public final void signal() {
if (!isHeldExclusively())
throw new IllegalMonitorStateException();
Node first = firstWaiter;
if (first != null)
//唤醒首节点，移除等待队列，加入同步队列队尾
doSignal(first);
}
private void doSignal(Node first) {
do {
//firstWaiter为首节点的下一个节点
if ( (firstWaiter = first.nextWaiter) == null)
lastWaiter = null;
//首节点移除等待队列
first.nextWaiter = null;
//当transferForSignal不成功，first指向了之前first的下一个节点且这个节点不为空
} while (!transferForSignal(first) &&
(first = firstWaiter) != null);
}
//这是AQS的方法
final boolean transferForSignal(Node node) {
//如果CAS不成功返回false,说明node在CANCELLED状态。回去继续唤醒等待队列首节点
if (!compareAndSetWaitStatus(node, Node.CONDITION, 0))
return false;
//当前node的等待状态已变为0
//入同步队列队尾，返回的是原来的队尾节点，也就是现在节点的前驱
Node p = enq(node);
int ws = p.waitStatus;
//如果前驱CANCELLED，就可以直接唤醒同步队列队尾节点node，也就是之前等待队列的首节点
//CAS前驱等待状态为SIGNAL，成功则表示node应该阻塞；失败则直接唤醒node的线程
if (ws > 0 || !compareAndSetWaitStatus(p, ws, Node.SIGNAL))
//直接唤醒node的线程，此时节点在队尾
LockSupport.unpark(node.thread);
return true;
}
调用该方法的前置条件是当前线程必须获取了锁，可以看到signal()方法进行了isHeldExclusively()检查，也就是当前线程必须是获取了锁的线程。接着获取等待队列的首节点，将其移动到同步队列并使用LockSupport唤醒节点中的线程。
通过调用同步器的enq(Node node)方法，等待队列中的头节点线程安全地移动到同步队列。当节点移动到同步队列后，当前线程再使用LockSupport唤醒该节点的线程。
被唤醒后的线程，将从await()方法中的while循环中退出（isOnSyncQueue(Node node)方法返回true，节点已经在同步队列中），进而调用同步器的acquireQueued()方法加入到获取同步状态的竞争中。
成功获取同步状态（或者说锁）之后，被唤醒的线程将从先前调用的await()方法返回，此时该线程已经成功地获取了锁。
Condition的signalAll()方法，相当于对等待队列中的每个节点均执行一次signal()方法，效果就是将等待队列中所有节点全部移动到同步队列中，并唤醒每个节点的线程。
public final void signalAll() {
if (!isHeldExclusively())
throw new IllegalMonitorStateException();
Node first = firstWaiter;
if (first != null)
doSignalAll(first);
}
private void doSignalAll(Node first) {
lastWaiter = firstWaiter = null;
do {
Node next = first.nextWaiter;
first.nextWaiter = null;
transferForSignal(first);
first = next;
} while (first != null);
}
Lock的实现
ReentrantLock的实现
锁的可重入
重进入是指任意线程在获取到锁之后能够再次获取该锁而不会被锁所阻塞，该特性的实现需要解决以下两个问题。
1）线程再次获取锁。锁需要去识别获取锁的线程是否为当前占据锁的线程，如果是，则再次成功获取。
2）锁的最终释放。线程重复n次获取了锁，随后在第n次释放该锁后，其他线程能够获取到该锁。锁的最终释放要求锁对于获取进行计数自增，计数表示当前锁被重复获取的次数，而锁被释放时，计数自减，当计数等于0时表示锁已经成功释放。
nonfairTryAcquire方法增加了再次获取同步状态的处理逻辑：通过判断当前线程是否为获取锁的线程来决定获取操作是否成功，如果是获取锁的线程再次请求，则将同步状态值进行增加并返回true，表示获取同步状态成功。同步状态表示锁被一个线程重复获取的次数。
如果该锁被获取了n次，那么前(n-1)次tryRelease(int releases)方法必须返回false，而只有同步状态完全释放了，才能返回true。可以看到，该方法将同步状态是否为0作为最终释放的条件，当同步状态为0时，将占有线程设置为null，并返回true，表示释放成功。
公平和非公平
ReentrantLock的构造函数中，默认的无参构造函数将会把Sync对象创建为NonfairSync对象，这是一个“非公平锁”；而另一个构造函数ReentrantLock(boolean fair)传入参数为true时将会把Sync对象创建为“公平锁”FairSync。
对于非公平锁，它在入队之前有2次CAS设置同步状态的机会；而公平锁则不同，先调用hasQueuedPredecessors()方法会判断是否有第二个节点（因为头结点是获取到了同步状态的），如果有，则表示有线程比当前线程更早地请求获取锁，因此需要等待前驱线程获取并释放锁之后才能继续获取锁；如果没有，才有一次CAS的机会，这次成功就可以避免入队。
我们往往用的是默认的非公平锁，为什么？
线程不必加入等待队列就有2次获得锁的机会,如果在这2次机会中成功获得锁：
1.免去了构造结点并加入队列的繁琐操作,减少了加入队列时 CAS 的竞争。
2.节省了线程阻塞唤醒的开销,线程阻塞和唤醒涉及到线程上下文的切换和操作系统的系统调用,是非常耗时的。在高并发情况下,如果线程持有锁的时间非常短,短到线程入队阻塞的过程超过线程持有并释放锁的时间开销,那么这种抢占式特性对并发性能的提升会更加明显。
源码分析
类 ReentrantLock
public void lock() {
sync.lock();
}
从上图可以看出，公平锁和非公平锁只有 lock() 和 tryAcquire(int) 方法不同而已。lock() 是重写的 Sync 的方法，tryAcquire(int) 是重写的 AQS 的方法。AQS 里已经分析过的方法 acquire、release 等，这里不会再分析了。
static final class NonfairSync extends Sync {
private static final long serialVersionUID = 7316153563782823691L;
final void lock() {
//立即CAS设置状态，这里的状态是获得锁的次数，因为是可重入的。
if (compareAndSetState(0, 1))
//如果设置成功，设置当前线程为独占锁拥有者。
setExclusiveOwnerThread(Thread.currentThread());
else
//AQS里的方法，1用于后面的重入次数的计数
acquire(1);
}
protected final boolean tryAcquire(int acquires) {
//见下面
return nonfairTryAcquire(acquires);
}
}
static final class FairSync extends Sync {
private static final long serialVersionUID = -3000897897090466540L;
final void lock() {
//不会进行CAS的尝试
acquire(1);
}
protected final boolean tryAcquire(int acquires) {
final Thread current = Thread.currentThread();
//重入次数
int c = getState();
//0表示当前是第一次尝试获取锁
if (c == 0) {
//如果没有前驱节点才会进行一次CAS
if (!hasQueuedPredecessors() &&
compareAndSetState(0, acquires)) {
//如果CAS成功，则设置当前线程独占锁资源
setExclusiveOwnerThread(current);
return true;
}
}
//如果当前线程已经拿到了锁，代表这次是重入的
else if (current == getExclusiveOwnerThread()) {
//次数加1
int nextc = c + acquires;
if (nextc < 0)
throw new Error("Maximum lock count exceeded");
//设置状态
setState(nextc);
return true;
}
//tryAcquire失败，后续就要进行入队等操作了
return false;
}
}
final boolean nonfairTryAcquire(int acquires) {
final Thread current = Thread.currentThread();
int c = getState();
//第一次尝试获得锁
if (c == 0) {
//第二次CAS
if (compareAndSetState(0, acquires)) {
setExclusiveOwnerThread(current);
return true;
}
}
//如果当前线程已经拿到了锁，代表这次是重入的
else if (current == getExclusiveOwnerThread()) {
int nextc = c + acquires;
if (nextc < 0) // overflow
throw new Error("Maximum lock count exceeded");
setState(nextc);
return true;
}
return false;
}
protected final boolean tryRelease(int releases) {
//每一次释放都是让状态减1
int c = getState() - releases;
if (Thread.currentThread() != getExclusiveOwnerThread())
throw new IllegalMonitorStateException();
boolean free = false;
//减到0才能释放锁资源
if (c == 0) {
free = true;
setExclusiveOwnerThread(null);
}
setState(c);
return free;
}
ReentrantReadWriteLock的实现
读写状态的设计
读写锁同样依赖自定义同步器来实现同步功能，而读写状态就是其同步器的同步状态。
回想ReentrantLock中自定义同步器的实现，同步状态表示锁被一个线程重复获取的次数，而读写锁的自定义同步器需要在同步状态（一个整型变量）上维护多个读线程和一个写线程的状态，使得该状态的设计成为读写锁实现的关键。
如果在一个整型变量上维护多种状态，就一定需要“按位切割使用”这个变量，读写锁将变量切分成了两个部分，高16位表示读，低16位表示写，读写锁是如何迅速确定读和写各自的状态呢？
答案是通过位运算。假设当前同步状态值为S，写状态等于S&0x0000FFFF（将高16位全部抹去），读状态等于S>>>16（无符号补0右移16位）。当写状态增加1时，等于S+1，当读状态增加1时，等于S+(1<<16)，也就是S+0x00010000。根据状态的划分能得出一个推论：S不等于0时，当写状态（S&0x0000FFFF）等于0时，则读状态（S>>>16）大于0，即读锁已被获取。
写锁的获取与释放
写锁是一个支持重进入的排它锁。如果当前线程已经获取了写锁，则增加写状态。如果当前线程在获取写锁时，读锁已经被获取（读状态不为0）或者该线程不是已经获取写锁的线程，则当前线程进入等待状态。
该方法除了重入条件（当前线程为获取了写锁的线程）之外，增加了一个读锁是否存在的判断。如果存在读锁，则写锁不能被获取，原因在于：读写锁要确保写锁的操作对读锁可见，如果允许读锁在已被获取的情况下对写锁的获取，那么正在运行的其他读线程就无法感知到当前写线程的操作。因此，只有等待其他读线程都释放了读锁，写锁才能被当前线程获取，而写锁一旦被获取，则其他读写线程的后续访问均被阻塞。
写锁的释放与ReentrantLock的释放过程基本类似，每次释放均减少写状态，当写状态为0时表示写锁已被释放，从而等待的读写线程能够继续访问读写锁，同时前次写线程的修改对后续读写线程可见。
读锁的获取与释放
读锁是一个支持重进入的共享锁，它能够被多个线程同时获取，在没有其他写线程访问（或者写状态为0）时，读锁总会被成功地获取，而所做的也只是（线程安全的）增加读状态。如果当前线程已经获取了读锁，则增加读状态。
如果当前线程在获取读锁时，写锁已被其他线程获取，则进入等待状态。读状态是所有线程获取读锁次数的总和，而每个线程各自获取读锁的次数只能选择保存在ThreadLocal中，由线程自身维护。在tryAcquireShared(int unused)方法中，如果其他线程已经获取了写锁，则当前线程获取读锁失败，进入等待状态。如果当前线程获取了写锁或者写锁未被获取，则当前线程（线程安全，依靠CAS保证）增加读状态，成功获取读锁。读锁的每次释放（线程安全的，可能有多个读线程同时释放读锁）均减少读状态。
锁的升降级
锁降级指的是写锁降级成为读锁。如果当前线程拥有写锁，然后将其释放，最后再获取读锁，这种分段完成的过程不能称之为锁降级。
锁降级是指把持住（当前拥有的）写锁，再获取到读锁，随后释放（先前拥有的）写锁的过程。
RentrantReadWriteLock不支持锁升级（把持读锁、获取写锁，最后释放读锁的过程）。目的是保证数据可见性，如果读锁已被多个线程获取，其中任意线程成功获取了写锁并更新了数据，则其更新对其他获取到读锁的线程是不可见的。
【并发编程】目录：
【并发编程】之走进Java里的线程世界
【并发编程】之学会使用线程的并发工具类
【并发编程】之学会使用原子操作CAS
【并发编程】之深入理解显式锁和AQS
【并发编程】之一文彻底搞懂并发容器
【并发编程】之Java面试经常会问到的线程池，你搞清楚了吗?
【并发编程】之Java并发安全知识点总结
【并发编程】之大厂很可能会问到的JMM底层实现原理