一、前言
AbstractQueuedSynchronizer 简称 AQS，是一个抽象类的队列式同步器，它的内部通过维护一个状态volatile int state(共享资源)，一个FIFO线程等待队列来实现同步功能。可能我们几乎不会直接去使用它，但它却是 JUC 的核心基础组件，支撑着 java 锁和同步器的实现，例如 ReentrantLock、ReentrantReadWriteLock、CountDownLatch，以及 Semaphore 等。大神 Doug Lea 在设计 JUC 包时希望能够抽象一个基础且通用的组件以支撑上层模块的实现，AQS 应运而生。这些同步器以及锁都是内部定义sync集成aqs然后定义自己的api。
state用关键字volatile修饰，代表着该共享资源的状态一更改就能被所有线程可见，而AQS的加锁方式本质上就是多个线程在竞争state，当state为0时代表线程可以竞争锁，不为0时代表当前对象锁已经被占有，其他线程来加锁时则会失败，加锁失败的线程会被放入一个FIFO的等待队列中，这些线程会被UNSAFE.park()操作挂起，等待其他获取锁的线程释放锁才能够被唤醒。
而这个等待队列其实就相当于一个CLH队列，用一张原理图来表示大致如下：
1.1基础定义
AQS支持两种资源分享的方式：Exclusive（独占，只有一个线程能执行，如ReentrantLock）和Share（共享，多个线程可同时执行，如Semaphore/CountDownLatch）。
自定义的同步器继承AQS后，只需要实现共享资源state的获取和释放方式即可，其他如线程队列的维护（如获取资源失败入队/唤醒出队等）等操作，AQS在顶层已经实现了，AQS代码内部提供了一系列操作锁和线程队列的方法，主要操作锁的方法包含以下几个：
- compareAndSetState()：利用CAS的操作来设置state的值
- tryAcquire(int)：独占方式获取锁。成功则返回true，失败则返回false。
- tryRelease(int)：独占方式释放锁。成功则返回true，失败则返回false。
- tryAcquireShared(int)：共享方式释放锁。负数表示失败；0表示成功，但没有剩余可用资源；正数表示成功，且有剩余资源。
- tryReleaseShared(int)：共享方式释放锁。如果释放后允许唤醒后续等待结点返回true，否则返回false。
像ReentrantLock就是实现了自定义的tryAcquire-tryRelease，从而操作state的值来实现同步效果，除此之外，AQS内部还定义了一个静态类Node，表示CLH队列的每一个结点，该结点的作用是对每一个等待获取资源做了封装，包含了需要同步的线程本身、线程等待状态等。
我们可以看下该类的一些重点变量：
static final class Node {
/**
* 标记节点未共享模式
* */
static final Node SHARED = new Node();
/**
* 标记节点为独占模式
*/
static final Node EXCLUSIVE = null;
/**
* 在同步队列中等待的线程等待超时或者被中断，需要从同步队列中取消等待
* */
static final int CANCELLED = 1;
/**
* 后继节点的线程处于等待状态，而当前的节点如果释放了同步状态或者被取消，
* 将会通知后继节点，使后继节点的线程得以运行。
*/
static final int SIGNAL = -1;
/**
* 节点在等待队列中，节点的线程等待在Condition上，当其他线程对Condition调用了signal()方法后，
* 该节点会从等待队列中转移到同步队列中，加入到同步状态的获取中
*/
static final int CONDITION = -2;
/**
* 表示下一次共享式同步状态获取将会被无条件地传播下去
*/
static final int PROPAGATE = -3;
/**
* 标记当前节点的信号量状态 (1,0,-1,-2,-3)5种状态
* 使用CAS更改状态，volatile保证线程可见性，高并发场景下，
* 即被一个线程修改后，状态会立马让其他线程可见。
*/
volatile int waitStatus;
/**
* 前驱节点，当前节点加入到同步队列中被设置
*/
volatile Node prev;
/**
* 后继节点
*/
volatile Node next;
/**
* 节点同步状态的线程
*/
volatile Thread thread;
/**
* 等待队列中的后继节点，如果当前节点是共享的，那么这个字段是一个SHARED常量，
* 也就是说节点类型(独占和共享)和等待队列中的后继节点共用同一个字段。
*/
Node nextWaiter;
} 代码里面定义了一个表示当前Node结点等待状态的字段waitStatus，该字段的取值包含了CANCELLED(1)、SIGNAL(-1)、CONDITION(-2)、PROPAGATE(-3)、0，这五个值代表了不同的特定场景：
- CANCELLED：表示当前结点已取消调度。当timeout或被中断（响应中断的情况下），会触发变更为此状态，进入该状态后的结点将不会再变化。
- SIGNAL：表示后继结点在等待当前结点唤醒。后继结点入队时，会将前继结点的状态更新为SIGNAL（记住这个-1的值，因为后面我们讲的时候经常会提到）
- CONDITION：表示结点等待在Condition上，当其他线程调用了Condition的signal()方法后，CONDITION状态的结点将从等待队列转移到同步队列中，等待获取同步锁。(注：Condition是AQS的一个组件，后面会细说)
- PROPAGATE：共享模式下，前继结点不仅会唤醒其后继结点，同时也可能会唤醒后继的后继结点。
- 0：新结点入队时的默认状态。
也就是说，当waitStatus为负值表示结点处于有效等待状态，为正值的时候表示结点已被取消。
在AQS内部中还维护了两个Node对象head和tail，一开始默认都为null。
/**
* 指向同步等待队列的头节点
*/
private transient volatile Node head;
/**
* 指向同步等待队列的尾节点
*/
private transient volatile Node tail;讲完了AQS的一些基础定义，我们就可以开始学习同步的具体运行机制了，为了更好的演示，我们用ReentrantLock作为使用入口，一步步跟进源码探究AQS底层是如何运作的，这里说明一下，因为ReentrantLock底层调用的AQS是独占模式，所以下文讲解的AQS源码也是针对独占模式的操作。在文章的末尾我也会附上aqs跟ReentrantLock源码的中文注释，大家有需要可以拷贝下来细读。
二、独占模式
2.1加锁
我们都知道，ReentrantLock的加锁和解锁方法分别为lock()和unLock()，我们先来看获取锁的方法。
/**
* 加锁行为
*/
final void lock() {
/**
* 第一步：直接尝试加锁
* 与公平锁实现的加锁行为一个最大的区别在于，此处不会去判断同步队列(CLH队列)中
* 是否有排队等待加锁的节点，上来直接加锁（判断state是否为0,CAS修改state为1）
* ，并将独占锁持有者 exclusiveOwnerThread 属性指向当前线程
* 如果当前有人占用锁，再尝试去加一次锁
*/
if (compareAndSetState(0, 1))
setExclusiveOwnerThread(Thread.currentThread());
else
//AQS定义的方法,加锁
acquire(1);
} 逻辑很简单，线程进来后直接利用CAS尝试抢占锁，如果抢占成功state值回被改为1，且设置对象独占锁线程为当前线程，否则就调用acquire(1)再次尝试获取锁。
我们假定有两个线程A和B同时竞争锁，A进来先抢占到锁，此时的AQS模型图就类似这样：
继续走下面的方法，acquire。
public final void acquire(int arg) {
if (!tryAcquire(arg) &&
acquireQueued(addWaiter(Node.EXCLUSIVE), arg))
selfInterrupt();
}- tryAcquire：尝试直接获取锁，如果成功就直接返回；
- addWaiter：将该线程加入等待队列FIFO的尾部，并标记为独占模式；
- acquireQueued：线程阻塞在等待队列中获取锁，一直获取到资源后才返回。如果在整个等待过程中被中断过，则返回true，否则返回false。
- selfInterrupt：自我中断，就是既拿不到锁，又在等待时被中断了，线程就会进行自我中断selfInterrupt()，将中断补上。
我们一个个来看源码，并结合上面的两个线程来做场景分析。
2.1.1tryAcquire
不用多说，就是为了再次尝试获取锁，或者判断当前持有锁的线程是不是自己本身。
protected final boolean tryAcquire(int acquires) {
return nonfairTryAcquire(acquires);
}
/**
* 尝试获取非公平锁
*/
final boolean nonfairTryAcquire(int acquires) {
//acquires = 1
final Thread current = Thread.currentThread();
int c = getState();
/**
* 不需要判断同步队列（CLH）中是否有排队等待线程
* 判断state状态是否为0，不为0可以加锁
*/
if (c == 0) {
//unsafe操作，cas修改state状态
if (compareAndSetState(0, acquires)) {
//独占状态锁持有者指向当前线程
setExclusiveOwnerThread(current);
return true;
}
}
/**
* state状态不为0，判断锁持有者是否是当前线程，
* 如果是当前线程持有 则state+1
*/
else if (current == getExclusiveOwnerThread()) {
int nextc = c + acquires;
if (nextc < 0) // overflow
throw new Error("Maximum lock count exceeded");
setState(nextc);
return true;
}
//加锁失败
return false;
} 当线程B进来后，nonfairTryAcquire方法首先会获取state的值，如果为0，则正常获取该锁，不为0的话判断是否是当前线程占用了，是的话就累加state的值，这里的累加也是为了配合释放锁时候的次数，从而实现可重入锁的效果。当然，因为之前锁已经被线程A占领了，所以这时候tryAcquire会返回false，继续下面的流程。
2.1.2 addWaiter
private Node addWaiter(Node mode) {
// 1. 将当前线程构建成Node类型
Node node = new Node(Thread.currentThread(), mode);
// Try the fast path of enq; backup to full enq on failure
Node pred = tail;
// 2. 1当前尾节点是否为null？
if (pred != null) {
// 2.2 将当前节点尾插入的方式
node.prev = pred;
// 2.3 CAS将节点插入同步队列的尾部
if (compareAndSetTail(pred, node)) {
pred.next = node;
return node;
}
}
enq(node);
return node;
} 这段代码首先会创建一个和当前线程绑定的Node节点，Node为双向链表。此时等待队列中的tail指针为空，直接调用enq(node)方法将当前线程加入等待队列尾部，然后返回当前结点的前驱结点。
/**
* 节点加入CLH同步队列
*/
private Node enq(final Node node) {
for (;;) {
Node t = tail;
if (t == null) { // Must initialize
//队列为空需要初始化，创建空的头节点,队列为空，初始化一个Node结点作为Head结点，并将tail结点也指向它
if (compareAndSetHead(new Node()))
tail = head;
} else {
node.prev = t;
//set尾部节点
if (compareAndSetTail(t, node)) {//当前节点置为尾部
t.next = node; //前驱节点的next指针指向当前节点
return t;
}
}
}
}第一遍循环时，tail指针为空，初始化一个Node结点，并把head和tail结点都指向它，然后第二次循环进来之后，tail结点不为空了，就将当前的结点加入到tail结点后面，也就是这样。
如果此时有另一个线程C进来的话，发现锁已经被A拿走了，然后队列里已经有了线程B，那么线程C就只能乖乖排到线程B的后面去，大家在跟着阅读源码或者自己阅读源码的时候，也可以跟着思路在纸上画出此时的队列情况这样子更能够理解。
2.1.3acquireQueued
/**
* 已经在队列当中的Thread节点，准备阻塞等待获取锁
*/
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)) {//如果前驱结点是头结点，才tryAcquire，其他结点是没有机会tryAcquire的。
setHead(node);//获取同步状态成功，将当前结点设置为头结点。
p.next = null; // help GC
failed = false;
return interrupted;
}
/**
* 如果前驱节点不是Head，通过shouldParkAfterFailedAcquire判断是否应该阻塞
* 前驱节点信号量为-1，当前线程可以安全被parkAndCheckInterrupt用来阻塞线程
*/
if (shouldParkAfterFailedAcquire(p, node) &&
parkAndCheckInterrupt())
interrupted = true;
}
} finally {
if (failed)
cancelAcquire(node);
}
}
private static boolean shouldParkAfterFailedAcquire(Node pred, Node node) {
int ws = pred.waitStatus;
if (ws == Node.SIGNAL)
/*
* 若前驱结点的状态是SIGNAL，意味着当前结点可以被安全地park
*/
return true;
if (ws > 0) {
/*
* waitStatus>0代表这个节点无效需要进行剔除,前驱节点状态如果被取消状态，将被移除出队列
*/
do {
node.prev = pred = pred.prev;
} while (pred.waitStatus > 0);
pred.next = node;
} else {
/*
* 当前驱节点waitStatus为 0 or PROPAGATE状态时
* 将其设置为SIGNAL状态，然后当前结点才可以可以被安全地park
*/
compareAndSetWaitStatus(pred, ws, Node.SIGNAL);
}
return false;
} acquireQueued方法的流程是这样的：
- CAS自旋，先判断当前传入的Node的前结点是否为head结点，是的话就尝试获取锁，获取锁成功的话就把当前结点置为head，之前的head置为null(方便GC)，然后返回。
- 如果前驱结点不是head或者加锁失败的话，就调用
shouldParkAfterFailedAcquire，将前驱节点的waitStatus变为了SIGNAL=-1，最后执行parkAndChecknIterrupt方法，调用LockSupport.park()挂起当前线程，parkAndCheckInterrupt在挂起线程后会判断线程是否被中断，如果被中断的话，就会重新跑acquireQueued方法的CAS自旋操作，直到获取资源。
ps：LockSupport.park方法会让当前线程进入waitting状态，在这种状态下，线程被唤醒的情况有两种，一是被unpark()，二是被interrupt()，所以，如果是第二种情况的话，需要返回被中断的标志，然后在acquire顶层方法的窗口那里自我中断补上。
此时，因为线程A还未释放锁，所以线程B状态都是被挂起的：
到这里，加锁的流程就分析完了，其实整体来说也并不复杂，而且当你理解了独占模式加锁的过程，后面释放锁和共享模式的运行机制也没什么难懂的了，所以整个加锁的过程还是有必要多消化下的，也是AQS的重中之重。这里我附上一张流程图：
2.2释放锁
说完了加锁，我们来看看释放锁是怎么做的，AQS中释放锁的方法是release()，当调用该方法时会释放指定量的资源 (也就是锁) ，如果彻底释放了（即state=0）,它会唤醒等待队列里的其他线程来获取资源。
/**
* 释放独占模式持有的锁
*/
public final boolean release(int arg) {
if (tryRelease(arg)) {//释放一次锁
Node h = head;
if (h != null && h.waitStatus != 0)
unparkSuccessor(h);//唤醒后继结点
return true;
}
return false;
}2.2.1tryRelease
代码上可以看出，核心的逻辑都在tryRelease方法中，该方法的作用是释放资源，AQS里该方法没有具体的实现，需要由自定义的同步器去实现，我们看下ReentrantLock代码中对应方法的源码：
/**
* 释放锁
*/
protected final boolean tryRelease(int releases) {
int c = getState() - releases;
if (Thread.currentThread() != getExclusiveOwnerThread())
throw new IllegalMonitorStateException();
boolean free = false;
if (c == 0) {
free = true;
setExclusiveOwnerThread(null);
}
setState(c);
return free;
} tryRelease方法会减去state对应的值，如果state为0，也就是已经彻底释放资源，就返回true，并且把独占的线程置为null，否则返回false。
此时AQS中的数据就会变成这样：
完全释放资源后，当前线程要做的就是唤醒CLH队列中第一个在等待资源的线程，也就是head结点后面的线程，此时调用的方法是unparkSuccessor().
private void unparkSuccessor(Node node) {
//获取wait状态
int ws = node.waitStatus;
if (ws < 0)
compareAndSetWaitStatus(node, ws, 0);// 将等待状态waitStatus设置为初始值0
/**
* 若后继结点为空，或状态为CANCEL（已失效），则从后尾部往前遍历找到最前的一个处于正常阻塞状态的结点
* 进行唤醒
*/
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);//唤醒线程
} 方法的逻辑很简单，就是先将head的结点状态置为0，避免下面找结点的时候再找到head，然后找到队列中最前面的有效结点，然后唤醒，我们假设这个时候线程A已经释放锁，那么此时队列中排最前边竞争锁的线程B就会被唤醒。然后被唤醒的线程B就会尝试用CAS获取锁，回到acquireQueued方法的逻辑.
for (;;) {//死循环
final Node p = node.predecessor();//找到当前结点的前驱结点
if (p == head && tryAcquire(arg)) {//如果前驱结点是头结点，才tryAcquire，其他结点是没有机会tryAcquire的。
setHead(node);//获取同步状态成功，将当前结点设置为头结点。
p.next = null; // help GC
failed = false;
return interrupted;
}
/**
* 如果前驱节点不是Head，通过shouldParkAfterFailedAcquire判断是否应该阻塞
* 前驱节点信号量为-1，当前线程可以安全被parkAndCheckInterrupt用来阻塞线程
*/
if (shouldParkAfterFailedAcquire(p, node) &&
parkAndCheckInterrupt())
interrupted = true;
}当线程B获取锁之后，会把当前结点赋值给head，然后原先的前驱结点 (也就是原来的head结点) 去掉引用链，方便回收，这样一来，线程B获取锁的整个过程就完成了，此时AQS的数据就会变成这样。
到这里，我们已经分析完了AQS独占模式下加锁和释放锁的过程，也就是tryAccquire->tryRelease这一链条的逻辑，除此之外，AQS中还支持共享模式的同步，这种模式下关于锁的操作核心其实就是tryAcquireShared->tryReleaseShared这两个方法，我们可以简单看下 。
三、共享模式
3.1获取锁
AQS中，共享模式获取锁的顶层入口方法是acquireShared，该方法会获取指定数量的资源，成功的话就直接返回，失败的话就进入等待队列，直到获取资源。
/**
* 请求获取共享锁
*/
public final void acquireShared(int arg) {
if (tryAcquireShared(arg) < 0)//返回值小于0，获取同步状态失败，排队去；获取同步状态成功，直接返回去干自己的事儿。
doAcquireShared(arg);
}该方法里包含了两个方法的调用：
- tryAcquireShared：尝试获取一定资源的锁，返回的值代表获取锁的状态。
- doAcquireShared：进入等待队列，并循环尝试获取锁，直到成功。
3.1.1tryAcquireShared
tryAcquireShared在AQS里没有实现，同样由自定义的同步器去完成具体的逻辑，像一些较为常见的并发工具Semaphore、CountDownLatch里就有对该方法的自定义实现，虽然实现的逻辑不同，但方法的作用是一样的，就是获取一定资源的资源，然后根据返回值判断是否还有剩余资源，从而决定下一步的操作。
返回值有三种定义：
- 负值代表获取失败；
- 0代表获取成功，但没有剩余的资源，也就是state已经为0；
- 正值代表获取成功，而且state还有剩余，其他线程可以继续领取
当返回值小于0时，证明此次获取一定数量的锁失败了，然后就会走doAcquireShared方法。
3.1.2doAcquireShared
此方法的作用是将当前线程加入等待队列尾部休息，直到其他线程释放资源唤醒自己，自己成功拿到相应量的资源后才返回，这是它的源码：
private void doAcquireShared(int arg) {
// 加入队列尾部
final Node node = addWaiter(Node.SHARED);
boolean failed = true;
try {
boolean interrupted = false;
// CAS自旋
for (;;) {
final Node p = node.predecessor();
// 判断前驱结点是否是head
if (p == head) {
// 尝试获取一定数量的锁
int r = tryAcquireShared(arg);
if (r >= 0) {
// 获取锁成功，而且还有剩余资源，就设置当前结点为head，并继续唤醒下一个线程
setHeadAndPropagate(node, r);
// 让前驱结点去掉引用链，方便被GC
p.next = null; // help GC
if (interrupted)
selfInterrupt();
failed = false;
return;
}
}
// 跟独占模式一样，改前驱结点waitStatus为-1，并且当前线程挂起，等待被唤醒
if (shouldParkAfterFailedAcquire(p, node) &&
parkAndCheckInterrupt())
interrupted = true;
}
} finally {
if (failed)
cancelAcquire(node);
}
}
private void setHeadAndPropagate(Node node, int propagate) {
Node h = head;
// head指向自己
setHead(node);
// 如果还有剩余量，继续唤醒下一个邻居线程
if (propagate > 0 || h == null || h.waitStatus < 0) {
Node s = node.next;
if (s == null || s.isShared())
doReleaseShared();
}
} 看到这里，你会不会一点熟悉的感觉，这个方法的逻辑怎么跟上面那个acquireQueued() 那么类似啊？对的，其实两个流程并没有太大的差别。只是doAcquireShared()比起独占模式下的获取锁上多了一步唤醒后继线程的操作，当获取完一定的资源后，发现还有剩余的资源，就继续唤醒下一个邻居线程。
3.2 释放锁
共享模式释放锁的顶层方法是releaseShared，它会释放指定量的资源，如果成功释放且允许唤醒等待线程，它会唤醒等待队列里的其他线程来获取资源。下面是releaseShared()的源码：
public final boolean releaseShared(int arg) {
if (tryReleaseShared(arg)) {
doReleaseShared();
return true;
}
return false;
}该方法同样包含两部分的逻辑：
- tryReleaseShared：释放资源。
- doAcquireShared：唤醒后继结点。
跟tryAcquireShared方法一样，tryReleaseShared在AQS中没有具体的实现，由子同步器自己去定义，但功能都一样，就是释放一定数量的资源。
3.2.1doAcquireShared
唤醒后继结点的工作在doReleaseShared()方法中完成，我们可以看下它的源码：
private void doReleaseShared() {
for (;;) {
// 获取等待队列中的head结点
Node h = head;
if (h != null && h != tail) {
int ws = h.waitStatus;
// head结点waitStatus = -1,唤醒下一个结点对应的线程
if (ws == Node.SIGNAL) {
if (!compareAndSetWaitStatus(h, Node.SIGNAL, 0))
continue; // loop to recheck cases
// 唤醒后继结点
unparkSuccessor(h);
}
else if (ws == 0 &&
!compareAndSetWaitStatus(h, 0, Node.PROPAGATE))
continue; // loop on failed CAS
}
if (h == head) // loop if head changed
break;
}
} 码没什么特别的，就是如果等待队列head结点的waitStatus为-1的话，就直接唤醒后继结点，唤醒的方法unparkSuccessor()在上面已经讲过了，这里也没必要再复述。
总的来看，AQS共享模式的运作流程和独占模式很相似，只要掌握了独占模式的流程运转，共享模式什么的不就那样吗，没难度。这也是我为什么共享模式讲解中不画流程图的原因，没必要嘛。
4.AbstractQueuedSynchronizer源码中文注释
package com.it.edu.aqs;
import sun.misc.Unsafe;
import java.util.ArrayList;
import java.util.Collection;
import java.util.Date;
import java.util.concurrent.TimeUnit;
import java.util.concurrent.locks.Condition;
import java.util.concurrent.locks.Lock;
import java.util.concurrent.locks.LockSupport;
/**
* @author ：图灵-杨过
* @date：2019/7/3
* @version: V1.0
* @slogan:天下风云出我辈，一入代码岁月催
* description：AQS同步器框架源码
*/
public abstract class AbstractQueuedSynchronizer
extends AbstractOwnableSynchronizer
implements java.io.Serializable {
private static final long serialVersionUID = 7373984972572414691L;
/**
* Creates a new {@code AbstractQueuedSynchronizer} instance
* with initial synchronization state of zero.
*/
protected AbstractQueuedSynchronizer() { }
/**
* Wait queue node class.
*
* <p>The wait queue is a variant of a "CLH" (Craig, Landin, and
* Hagersten) lock queue. CLH locks are normally used for
* spinlocks. We instead use them for blocking synchronizers, but
* use the same basic tactic of holding some of the control
* information about a thread in the predecessor of its node. A
* "status" field in each node keeps track of whether a thread
* should block. A node is signalled when its predecessor
* releases. Each node of the queue otherwise serves as a
* specific-notification-style monitor holding a single waiting
* thread. The status field does NOT control whether threads are
* granted locks etc though. A thread may try to acquire if it is
* first in the queue. But being first does not guarantee success;
* it only gives the right to contend. So the currently released
* contender thread may need to rewait.
*
* <p>To enqueue into a CLH lock, you atomically splice it in as new
* tail. To dequeue, you just set the head field.
* <pre>
* +------+ prev +-----5.ReentrantLock源码中文注释
package com.it.edu.aqs;
/*
* ORACLE PROPRIETARY/CONFIDENTIAL. Use is subject to license terms.
*/
/*
*
*
*
*
*
* Written by Doug Lea with assistance from members of JCP JSR-166
* Expert Group and released to the public domain, as explained at
* http://creativecommons.org/publicdomain/zero/1.0/
*/
import java.util.Collection;
import java.util.concurrent.TimeUnit;
import java.util.concurrent.locks.Condition;
import java.util.concurrent.locks.Lock;
/**
* A reentrant mutual exclusion {@link Lock} with the same basic
* behavior and semantics as the implicit monitor lock accessed using
* {@code synchronized} methods and statements, but with extended
* capabilities.
*
* <p>A {@code ReentrantLock} is <em>owned</em> by the thread last
* successfully locking, but not yet unlocking it. A thread invoking
* {@code lock} will return, successfully acquiring the lock, when
* the lock is not owned by another thread. The method will return
* immediately if the current thread already owns the lock. This can
* be checked using methods {@link #isHeldByCurrentThread}, and {@link
* #getHoldCount}.
*
* <p>The constructor for this class accepts an optional
* <em>fairness</em> parameter. When set {@code true}, under
* contention, locks favor granting access to the longest-waiting
* thread. Otherwise this lock does not guarantee any particular
* access order. Programs using fair locks accessed by many threads
* may display lower overall throughput (i.e., are slower; often much
* slower) than those using the default setting, but have smaller
* variances in times to obtain locks and guarantee lack of
* starvation. Note however, that fairness of locks does not guarantee
* fairness of thread scheduling. Thus, one of many threads using a
* fair lock may obtain it multiple times in succession while other
* active threads are not progressing and not currently holding the
* lock.
* Also note that the untimed {