从源码学习Java并发的锁是怎么维护内部线程队列的
在上一篇文章中，凯哥对同步组件基础框架- AbstractQueuedSynchronizer(AQS)做了大概的介绍。我们知道AQS能够通过内置的FIFO队列来完成资源获取线程的排队工作。那么AQS是怎么来维护这个排队工作的呢？今天我们就来扒一扒AQS源码。从源码中来看看是怎么维护对了的。
本篇是《凯哥(凯哥Java:kagejava)并发编程学习》系列之《Lock系列》教程的第一篇：《Java并发包下锁学习第三篇-从源码学习Java并发是怎么维护内部线程队列的》。
在上篇我们知道AQS内部有个内部类-Node对象。这个对象就是来维护线程对资源访问的排队工作的。具体怎么操作的呢？本文主要内容：Node节点介绍；在同步器中怎么为维护排队的流程图。
一：Node节点对象介绍
在AQS内部有个Node对象的内部类。我们来看看这个对象都有哪些属性：
简化后：
static final class Node {
//线程等待状态
volatile int waitStatus;
//当前节点的上一个节点
volatile Node prev;
//当前节点对象
volatile Node next;
//当前节点维护的线程对象
volatile Thread thread;
//当前节点的下一个(后续)节点
Node nextWaiter;
}
对象中属性介绍
Int waitStatus:
对象里面有表示状态的4个属性：
static final int CANCELLED = 1：线程从同步队列中取消
static final int SIGNAL = -1：后续节点等待状态。当前节点在获取到资源后，在释放前需要断开和后续节点的连接。在其释放后，会通知后续节点，使后续解决继续运行。
static final int CONDITION = -2：当前节点等待中。在等待condition通知。也可以理解成在condition队列中。
static final int PROPAGATE = -3：在共享模式下，下一次无条件传播
0：默认状态。
Node prev：当前节点的上一个节点
Node Next：当前解决的后续节点
Node nextWaiter：可以理解为节点的类型。是共享式还是独占式。
Thread thread：当前获取到同步状态的线程对象。
具体可以如下图：
首先，我们需要明白，在数据结构中，能够保持FIFO的结构是队列模式的。但是队列有单项队列和循环队列两种。那么，同步器使用的是哪个队列方式呢？
从Node节点属性中，我们可以看到前节点和后续节点的属性。说明使用的是循环队列。
二：维护线程排队的流程图
为了保证线程的安全，同步器提供了几个CAS的方法。如下图：
CAS设置头节点、设置下一个节点、设置状态、设置尾节点等。
操作流程可以简述如下图：
流程说明：
入队列
入队流程如下：
上图流程说明：
当多个线程同时来争夺资源的时候，其中一个线程获取到了资源(同步状态或者是锁)，这个时候获取到资源的线程就会被构造成头节点。其他线无非获取到资源的线程会被构成成Node节点对象并被放到队列中。被构造成Node节点的线程会排在队列尾部排队。为了保证线程安全性，同步器会基于CAS设置尾节点的方法(即：compareAndSetTail ())来保持线程安全性.这个方法需要传递当前线程“自己认为”的尾节点和前一个节点，当CAS执行成功之后，当前节点才会正式与之前的节点建立关系。被设置尾部的Node节点的next将指向头节点。
如上图中线程3会和线程1执行类似的操作，把自己添加到队列的尾部。这样就形成了一个完整的双向队列排队了。
出队列
出队流程图如下：
出队流程说明：
从入队流程图中我们可以看出，所有争夺资源并发的线程都被排队了。同步队列遵循FIFO(先进先出)。所谓的首节点就是获取同步状态成功节点。当来的首节点中的线程在释放同步状态的时候，会断开自己与后续节点的关联关系，然后会唤醒后续节点操作的。当后续节点获取同步状态成功的时候，就将自己设置为首节点，原来的首节点就退出了队列。如果原来的首节点还需要获取的话，后将自己线程构造成Node节点对象，然后进行排队。
