最近一段时间在研究jdk里的concurrent包，分为了线程管理，锁操作以及原子操作三个部分。线程管理平时用得还算多，但是锁操作和原子操作基本就没用过，只是以前在大学的时候跑了几个例子玩玩。当看到reentrantlock的时候，发现用法倒是和synchronized有点类似也很简单，但是内部原理比较复杂。网上查了关于reentrantlock的相关内容，没发现有谁把它分析得很透彻，只是有几篇讲了内部的锁实现机制，只可惜都是以文字为主，难以把整个内部流程串起来理解，相信很多人没有真正把这个新的同步机制搞明白，当然也包括我在内。所以花了几天时间反复调试，终于把最基础的lock-unlock以及与reentrantlock绑定的condition的await-signal机制以流程图的形式画了出来，同时把我认为较为难理解的代码也分析了其内部原理加以注释，以此分享给大家，希望能帮助各位更快的理解它的实现原理，也欢迎批评指正。
目前只是研究了正常状态下的同步原理，如果存在线程中断，其流程将更为复杂。所以暂时先上两篇无中断的流程讲解，待我能把带中断的流程整理清楚了再发出来，以免误导大家。
在jdk1.5之前，多线程之间的同步是依靠synchronized来实现。synchronized是java的关键字，直接由jvm解释成为指令进行线程同步管理。因为操作简单，而且现在jdk的后续版本已经对synchronized进行了很多的优化，所以一直是大家编写多线程程序常用的同步工具。那为什么要推出新的同步api呢？jdk1.5发布的时候，synchronized性能并不好，这可能是concurrent包出现的一个潜在原因，但是更重要的是新的api提供了更灵活，更细粒度的同步操作，以满足不同的需求。但是问题也很明显，越灵活可控度越高就越容易出错，所以大多数人很少使用concurrent里的同步锁api。本文并不比较两者的优劣，毕竟存在即合理。能把更高级的工具用好，有时候提高工作效率，加快异常排查也是很不错的，不过本人是出于学习其原理及思想才进行研究，工作中用哪一个同样也会谨慎抉择。
reentrantlock类图：
abstractownablesynchronizer类保持和获取独占线程。
abstractqueuedsynchronizer是以虚拟队列的方式管理线程的锁获取与锁释放，以及各种情况下的线程中断。提供了默认的同步实现，但是获取锁和释放锁的实现定义为抽象方法，由子类实现。目的是使开发人员可以自由定义获取锁以及释放锁的方式。
sync是reentrantlock的内部抽象类，实现了简单的获取锁和释放锁。
nonfairsync和fairsync分别表示“非公平锁”和“公平锁”，都继承于sync，并且都是reentrantlock的内部类。
reentrantlock实现了lock接口的lock-unlock方法，根据fair参数决定使用nonfairsync还是fairsync。
这里面有两个重点内容：
abstractqueuedsynchronizer内部的node
abstractqueuedsynchronizer内部的state
node：
node是对每一个访问同步代码的线程的封装。不仅包括了需要同步的线程，而且也包含了每个线程的状态，比如等待解除阻塞，等待条件唤醒，已经被取消等等。同时node还关联了前驱和后继，即prev和next。个人认为是为了以集中的方式管理多个不同状态的线程，当不同的线程发生状态改变时，可以尽快的反应到别的线程上，提高运行效率。比如某个node的prev已经被取消了，那么当对这个prev解除阻塞的时候就可以被忽略掉，进而尝试解除该node的阻塞状态。
多个node连接起来成为了虚拟队列（因为不存在真正的队列容器将每个元素装起来所以说是虚拟的，我把它称为release队列，意思是等待释放），那么就得有head和tail。针对公平锁，head是不带线程的特殊node，只有next，而最新一个请求锁的线程取锁失败时就把它添加到队尾，即tail。但是对于非公平锁，新请求锁的线程会插队，也许会插到最前面，也许不会。
这里可能有人会有疑问：head放在队列中有什么用处？为什么不是一个等待锁的线程作为head呢？原因很简单，因为每个等待线程都有可能被中断而取消，对于一个已经取消的线程，自然是有机会就把它gc了。那么gc前一定得让后续的node成为head，这样一来sethead的操作过于分散，而且要应对多种线程状态的变化来设置head，这样就太麻烦了。所以这里很巧妙地将head的next设置为等待锁的node，head就相当于一个引导的作用，因为head没有线程，所以不存在“取消”这种状态。
state：
state是用来记录锁的持有情况。
没有线程持有锁的时候，state为0。
当某个线程获取锁时，state的值增加，具体增加多少开发人员可自定义，默认为1，表示该锁正在被一个线程占有。
当某个已经占用锁的线程再次获取到锁时，state再增长，此为重入锁。
当占有锁的线程释放锁时，state也要减去当初占有时传入的值，默认为1。
多个线程竞争锁的时候，state必须通过cas进行设置，这样才能保证锁只能有一个线程持有。当然这是排它锁的规则，共享锁就不是这样了。
公平锁和非公平锁的不同仅在于修改state的时机。看下面的代码就能明白：
// reentrantlock.class
protected final boolean tryacquire(int acquires) {
final thread current = thread.currentthread();
int c = getstate();
if (c == 0) {
// 此为公平锁的实现，而非公平锁不调用hasqueuedpredecessors方法，即不需要判断队列里是否有内容，直接通过cas修改state来竞争锁
if (!hasqueuedpredecessors() &&
compareandsetstate(0, acquires)) {
setexclusiveownerthread(current);
return true;
}
}
else if (current == getexclusiveownerthread()) {
int nextc = c + acquires;
if (nextc < 0)
throw new error("maximum lock count exceeded");
setstate(nextc);
return true;
return false;
}
基本上把node和state的意义弄明白了，一个正常的lock-unlock过程应该很容易明白。但是代码里有很多地方要针对已取消的线程做特殊处理，所以理解上还是会有困难。因为已经有几篇文章进行了源码讲解，所以这里我就不再把每段源代码都拿出来细讲了。
先看看lock()的流程：（图中的node0和node1在源代码中不存在，是我为了方便说明清楚才添加的别称）
如图所示，彩色的字都是一个cas操作，其中三个红色cas都对成功和失败有相应地处理，为什么另外一个蓝色cas不关心设置是否成功呢？下面这段代码里我给出了解释：
// abstractqueuedsynchronizer.class
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.
*/
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.
* 为什么不关心是否成功却还要设置呢？
*
* 如果设置失败，表示前驱已经被signal了。如果前驱是head，说明有机会获取锁，所以返回false后还可以再次tryacquire
* 如果设置成功，表示前驱等待signal。如果再次确认pred.waitstatus仍然是node.signal，则表明前驱等待释放锁的情况下必须阻塞当前线程
* 所以返回true后即被park
compareandsetwaitstatus(pred, ws, node.signal);
再看下unlock()的流程图：
如图所示，这里的粉红色折线与lock流程图里的粉红色虚折线对应，即线程a调用lock阻塞与线程b调用unlock解除线程a的阻塞。同时可以看到unlock只有一个cas操作，但是也不用关心设置是否成功。我给这段代码做了下面解释：
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.
*/
int ws = node.waitstatus;
* 为什么不关心是否成功却还要设置呢？
*
* 注意这里的node实际就是head
*
* 如果设置成功，即head.waitstatus=0，则可以让这时即将被阻塞的线程有机会再次调用tryacquire获取锁。
* 也就是让shouldparkafterfailedacquire方法里的compareandsetwaitstatus(pred, ws, node.signal)执行失败返回false，这样就能再有机会再tryacquire了
* 如果设置失败，新跟随在head后面的线程被阻塞，但是没关系，下面的代码会立即将这个阻塞线程释放掉
if (ws < 0)
compareandsetwaitstatus(node, ws, 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;
for (node t = tail; t != null && t != node; t = t.prev)
if (t.waitstatus <= 0)
s = t;
if (s != null)
locksupport.unpark(s.thread);
以上的两段代码说明是我觉得比较难理解的，虽然有英文注释，但是却没说明为什么这么做，我也是反复调试才想明白。但是不得不说这两段代码的巧妙，尽可能利用cas操作减少阻塞的机会，让线程能有更多机会获取锁，毕竟阻塞线程是内核操作，开销不小。
本篇只讲了普通的lock-unlock，下篇会讲讲等待-通知，即condition的await-signal的详细流程
参考资料：