本系列是基于经验设计原型，然后不断优化最终达到和AQS（AbstractQueuedSynchronizer）类似的设计。最终结果不一定和AQS完全一致，基于个人理解会有修改，可以作为理解AQS的不完全参考。 接上篇。本篇主要介绍Condition即条件变量的实现，ReentrantLock中最后一块需要实现的内容。 在实现条件变量之前，考虑一下条件变量的一些特性。 条件变量依赖锁，而且是独占锁 执行await方法后释放锁，当前线程进入睡眠状态，等待满足条件后被其他线程signal/signalAll唤醒，被唤醒后会尝试重新获取锁 唤醒可以选择一个也可以全部 注意第一条特性，条件变量依赖的是独占锁，所以类似读锁这种共享锁是不支持条件变量的，ReentrantReadWriteLock中ReadLock#newCondition的实现是直接抛错。 按照第二条特性，可以得到如下的执行过程

接着上篇，本篇主要介绍如何添加限时tryLock方法。介绍完之后，ReentrantLock除了condition之外都会实现，而且基本和实际ReentrantLock代码接近。上篇也提到过，实际ReentrantLock依赖AQS，但是本文不会直接介绍AQS，只是AQS的一个不完全分析。 顺便提一下，“自己写ReentrantLock和ReentrantReadWriteLock”由于篇幅比较长，预计会分成3到4篇左右。 在进入限时tryLock方法的介绍之前，考虑一个问题：上篇中FairLock1和UnfairLock1是否可以复用Node？ 为什么要问这个问题？因为C++代码比较关注对象的生命周期。使用C++实现锁的话必须关注何时可以回收Node的内存。如果你了解CLHLock的话，可以知道CLHLock是可以复用Node的，最多是N个（线程）+1个（哨兵）Node，理论上不需要回收。所以和CLHLock基本一致的FairLock1，同样可以用类似CLHLock的方式，即复用前序节点为自己的当前节点（CLHLock是复用前序节点的，至于为什么可以参阅CLHLock的介绍）。UnfairLock1中由于可能是非公平模式，不知道前序节点是谁，也就无法简单复用了。

最近个人在研究如何实现Transaction Memory，这其实也是受《the art of multiprocessor programming》最后一章的影响。作为研究的一部分，个人需要一个类似ReadWriteLock语义的同步器，于是分析了一下现有ReentrantLock和ReentrantReadWriteLock。在分析之前我其实知道ReentrantLock和ReentrantReadWriteLock都是基于AbstractQueuedSynchronizer，所以本篇也可以作为AbstractQueuedSynchronizer的不完全分析。 首先从ReentrantLock开始分析。最简单的不公平模式，无等待（SPIN，PARK）的锁。