接着上一篇文章再来分析下同步是如何完成线程同步的，主要内容有：同步队列，独占式同步状态获取与释放，共享式同步状态获取与释放，超时获取同步状态。
1，同步器状态同步整体说明
同步器依赖内部的同步队列(FIFO双向队列)业完成同步状态的管理，当前线程获取同步状态失败时，同步器会将当前线程及等待状态等信息构造成一个节点Node并将其加入同步队列，同时阻塞当前线程，当同步状态释放时，会将节点中的线程唤醒，使其再次获取同步状态。
同步器包含了两个节点类型的引用，一个指向头节点，另一个指向尾节点。获取同步状态时只会有一个线程能获取成功，因此设置头节点时不需要使用CAS，只需要将首节点设置成为原首节点的后继节点并断开原首节点的next引用。首节点的线程在释放同步状态时，会唤醒后继节点，后继节点在获取到同步状态后将自己设置为首节点。
其它没获取到头节点的线程会被构造成节点加入到同步队列的尾部，因为有多个线程所以使用了CAS设置尾节点。
2，同步器源码说明
2.1 Node节点类
同步队列中的节点(Node)用来保存获取同步状态失败的线程引用，等待状态及前驱和后继节点。
static final class Node {
/** Marker to indicate a node is waiting in shared mode */
static final Node SHARED = new Node();
/** Marker to indicate a node is waiting in exclusive mode */
static final Node EXCLUSIVE = null;
/** waitStatus value to indicate thread has cancelled */
static final int CANCELLED = 1;
/** waitStatus value to indicate successor's thread needs unparking */
static final int SIGNAL = -1;
/** waitStatus value to indicate thread is waiting on condition */
static final int CONDITION = -2;
/**
* waitStatus value to indicate the next acquireShared should
* unconditionally propagate
*/
static final int PROPAGATE = -3;
volatile int waitStatus;
volatile Node prev;
volatile Node next;
volatile Thread thread;
Node nextWaiter;
/**
* Returns true if node is waiting in shared mode.
*/
final boolean isShared() {
return nextWaiter == SHARED;
}
/**
* Returns previous node, or throws NullPointerException if null.
* Use when predecessor cannot be null. The null check could
* be elided, but is present to help the VM.
*
* @return the predecessor of this node
*/
final Node predecessor() throws NullPointerException {
Node p = prev;
if (p == null)
throw new NullPointerException();
else
return p;
}
Node() { // Used to establish initial head or SHARED marker
}
Node(Thread thread, Node mode) { // Used by addWaiter
this.nextWaiter = mode;
this.thread = thread;
}
Node(Thread thread, int waitStatus) { // Used by Condition
this.waitStatus = waitStatus;
this.thread = thread;
}
}
waitStatus，等待状态，包含如下状态：
CANCELLED(1)：由于在同步队列中等待的线程超时或被中断需要从同步队列中取消等待，节点进入该状态将不会变化
SIGNAL(-1)：后继的线程处于等待状态，如果当前节点的线程释放了同步状态或者被取消，将会通知后继节点使后继节点的线程得以运行。
CONDITION(-2)：节点处于等待队列中，节点线程等待在Condition上，当其它线程对Condition调用了signal后，该节点将会从等待队列中转移到同步队列，加入到对同步状态的获取中。
PROPAGATE(-3)：表示下一次共享式同步状态获取将会无条件被传播下去。
INITIAL(0):初始状态。
注意，负值表示结点处于有效等待状态，而正值表示结点已被取消。所以源码中很多地方用>0、<0来判断结点的状态是否正常。
Node prev，前驱节点，当节点加入同步队列时被设置（尾部添加）。
Node next，后继节点。
Node nextWaiter，同步队列中的后继节点，如果当前节点是共享的，那么这个字段是一个SHARED常量，也就是说节点类型（分独占和共享）和同步队列中的后继节点共用一个字段。
Thread thread，获取同步状态的线程。
3，独占锁及共享锁的实现
3.1.1 acquire(int) 独占锁获取
此方法是独占模式（独占模式是通过isHeldByCurrentThread或getHoldCount方法进行判断的，也就是比较持有锁的线程是否是当前线程）下线程获取共享资源的顶层入口。如果获取到资源，线程直接返回，否则进入同步队列，直到获取到资源为止，且整个过程忽略中断的影响。这也正是lock()的语义，当然不仅仅只限于lock()。获取到资源后，线程就可以去执行其临界区代码了。下面是acquire()的源码：
public final void acquire(int arg) {
if (!tryAcquire(arg) &&
acquireQueued(addWaiter(Node.EXCLUSIVE), arg))
selfInterrupt();
}
流程如下：
- tryAcquire()尝试直接去获取资源，如果成功则直接返回（&&为短路运算符，这里体现了非公平锁，每个线程获取锁时会尝试直接抢占加塞一次，而CLH队列中可能还有别的线程在等待）；如果失败则进一步执行acquireQueued()
- addWaiter()将该线程加入同步队列的尾部，并标记为独占模式。
- acquireQueued()使线程阻塞在同步队列中获取资源，一直获取到资源后才返回。如果在整个等待过程中被中断过，则返回true，否则返回false。
- 如果线程在等待过程中被中断过，它是不响应的。只是获取资源后才再进行自我中断selfInterrupt()，将中断补上。
protected boolean tryAcquire(int arg) {
throw new UnsupportedOperationException();
}
AQS这里只定义了一个接口，具体资源的获取交由自定义同步器去实现了（通过state的get/set/CAS）。
private Node addWaiter(Node mode) {
//以给定模式构造结点。mode有两种：EXCLUSIVE（独占）和SHARED（共享）
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;
}
}
//CAS自旋加入队尾
enq(node);
return node;
}
//加入队尾
private Node enq(final Node node) {
//CAS"自旋"，直到成功加入队尾
for (;;) {
Node t = tail;
if (t == null) {// 队列为空，创建一个空的标志结点作为head结点，并将tail也指向它。
if (compareAndSetHead(new Node()))
tail = head;
} else {
node.prev = t;
if (compareAndSetTail(t, node)) {//放入队尾
t.next = node;
return t;
}
}
}
}
//获取同步状态
final boolean acquireQueued(final Node node, int arg) {
boolean failed = true;//标记是否成功拿到资源，true未获取；false已获取
try {
boolean interrupted = false;//标记等待过程中是否被中断过
for (;;) {
final Node p = node.predecessor();//前驱节点
//如果前驱节点是头节点，才有资格(可能是被头节点唤醒或被中断)去获取同步状态
if (p == head && tryAcquire(arg)) {
//将同步器节点指向当前节点，当前节点也就成为了头节点
setHead(node);
//将之前的头节点的next置为null，也就是断开与下一节点的连接
//这个操作是将之前的头节点从队列里移除了
p.next = null;//HELP GC
failed = false;//成功获取资源
return interrupted;
}
//如果前驱节点不是头节点且尝试获取同步状态失败，则说明需要park
//从而进入waiting状态直到被unpark()
if (shouldParkAfterFailedAcquire(p, node) &&
parkAndCheckInterrupt())
interrupted = true;
}
} finally {
//如果等待过程中没有成功获取资源（如timeout，或者可中断的情况下被中断了），那么取消结点在队列中的等待。
if (failed)
cancelAcquire(node);
}
}
/*
*此方法主要用于检查状态，看看自己是否真的可以去休息了，
*以免队列前边的线程都放弃了而自己一直盲等。
*整个流程中，如果前驱结点的状态不是SIGNAL，那么自己就不能安心去休息，
*需要去找个安心的休息点，同时可以再尝试下看有没有机会轮到自己拿号
*/
private static boolean shouldParkAfterFailedAcquire(Node pred, Node node) {
int ws = pred.waitStatus;//获取前驱节点状态
if (ws == Node.SIGNAL)
/*
* This node has already set status asking a release
* to signal it, so it can safely park.
* 如果已经告诉前驱拿完号后通知自己一下，那就可以安心休息了
* 可以看下上面2.1 Node类里关于waitStatus的说明
*/
return true;
if (ws > 0) {
/*
* Predecessor was cancelled. Skip over predecessors and
* indicate retry.
* 前驱节点状态大于0说明前驱节点因为等待超时或被中断放弃了等待
* 如果前驱放弃了，那就一直往前找，直到找到最近一个正常等待的状态，
* 并排在它的后边。
* 注意：那些放弃的结点，由于被自己“加塞”到它们前边，
* 它们相当于形成一个无引用链，稍后就会被GC回收
*/
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.
* 如果前驱正常，那就把前驱的状态设置成SIGNAL，告诉它拿完号后
* 通知自己一下。
*/
compareAndSetWaitStatus(pred, ws, Node.SIGNAL);
}
return false;
}
/*
*如果线程找好安全休息点后，那就可以安心去休息了。此方法就是让线程去休息，
*真正进入等待状态。
*/
private final boolean parkAndCheckInterrupt() {
//park()会让当前线程进入waiting状态。在此状态下，有两种途径可以唤醒该线程：1）被unpark()；2）被interrupt()。
LockSupport.park(this);
//Thread.interrupted()会清除当前线程的中断标记位。
return Thread.interrupted();
}
这里总结下acquireQueued()方法的流程：
- 结点进入队尾后，检查状态，找到安全休息点；
- 调用park()进入waiting状态，等待unpark()或interrupt()唤醒自己；
- 被唤醒后，看自己是不是有资格能拿到号。如果拿到，head指向当前结点，并返回从入队到拿到号的整个过程中是否被中断过；如果没拿到，继续流程1。
acquire()方法也做一个总结：
- 调用自定义同步器的tryAcquire()尝试直接去获取资源，如果成功则直接返回；
- 没成功，则addWaiter()将该线程加入同步队列的尾部，并标记为独占模式；
- acquireQueued()使线程在同步队列中休息，有机会时（轮到自己，会被unpark()）会去尝试获取资源。获取到资源后才返回。如果在整个等待过程中被中断过，则返回true，否则返回false。
- 如果线程在等待过程中被中断过，它是不响应的。只是获取资源后才再进行自我中断selfInterrupt()，将中断补上。
3.1.2 release(int) 独占锁释放
该方法为释放同步状态，在释放了之后还会唤醒其后继节点，这样后继节点才有机会重新尝试获取同步状态。
public final boolean release(int arg) {
if (tryRelease(arg)) {
Node h = head;//找头节点
if (h != null && h.waitStatus != 0)
unparkSuccessor(h);//唤醒下一节点
return true;
}
return false;
}
/*
*跟tryAcquire()一样，这个方法是需要独占模式的自定义同步器去实现的
*/
protected boolean tryRelease(int arg) {
throw new UnsupportedOperationException();
}
private void unparkSuccessor(Node node) {
/*
* If status is negative (i.e., possibly needing signal) try
* to clear in anticipation of signalling. It is OK if this
* fails or if status is changed by waiting thread.
* ws为当前节点的状态，此时node还是头节点
*/
int ws = node.waitStatus;
if (ws < 0)
compareAndSetWaitStatus(node, ws, 0);//将自身状态置为0
/*
* Thread to unpark is held in successor, which is normally
* just the next node. But if cancelled or apparently null,
* traverse backwards from tail to find the actual
* non-cancelled successor.
*/
Node s = node.next;//下一节点
//如果为空或等待的节点状态已无效（等待超时或被中断，需要从队列里取消等待）
if (s == null || s.waitStatus > 0) {
s = null;
//从后往前找，waitStatus小于0的等待是有效的
for (Node t = tail; t != null && t != node; t = t.prev)
if (t.waitStatus <= 0)
s = t;
}
if (s != null)
LockSupport.unpark(s.thread);//将找到的合适节点唤醒
}
总结一下release(int)方法就是：
一句话概括，用unpark()唤醒同步队列中最前边的那个未放弃线程
上面分析了独占锁的获取与释放，下面来看下共享锁的获取与释放。
共享锁获取锁的过程：
- 当线程调用acquireShared()申请获取锁资源时，如果成功，则进入临界区。
- 当获取锁失败时，则创建一个共享类型的节点并进入一个FIFO同步队列，然后被挂起等待唤醒。
- 当队列中的等待线程被唤醒以后就重新尝试获取锁资源，如果成功则唤醒后面还在等待的共享节点并把该唤醒事件传递下去，即会依次唤醒在该节点后面的所有共享节点，然后进入临界区，否则继续挂起等待。
共享锁释放锁过程：
- 当线程调用releaseShared()进行锁资源释放时，如果释放成功，则唤醒队列中等待的节点，如果有的话。
3.2.1 acquireShared(int) 共享锁获取
共享式获取与独占式获取最主要区别在于同一时刻能否有多个线程同时获取同步状态。
public final void acquireShared(int arg) {
/*
*tryAcquireShared依然需要子类去实现，但返回值的含义已定义好：
*负值代表获取失败；
*0代表获取成功，但没有剩余资源；
*正数表示获取成功，还有剩余资源，其他线程还可以去获取
*/
if (tryAcquireShared(arg) < 0)
doAcquireShared(arg);
}
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) {//获取成功
//将head指向自己，还有剩余资源可以再唤醒之后的线程
setHeadAndPropagate(node, r);
p.next = null; // help GC
//如果等待过程中被打断过，此时将中断补上
if (interrupted)
selfInterrupt();
failed = false;
return;
}
}
//判断状态，寻找安全点，进入waiting状态，等着被unpark()或interrupt()
if (shouldParkAfterFailedAcquire(p, node) &&
parkAndCheckInterrupt())
interrupted = true;
}
} finally {
if (failed)
cancelAcquire(node);
}
}
//将自己设置为头节点，如果还有剩余资源还会唤醒下一临近节点
private void setHeadAndPropagate(Node node, int propagate) {
Node h = head; //记录旧的头节点
setHead(node);//设置新的头节点，不需要CAS
/*
* Try to signal next queued node if:
* Propagation was indicated by caller,
* or was recorded (as h.waitStatus either before
* or after setHead) by a previous operation
* (note: this uses sign-check of waitStatus because
* PROPAGATE status may transition to SIGNAL.)
* and
* The next node is waiting in shared mode,
* or we don't know, because it appears null
*
* The conservatism in both of these checks may cause
* unnecessary wake-ups, but only when there are multiple
* racing acquires/releases, so most need signals now or soon
* anyway.
* 如果还有剩余量，继续唤醒下一个邻居线程
*/
if (propagate > 0 || h == null || h.waitStatus < 0 ||
(h = head) == null || h.waitStatus < 0) {
Node s = node.next;
if (s == null || s.isShared())
doReleaseShared();
}
}
与独占模式相比，共享式获取到资源后，如果有剩余资源还会去唤醒后继节点。
3.2.2 releaseShared() 共享锁释放
如果成功释放且允许唤醒等待线程，它会唤醒同步队列里的其他线程来获取资源。
public final boolean releaseShared(int arg) {
if (tryReleaseShared(arg)) {//尝试释放资源，需要子类实现
doReleaseShared();//唤醒后继节点
return true;
}
return false;
}
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) {
//这里需要控制并发，因为入口有setHeadAndPropagate跟release两个，避免两次unpark
if (!compareAndSetWaitStatus(h, Node.SIGNAL, 0))
continue; // loop to recheck cases
unparkSuccessor(h);//唤醒后继
}
//如果后继节点暂时不需要唤醒，则把当前节点状态设置为PROPAGATE确保以后可以传递下去
else if (ws == 0 &&
!compareAndSetWaitStatus(h, 0, Node.PROPAGATE))
continue;// loop on failed CAS
}
//如果头结点没有发生变化，表示设置完成，退出循环
//如果头结点发生变化，比如说其他线程获取到了锁，为了使自己的唤醒动作可以传递，必须进行重试
if (h == head)// loop if head changed
break;
}
}
这里再提一下关于超时获取资源贴一下代码：
private boolean doAcquireNanos(int arg, long nanosTimeout)
throws InterruptedException {
if (nanosTimeout <= 0L)
return false;
//截止时间
final long deadline = System.nanoTime() + nanosTimeout;
final Node node = addWaiter(Node.EXCLUSIVE);//独占式
boolean failed = true;
try {
for (;;) {
final Node p = node.predecessor();
if (p == head && tryAcquire(arg)) {//尝试获取
setHead(node);
p.next = null; // help GC
failed = false;
return true;
}
//减去尝试获取所花时间
nanosTimeout = deadline - System.nanoTime();
if (nanosTimeout <= 0L)//时间到了或已超时，需要立即返回
return false;
//获取失败后需要等待，且需要等待的时间仍大于1s
//则等待nanosTimeout
//说明下，如果需等待时间已小于1s也进入等待的话，那经过下一轮的
//计算误差会很大，所以只有大于1s才进入等待。
if (shouldParkAfterFailedAcquire(p, node) &&
nanosTimeout > spinForTimeoutThreshold)
LockSupport.parkNanos(this, nanosTimeout);
if (Thread.interrupted())
throw new InterruptedException();
}
} finally {
if (failed)
cancelAcquire(node);
}
}
好了，这里分析完了独占锁与共享的获取与释放，下一篇文章再分析下重入锁，读写锁及锁降级相关的知识点。
在最后再写下几个特别的地方：
- 头节点在唤醒后继节点时为什么要从tail从后往前遍历？
private void unparkSuccessor(Node node) {
// 这里的node 是当前持有锁的节点
int ws = node.waitStatus;
if (ws < 0)
compareAndSetWaitStatus(node, ws, 0);
// 找到头结点的有效的后继节点
Node s = node.next;
//（1）如果为null或状态不对则从尾节点一直向前遍历
if (s == null || s.waitStatus > 0) {
// 大于0的状态只有1，表示被取消了，如果被取消了，就继续取下一个节点唤醒
s = null;
for (Node t = tail; t != null && t != node; t = t.prev)
if (t.waitStatus <= 0)
s = t;
}
//（2）如果上面node.next是一个有效的节点，那这个节点就是要找的节点
if (s != null)
LockSupport.unpark(s.thread);
}这里（下一个节点无效或节点状态大于1的情况）不采用头节点往后遍历的原因是为了避免多线程场景下从前往后获取的节点为null但其实有后继节点而导致同步队列断开的情形，我们再来看下将节点添加到尾部的代码：
private Node enq(final Node node) {
// 空的for循环，自旋操作，直到成功把节点加入到同步队列
for (;;) {
// 同步队列尾巴
Node t = tail;
if (t == null) { // Must initialize
// 尾巴是空的，还没有初始化， 第一个排队的线程进来的话，队头队尾都是同一个节点
if (compareAndSetHead(new Node()))
tail = head;
} else {
// 进入到这里，说明同步队列已经有线程在排队了
// 当前节点前驱直接指向同步队里的尾节点
node.prev = t;//-----1
// CAS 修改尾节点为当前节点
if (compareAndSetTail(t, node)) {//-----2
// t还是老的尾节点，修改新的尾节点后老的尾节点的下一个节点就是当前节点，建立他们的联系
t.next = node;//------3
// 成功把当前节点加入到了同步队列，返回当前节点，退出自旋
return t;
}
}
}先看标识2与3的地方：使用CAS将节点添加到尾节点后，再让之前的尾节点指向自己。显然这不是原子操作，在多线程场景下有可能标识2操作完成后但被挂起，接着其它线程进行了添加尾节点的操作，于是就出现了上面说的s为null但其实有后继节点的情形。
那从尾部往前遍历会有类似问题吗？不会存在，答案就在标识1那个地方，在使用CAS设置尾节点前先将自己的前驱指向之前的尾节点，这样就不存在同步队列断开的情形。那这里会有并发问题吗？其实是不影响的，我们假设下：
- 线程A先执行了node.prev = t将自己前驱指向了之前的尾节点但被挂起。
- 线程B同样执行了node.prev = t，然后使用compareAndSetTail成功将自己设置为新的尾节点并返回。
- 这时线程A获取执行权，尝试使用CAS将自己设置为尾节点，很显然会失败，于是会进入for循环里的下一次尝试，重新获取尾节点再尝试将自己设置为尾节点。
这个知识点参考的文章：
AbstractQueuedSynchronizer源码解读
Java AQS unparkSuccessor 方法中for循环为什么是从tail开始而不是head
- PROPAGATE(-3)节点存在的意义
在很久以前AQS的代码确实是没有PROPAGATE的，PROPAGATE的引入是为了解决共享锁并发释放导致的线程hang住问题。PROPAGATE的值是在获取共享锁成功后设置的：
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);
}
}
private void setHeadAndPropagate(Node node, int propagate) {
Node h = head; // Record old head for check below
setHead(node);
/*
* Try to signal next queued node if:
* Propagation was indicated by caller,
* or was recorded (as h.waitStatus either before
* or after setHead) by a previous operation
* (note: this uses sign-check of waitStatus because
* PROPAGATE status may transition to SIGNAL.)
* and
* The next node is waiting in shared mode,
* or we don't know, because it appears null
*
* The conservatism in both of these checks may cause
* unnecessary wake-ups, but only when there are multiple
* racing acquires/releases, so most need signals now or soon
* anyway.
*/
if (propagate > 0 || h == null || h.waitStatus < 0 ||
(h = head) == null || h.waitStatus < 0) {
Node s = node.next;
if (s == null || s.isShared())
//这个方法是共享锁获取与释放时的共用逻辑
doReleaseShared();
}
}
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;
}
}PROPAGATE的引入是为了解决共享锁并发释放无法唤醒后继节点的问题。
在AQS的共享锁中，一个被park的线程，不考虑线程中断和前驱节点取消的情况，有两种情况可以被unpark：一种是其他线程释放信号量，调用unparkSuccessor；另一种是其他线程获取共享锁时通过传播机制来唤醒后继节点。
在tryAcquireShared方法里，返回负数表示获取失败;返回0表示成功，但是后继线程不会成功;返回正数表示获取成功，并且后继线程也可能成功，这个返回值会作为setHeadAndPropagate方法的入参。
在共享锁获取成功后会调用setHeadAndPropagate设置头节点与传播状态，在这个方法里也会调用doReleaseShared方法，而这个方法在释放共享锁的时候也会调用。在节点获取共享锁(节点成为头节点)成功后的某一时刻，该节点waitStatus可能为SIGNAL(-1)，这是它成为头节点排队的时候它后面的节点设置的。该头节点如果发现还有共享资源它还会尝试唤醒后继节点，在唤醒过程中，如果头节点状态是-1会使用CAS变为0；如果头节点状态是0会使用CAS变为PROPAGATE(-3)。需要说明的是，在之前的JDK版本里并没有PROPAGATE这个状态，会导致在旧版本的setHeadAndPropagate方法里node.waitStatus!=0不成立,从而无法唤醒后继节点。
- 同步队列为什么要是双向的？
其实为什么是双向很好回答：
1，向后的指针：因为头节点释放锁后需要唤醒后继节点，不过这里也分了两种情况：第一种情况是如果后继节点为null或后继节点状态无效(waitStatus>0,被中断或超时)，这时会从后往前寻找（参见3.1.2独占锁的释放代码）；第二种情况是存在有效的后继节点，这就相当于从前往后在寻找，所以队列里节点需要有指向后继节点的指针。
2，向前的指针：线程未获取锁会被包装成节点加入到同步队列里，而在加入过程中需要找到一个‘安全点’进行等待，这个查找过程是从队列尾部向前遍历的(参见3.1.1独占锁的获取代码)，所以需要后面节点记录前面节点的指针。
这个知识点参考的文章：
AbstractQueuedSynchronizer源码解读
AbstractQueuedSynchronizer.java旧版本实现
知乎里关于PROPAGATE的一个问题
java
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用。你还可以使用@来通知其他用户。