副标题#e#
媒介
Java中的FutureTask作为可异步执行任务并可获取执行功效而被各人所熟知。凡是可以利用future.get()来获取线程的执行功效，在线程执行竣事之前，get要了解一直阻塞状态，直到call()返回，其利益是利用线程异步执行任务的环境下还可以获取到线程的执行功效，可是FutureTask的以上成果却是依靠通过一个叫AbstractQueuedSynchronizer的类来实现，至少在JDK 1.5、JDK1.6版本是这样的（从1.7开始FutureTask已经被其作者Doug Lea修改为不再依赖AbstractQueuedSynchronizer实现了，这是JDK1.7的变革之一）。可是AbstractQueuedSynchronizer在JDK1.8中尚有如下图所示的浩瀚子类：
这些JDK中的东西类或多或少都被各人用过不止一次，好比ReentrantLock，我们知道ReentrantLock的成果是实现代码段的并发会见节制，也就是凡是意义上所说的锁，在没有看到AbstractQueuedSynchronizer前，大概会觉得它的实现是通过雷同于synchronized，通过对工具加锁来实现的。但事实上它仅仅是一个东西类！没有利用更“高级”的呆板指令，不是要害字，也不依靠JDK编译时的非凡处理惩罚，仅仅作为一个普普通通的类就完成了代码块的并发会见节制，这就更让人疑问它怎么实现的代码块的并发会见节制的了。那就让我们一起来仔细看下Doug Lea怎么去实现的这个锁。为了利便，本文中利用AQS取代AbstractQueuedSynchronizer。
独有锁
在真正对解读AQS之前，我想先从利用了它独有节制成果的子类ReentrantLock说起，阐明ReentrantLock的同时看一看AQS的实现，再推理出AQS奇特的设计思路和实现方法。最后，在看其共享节制成果的实现。
对付ReentrantLock，利用过的同学应该都知道，凡是是这么用它的：
reentrantLock.lock()
//do something
reentrantLock.unlock()
ReentrantLock会担保 do something在同一时间只有一个线程在执行这段代码，可能说，同一时刻只有一个线程的lock要了解返回。其余线程会被挂起，直到获取锁。从这里可以看出，其实ReentrantLock实现的就是一个独有锁的成果：有且只有一个线程获取到锁，其余线程全部挂起，直到该拥有锁的线程释放锁，被挂起的线程被叫醒从头开始竞争锁。没错，ReentrantLock利用的就是AQS的独有API实现的。
那此刻我们就从ReentrantLock的实现开始一起看垂青入锁是怎么实现的。
首先看lock要领：
如FutureTask（JDK1.6）一样，ReentrantLock内部有署理类完成详细操纵，ReentrantLock只是封装了统一的一套API罢了。值得留意的是，利用过ReentrantLock的同学应该知道，ReentrantLock又分为公正锁和非公正锁之分，所以，ReentrantLock内部只有有两个sync的实现：
#p#副标题#e#
公正锁：每个线程抢占锁的顺序为先后挪用lock要领的顺序依次获取锁，雷同于列队用饭。
非公正锁：每个线程抢占锁的顺序不定，谁命运好，谁就获取到锁，和挪用lock要领的先后顺序无关，雷同于堵车时，加塞的那些XXXX。
到这里，通过ReentrantLock的成果和锁的所谓排不列队的方法，我们是否可以这么揣摩ReentrantLock可能AQS的实现（此刻不清楚谁去实现这些成果）：有那么一个被volatile修饰的符号位叫做key，用来暗示有没有线程拿走了锁，可能说，锁还存不存在，还需要一个线程安详的行列，维护一堆被挂起的线程，以至于当锁被偿还时，能通知到这些被挂起的线程，可以来竞争获取锁了。
至于公正锁和非公正锁，独一的区别是在获取锁的时候是直接去获取锁，照旧进入行列列队的问题了。为了验证我们的意料，我们继承看一下ReentrantLock中公正锁的实现、
挪用到了AQS的acquire要领，
从要领名字上看语义是，实验获取锁，获取不到则建设一个waiter（当前线程）后放到行列中，这和我们揣摩的仿佛很雷同。[G1]
先看下tryAcquire要领:
留空了，Doug Lea是想留给子类去实现（既然要给子类实现，应该用抽象要领，可是Doug Lea没有这么做，原因是AQS有两种成果，面向两种利用场景，需要给子类界说的要领都是抽象要领了，会导致子类无论如何都需要实现别的一种场景的抽象要领，显然，这对子类来说是不友好的。）
看下FairSync的tryAcquire要领：
getState要领是AQS的要领，因为在AQS内里有个叫statede的符号位 :
事实上，这个state就是前面我们意料的谁人“key”！
#p#分页标题#e#
回到tryAcquire要领：
protected final boolean tryAcquire(int acquires) {
final Thread current = Thread.currentThread();//获取当前线程
int c = getState(); //获取父类AQS中的符号位
if (c == 0) {
if (!hasQueuedPredecessors() &&
//假如行列中没有其他线程 说明没有线程正在占有锁！
compareAndSetState(0, acquires)) {
//修改一下状态位，留意：这里的acquires是在lock的时候通报来的，从上面的图中可以知道，这个值是写死的1
setExclusiveOwnerThread(current);
//假如通过CAS操纵将状态为更新乐成则代表当前线程获取锁，因此，将当前线程配置到AQS的一个变量中，说明这个线程拿走了锁。
return true;
}
}
else if (current == getExclusiveOwnerThread()) {
//假如不为0 意味着，锁已经被拿走了，可是，因为ReentrantLock是重入锁，
//是可以反复lock,unlock的，只要成对呈现行。一次。这里还要再判定一次 获取锁的线程是不是当前请求锁的线程。
int nextc = c + acquires;//假如是的，累加在state字段上就可以了。
if (nextc < 0)
throw new Error("Maximum lock count exceeded");
setState(nextc);
return true;
}
return false;
}
到此，假如假如获取锁，tryAcquire返回true，反之，返回false，回到AQS的acquire要领。
假如没有获取到锁，凭据我们的描写，应该讲当前线程放到行列中区，只不外，在放之前，需要做些包装。
先看addWaiter要领：
用当前线程去结构一个Node工具，mode是一个暗示Node范例的字段，仅仅暗示这个节点是独有的，照旧共享的，可能说，AQS的这个行列中，哪些节点是独有的，哪些是共享的。
这里lock挪用的是AQS独有的API，虽然，可以写死是独有状态的节点。
建设好节点后，将节点插手到行列尾部，此处，在行列不为空的时候，先实验通过cas方法修改尾节点为最新的节点，假如修改失败，意味着有并发，这个时候才会进入enq中死轮回，“自旋”方法修改。
将线程的节点接入到队里中后，当让还需要做一件事:将当前线程挂起！这个事，由acquireQueued来做。
在表明acquireQueued之前，我们需要先看下AQS中行列的内存布局，我们知道，行列由Node范例的节点构成，个中至少有两个变量，一个封装线程，一个封装节点范例。
而实际上，它的内存布局是这样的（第一次节点插入时，第一个节点是一个空节点，代表有一个线程已经获取锁，事实上，行列的第一个节点就是代表持有锁的节点）：
黄色节点为行列默认的头节点，每次有线程竞争失败，进入行列后其实都是插入到头节点后头。这个从enq要领可以看出来，上文中有提到enq要领为将节点插入行列的要领:
再返来看看
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)) {
//假如当前的节点是head说明他是行列中第一个“有效的”节点，因此实验获取，上文中有提到这个类是交给子类去扩展的。
setHead(node);//乐成后，将上图中的黄色节点移除，Node1酿成头节点。
p.next = null; // help GC
failed = false;
return interrupted;
}
if (shouldParkAfterFailedAcquire(p, node) &&
//不然，查抄前一个节点的状态为，看当前获取锁失败的线程是否需要挂起。
parkAndCheckInterrupt())
//假如需要，借助JUC包下的LockSopport类的静态要领Park挂起当前线程。知道被叫醒。
interrupted = true;
}
} finally {
if (failed) //假如有异常
cancelAcquire(node);// 打消请求，对应到行列操纵，就是将当前节点从行列中移除。
}
}
这块代码有几点需要说明：
#p#分页标题#e#
1. Node节点中，除了存储当前线程，节点范例，行列中前后元素的变量，尚有一个叫waitStatus的变量，改变量用于描写节点的状态，为什么需要这个状态呢？
原因是：AQS的行列中，在有并发时，必定会存取必然数量的节点，每个节点[G4] 代表了一个线程的状态，有的线程大概大概“等不及”获取锁了，需要放弃竞争，退出行列，有点线程在期待一些条件满意，满意后才规复执行（这里的描写很像某个J.U.C包下的东西类，ReentrankLock的Condition，事实上，Condition同样也是AQS的子类）等等，总之，各个线程有各个线程的状态，但总需要一个变量买描写它，这个变量就叫waitStatus,它有四种状态：
别离暗示：
节点打消
节点期待触发
节点期待条件
节点状态需要向后流传。
只有当前节点的前一个节点为SIGNAL时，才气当前节点才气被挂起。
2. 对线程的挂起及叫醒操纵是通过利用UNSAFE类挪用JNI要领实现的。虽然，还提供了挂起指按时间后叫醒的API，在后头我们会讲到。
到此为止，一个线程对付锁的一次竞争才告一段落，功效又两种，要么乐成获取到锁（不消进入到AQS行列中，），要么，获取失败，被挂起，期待下次叫醒后继承轮回实验获取锁，值得留意的是，AQS的行列为FIFO行列，所以，每次实时被CPU假叫醒，且当前线程不是出在头节点的位置，也是会被挂起的。AQS通过这样的方法，实现了竞争的列队计策。
看完了获取锁，在看看释放锁，详细看代码之前，我们可以先继承猜下，释放操纵需要做哪些工作：
因为获取锁的线程的节点，此时在AQS的头节点位置，所以，大概需要将头节点移除。
而应该是直接释放锁，然后找到AQS的头节点，通知它可以来竞争锁了。
是不是这样呢?我们继承来看下，同样我们用ReentrantLock的FairSync来说明：
unlock要领挪用了AQS的release要领，同样传入了参数1，和获取锁的相应对应，获取一个锁，标示为+1，释放一个锁，符号位-1。
同样，release为空要领，子类本身实现逻辑：
protected final boolean tryRelease(int releases) {
int c = getState() - releases;
if (Thread.currentThread() != getExclusiveOwnerThread()) //假如释放的线程和获取锁的线程不是同一个，抛出犯科监督器状态异常。
throw new IllegalMonitorStateException();
boolean free = false;
if (c == 0) {//因为是重入的干系，不是每次释放锁c都便是0，直到最后一次释放锁时，才通知AQS不需要再记录哪个线程正在获取锁。
free = true;
setExclusiveOwnerThread(null);
}
setState(c);
return free;
}
释放锁，乐成后，找到AQS的头节点，并叫醒它即可：
值得留意的是，寻找的顺序是从行列尾部开始往前去找的最前面的一个waitStatus小于0的节点。
到此，ReentrantLock的lock和unlock要领已经根基理会完毕了，唯独还剩下一个非公正锁NonfairSync没说，其实，它和公正锁的独一区别就是获取锁的方法差异，一个是按前后顺序一次获取锁，一个是抢占式的获取锁，那ReentrantLock是怎么实现的呢？再看两段代码：
非公正锁的lock要领的处理惩罚方法是: 在lock的时候先直接cas修改一次state变量（实验获取锁），乐成绩返回，不乐成再列队，从而到达不列队直接抢占的目标。
而对付公正锁：则是老诚恳实的开始就走AQS的流程列队获取锁。假如前面有人挪用过其lock要领，则排在行列中前面，也就更有时机更早的获取锁，从而到达“公正”的目标。
总结
#p#分页标题#e#
这篇文章，我们从ReentrantLock出发，完整的阐明白AQS独有成果的API及内部实现，总的来说，思路其实并不巨大，照旧利用的符号位+行列的方法，记录获取锁、竞争锁、释放锁等一系列锁的状态，或者用更精确一点的描写的话，应该是利用的符号位+行列的方法，记录锁，竞争，释放等一系列独有的状态，因为站在AQS的层面state可以暗示锁，也可以暗示其他状态，它并不体贴它的子类把它酿成一个什么东西类，而只是提供了一套维护一个独有状态。甚至，最精确的是AQS只是维护了一个状态，因为，别忘了，它尚有一套共享状态的API，所以，AQS只是维护一个状态，一个节制各个线程何时可以会见的状态，它只对状态认真，而这个状态暗示什么寄义，由子类本身去界说。
