深入分析AbstractQueuedSynchronizer独占锁的实现原理：ReentranLock
一、ReentranLock
相信我们都使用过ReentranLock，ReentranLock是Concurrent包下一个用于实现并发的工具类（ReentrantReadWriteLock、Semaphore、CountDownLatch等），它和Synchronized一样都是独占锁，它们两个锁的比较如下：
1. ReentrantLock实现了Lock接口，提供了与synchronized同样的互斥性和可见性，也同样提供了可重入性。
2. synchronized存在一些功能限制：无法中断一个正在等待获取锁的线程，无法获取一个锁时无限得等待下去。ReentrantLock更加灵活，能提供更好的活跃性和性能，可以中断线程
3. 内置锁的释放时自动的，而ReentrantLock的释放必须在finally手动释放
4. 在大并发量的时候，ReentranLock的效率会比Synchronized好很多
5. Lock可以进行可中断的（lock.lockInterruptibly()）、可超时的（tryLock(long time, TimeUnit unit)）、非阻塞（tryLock()）的方式获取锁
更多关于Lock和synchronized：Java并发编程：Lock
一个并发工具自然最基本的功能就是获取锁和释放锁，那么有没有想过，ReentranLock是如何来实现并发的？既然ReentranLock可以中断线程，所以内部自然不可能使用synchronized来实现。事实上，ReentranLock只是一个工具类，它内部的的实现都是通过一个AbstractQueuedSynchronizer（简称AQS）来实现的，AQS是整个Concurrent包中最核心的地方，其它的并发工具也都是使用AQS来实现的，因此，以下我们就通过ReentranLock来分析AQS是如何实现的！
二、AQS
站在使用者的角度，AQS的功能可以分为两类：独占功能和共享功能，它的所有子类中，要么实现并使用了它独占功能的API，要么使用了共享锁的功能，而不会同时使用两套API，即便是它最有名的子类ReentrantReadWriteLock，也是通过两个内部类：读锁和写锁，分别实现的两套API来实现的，为什么这么做，后面我们再分析，到目前为止，我们只需要明白AQS在功能上有独占控制和共享控制两种功能即可
AQS类中，有一个叫做state的成员变量，在ReentranLock他表示获取锁的线程数，假如state=0，表示还没有现成获取锁；1表示已经有现成获取了锁；大于1表示重入的数量
三、ReentranLock的源码
首先我们要对ReentranLock有一个大体的了解，ReentranLock分为公平锁和非公平锁，并且ReentranLock是AQS独占功能的体现
公平锁：每个线程抢占锁的顺序为先后调用lock方法的顺序依次获取锁，就像排队一样
非公平锁：表示获取锁的线程是不定顺序的，谁运气好，谁就获取到锁
可以看到，两个锁都是继承了一个叫做Sync的类，并且都分别有两个方法lock和tryAcquire，那我们看看Sync这个类：
原来，Sync继承自AQS，并且公平锁和非公平锁的两个方法lock和tryAcquire都是重写了Sync的方法，这也就验证了ReentrantLock的实现原理就是AQS
到这里，我们已经有了基本的认识，那么我们就想想，公平锁和非公平锁该如何实现：
有那么一个被volatile修饰的标志位叫做key（其实就是上面所说的AQS中的state），用来表示有没有线程拿走了锁，还需要一个线程安全的队列，维护一堆被挂起的线程，以至于当锁被归还时，能通知到这些被挂起的线程，可以来竞争获取锁了。
因此，公平锁和非公平锁唯一的区别就是获取锁的时候，是先直接去获取锁还是先进入队列中等待
四、ReentranLock的加锁
我们来看看ReentranLock是如何加锁的：
公平锁
公平锁调用lock时，会直接调用父类AQS的acquire方法，这里传入1，很简单，就是告知有一个线程要获取锁，这里是定死的；因此，相反，在释放锁的时候，也是传入1
在acquire中，首先调用tryAcquire，目的尝试获取锁，如果获取不到，就调用addWaiter创建一个waiter（当前线程）防止到队列中，然后自身阻塞，那我们来看看如何尝试获取锁？（注意：两个锁都重写了AQS的tryAcquire方法）
protected final boolean tryAcquire(int acquires) {
//首先得到获取锁的当前线程
final Thread current = Thread.currentThread();
//获取当前state
int c = getState();
//如果当前没有线程获取锁
if (c == 0) {
//hasQueuedPredecessors表示当前队列是否有线程在等待
//表示没有线程在等待，同时采用CAS更新state的状态
if (!hasQueuedPredecessors() &&
compareAndSetState(0, acquires)) {
//然后设置一个属性exclusiveOwnerThread = current，记录锁被当前线程拿去
setExclusiveOwnerThread(current);
return true;
}
}
//如果c != 0，说明已经有线程获取锁，并且getExclusiveOwnerThread == current,表示当前正在获取锁的就是当前锁，所以这里是重入！
else if (current == getExclusiveOwnerThread()) {
//重入的话，让状态为state+1，表示多一次重入
int nextc = c + acquires;
//如果当前状态<0，说明出现异常
if (nextc < 0)
throw new Error("Maximum lock count exceeded");
//设置当前标志位
setState(nextc);
return true;
}
//如果锁已经被获取，并且又不是重入，所以返回false，表明获取锁失败
return false;
}
} 获取锁的逻辑上面说得很明白了，但是这里需要了解的是CAS操作和队列的数据结构，这个下面在说，我们接着看，回到tryAcquire中
如果获取锁成功，则不操作；如果获取锁失败，则调用addWaiter并采取Node.EXECLUSIVE模式把当前线程放到队列中去，mode是一个表示Node类型的字段，仅仅表示这个节点是独占的，还是共享的
private Node addWaiter(Node mode) {
//把当前线程按照Node.EXECLUSIVE模式包装成1个Node
Node node = new Node(Thread.currentThread(), mode);
//用pred表示队列中的尾节点
Node pred = tail;
//如果尾节点不为空
if (pred != null) {
node.prev = pred;
//通过CAS操作把node插入到列表的尾部，并把尾节点指向node如果失败，说明有并发，此时调用enq
if (compareAndSetTail(pred, node)) {
pred.next = node;
return node;
}
}
//如果队列为空，或者CAS失败，进入enq中死循环，“自旋”方式修改。
enq(node);
return node;
} 先看下AQS中队列的内存结构，我们知道，队列由Node类型的节点组成，其中至少有两个变量，一个封装线程，一个封装节点类型。
而实际上，它的内存结构是这样的（第一次节点插入时，第一个节点是一个空节点，代表有一个线程已经获取锁，事实上，队列的第一个节点就是代表持有锁的节点）：
private Node enq(final Node node) {
//进入死循环
for (;;) {
Node t = tail;
//如果尾节点为null，说明队列为空
if (t == null) {
//此时通过CAS增加一个头结点(即上图的黄色节点)，并且tail也指向头结点，之后下一次循环
if (compareAndSetHead(new Node()))
tail = head;
} else {//否则，把当前线程的node插入到尾节点的后面
node.prev = t;
if (compareAndSetTail(t, node)) {
t.next = node;
//并返回插入结点的前一个节点
return t;
}
}
}
}这就完成了线程节点的插入，还需要做一件事：将当前线程挂起！，这里在acquireQueued内通过parkAndCheckInterrupt将线程挂起
final boolean acquireQueued(final Node node, int arg) {
boolean failed = true;
try {
boolean interrupted = false;
for (;;) {
final Node p = node.predecessor();
//如果当前的节点是head说明他是队列中第一个“有效的”节点，因此尝试获取，
if (p == head && tryAcquire(arg)) {
//成功后，将上图中的黄色节点移除，Node1变成头节点。
setHead(node);
p.next = null; // help GC
failed = false;
//返回true表示已经插入到队列中，且已经做好了挂起的准备
return interrupted;
}
//否则，检查前一个节点的状态为，看当前获取锁失败的线程是否需要挂起。如果需要，借助JUC包下的LockSopport类的静态方法Park挂起当前线程。知道被唤醒。
if (shouldParkAfterFailedAcquire(p, node) && parkAndCheckInterrupt())
interrupted = true;
}
} finally {
if (failed) //如果有异常
cancelAcquire(node);// 取消请求，对应到队列操作，就是将当前节点从队列中移除。
}
}这块代码有几点需要说明：
1. Node节点中，除了存储当前线程，节点类型，队列中前后元素的变量，还有一个叫waitStatus的变量，改变量用于描述节点的状态，为什么需要这个状态呢？
原因是：AQS的队列中，在有并发时，肯定会存取一定数量的节点，每个节点[G4] 代表了一个线程的状态，有的线程可能“等不及”获取锁了，需要放弃竞争，退出队列，有的线程在等待一些条件满足，满足后才恢复执行（这里的描述很像某个J.U.C包下的工具类，ReentrankLock的Condition，事实上，Condition同样也是AQS的子类）等等，总之，各个线程有各个线程的状态，但总需要一个变量来描述它，这个变量就叫waitStatus,它有四种状态：
节点取消
节点等待触发
节点等待条件
节点状态需要向后传播。
只有当前节点的前一个节点为SIGNAL时，才能当前节点才能被挂起。
2. 对线程的挂起及唤醒操作是通过使用UNSAFE类调用JNI方法实现的。当然，还提供了挂起指定时间后唤醒的API，在后面我们会讲到。
（这一块分析来自：http://www.infoq.com/cn/articles/jdk1.8-abstractqueuedsynchronizer#anch140431）
我们来理一理思路：
1. 调用lock方法获取锁，而lock方法内值调用了AQS的acquire(1)
2. 然后尝试获取锁，如果当前state标志==0，表示还没有线程获取锁，然后再判断是否有队列在等待获取该锁，如果没有队列，说明当前线程是第一个获取该锁的线程，然后修改标志位，并且用一个变量exclusiveOwnerThread来记录当前线程获取了锁
3. 如果是重入状态，也修改state+1
4. 如果锁已被占取，获取失败
5. 如果获取失败，则把当前线程包装成一个Node，插入到队列中，
6. 否则，检查前一个节点的状态为，看当前获取锁失败的线程是否需要挂起。如果需要，借助JUC包下的LockSopport类的静态方法Park挂起当前线程。知道被唤醒。
非公平锁
这里可以看到，非公平锁，首先是直接去获取锁，如果有并发获取失败，调用AQS的acquire（1），然后acquire中调用非公平锁的tryAcquire，进而调用nonfairTryAcquire
final boolean nonfairTryAcquire(int acquires) {
final Thread current = Thread.currentThread();
int c = getState();
//如果当前没有现成获取锁，直接获取锁，然后设置一个属性exclusiveOwnerThread = current，记录锁被当前线程拿去，这里和公平所有细微的差别，公平所还要判断hasQueuedPredecessors（）
if (c == 0) {
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;
}
//如果当前锁获取失败，返回false
return false;
}其它的都和公平锁一样了，如果到这里都获取失败了，就会插入到队列中阻塞起来
总结公平锁和非公平锁
- 公平锁获取锁时，会老老实实得走AQS的流程去获取锁
- 非公平锁获取锁是，首先会抢占锁，达到不排队的目的，如果抢占失败，只能老老实实排队了
五、ReentrantLock的释放锁
从上面我们可以知道，当锁已被占，获取锁的线程会一直在队列中排队（FIFO），那么我们想想，释放的时候该怎么做？
1. 首先锁的状态位要改变
2. 队列中的头结点去获取锁
我们来看看代码验证一下：
释放锁的时候调用unlock()，然后在方法中调用AQS的release方法
在release方法中，首先调用tryRelease方法，由于继承自AQS的Sync类重写了tryRelease方法，所以此时执行的是Sync的tryRelease方法
protected final boolean tryRelease(int releases) {
//这里传入的releases是1，跟获取锁时传入的1一致，更新state状态
int c = getState() - releases;
//如果当前占领锁的线程不是尝试释放锁的线程，会抛出非法异常
if (Thread.currentThread() != getExclusiveOwnerThread())
throw new IllegalMonitorStateException();
boolean free = false;
//如果释放成功，则修改获取锁的变量为null，但是因为是重入的关系，不是每次释放锁c都等于0，直到最后一次释放锁时，才通知AQS不需要再记录哪个线程正在获取锁
if (c == 0) {
free = true;
setExclusiveOwnerThread(null);
}
setState(c);
return free;
} 此时已经释放了锁，然后便通知队列头部的线程去获取锁
寻找的顺序是从队列尾部开始往前去找的最前面的一个waitStatus小于0的节点，找到这个及节点后，利用LockSopport类将其唤醒，这个waitStatu前面说过了，不记得了到前面看看。
六、总结
在Concurrent包中，基本上并发工具都是使用了AQS作为核心，因此AQS也是并发编程中最重要的地方！我们从ReentrantLock出发，去探讨了AQS的实现原理，其实并不难，AQS中采用了一个state的状态位+一个FIFO的队列的方式，记录了锁的获取，释放等，这个state不一定用来代指锁，ReentrantLock用它来表示线程已经重复获取该锁的次数，Semaphore用它来表示剩余的许可数量，FutureTask用它来表示任务的状态（尚未开始，正在运行，已完成以及以取消）。同时，在AQS中也看到了很多CAS的操作。AQS有两个功能：独占功能和共享功能，而ReentranLock就是AQS独占功能的体现，而CountDownLatch则是共享功能的体现