并发编程
AQS
1、AQS的产生背景
通过JCP的JSR166规范，Jdk1.5开始引入了j.u.c包，这个包提供了一系列支持并发的组件。这些组件是一系列的同步器，这些同步器主要维护着以下几个功能：内部同步状态的管理(例如表示一个锁的状态是获取还是释放)，同步状态的更新和检查操作，且至少有一个方法会导致调用线程在同步状态被获取时阻塞，以及在其他线程改变这个同步状态时解除线程的阻塞。上述的这些的实际例子包括：互斥排它锁的不同形式、读写锁、信号量、屏障、Future、事件指示器以及传送队列等。可以看下这里图便能理解j.u.c包的组件构成。
几乎任一同步器都可以用来实现其他形式的同步器。例如，可以用可重入锁实现信号量或者用信号量实现可重入锁。但是，这样做带来的复杂性、开销及不灵活使j.u.c最多只能是一个二流工程，且缺乏吸引力。如果任何这样的构造方式不能在本质上比其他形式更简洁，那么开发者就不应该随意地选择其中的某个来构建另一个同步器。因此，JSR166基于AQS类建立了一个小框架，这个框架为构造同步器提供一种通用的机制，并且被j.u.c包中大部分类使用，同时很多用户也可以用它来定义自己的同步器。这个就是j.u.c的作者Doug Lea大神的初衷，通过提供AQS这个基础组件来构建j.u.c的各种工具类，至此就可以理解AQS的产生背景了。
2、AQS的设计和结构
2.1 设计思想
同步器的核心方法是acquire和release操作，其背后的思想也比较简洁明确。acquire操作是这样的：
while (当前同步器的状态不允许获取操作) {
如果当前线程不在队列中，则将其插入队列
阻塞当前线程
}
如果线程位于队列中，则将其移出队列
release操作是这样的：
更新同步器的状态
if (新的状态允许某个被阻塞的线程获取成功)
解除队列中一个或多个线程的阻塞状态
从这两个操作中的思想中我们可以提取出三大关键操作：同步器的状态变更、线程阻塞和释放、插入和移出队列。所以为了实现这两个操作，需要协调三大关键操作引申出来的三个基本组件：
·同步器状态的原子性管理；
·线程阻塞与解除阻塞；
·队列的管理；
由这三个基本组件，我们来看j.u.c是怎么设计的。
2.1.1 同步状态
AQS类使用单个int（32位）来保存同步状态，并暴露出getState、setState以及compareAndSet操作来读取和更新这个同步状态。其中属性state被声明为volatile，并且通过使用CAS指令来实现compareAndSetState，使得当且仅当同步状态拥有一个一致的期望值的时候，才会被原子地设置成新值，这样就达到了同步状态的原子性管理，确保了同步状态的原子性、可见性和有序性。
基于AQS的具体实现类（如锁、信号量等）必须根据暴露出的状态相关的方法定义tryAcquire和tryRelease方法，以控制acquire和release操作。当同步状态满足时，tryAcquire方法必须返回true，而当新的同步状态允许后续acquire时，tryRelease方法也必须返回true。这些方法都接受一个int类型的参数用于传递想要的状态。
2.1.2 阻塞
直到JSR166，阻塞线程和解除线程阻塞都是基于Java的内置管程，没有其它非基于Java内置管程的API可以用来达到阻塞线程和解除线程阻塞。唯一可以选择的是Thread.suspend和Thread.resume，但是它们都有无法解决的竞态问题，所以也没法用，目前该方法基本已被抛弃。具体不能用的原因可以官方给出的答复。
j.u.c.locks包提供了LockSupport类来解决这个问题。方法LockSupport.park阻塞当前线程直到有个LockSupport.unpark方法被调用。unpark的调用是没有被计数的，因此在一个park调用前多次调用unpark方法只会解除一个park操作。另外，它们作用于每个线程而不是每个同步器。一个线程在一个新的同步器上调用park操作可能会立即返回，因为在此之前可以有多余的unpark操作。但是，在缺少一个unpark操作时，下一次调用park就会阻塞。虽然可以显式地取消多余的unpark调用，但并不值得这样做。在需要的时候多次调用park会更高效。park方法同样支持可选的相对或绝对的超时设置，以及与JVM的Thread.interrupt结合 ，可通过中断来unpark一个线程。
2.1.3 队列
整个框架的核心就是如何管理线程阻塞队列，该队列是严格的FIFO队列，因此不支持线程优先级的同步。同步队列的最佳选择是自身没有使用底层锁来构造的非阻塞数据结构，业界主要有两种选择，一种是MCS锁，另一种是CLH锁。其中CLH一般用于自旋，但是相比MCS，CLH更容易实现取消和超时，所以同步队列选择了CLH作为实现的基础。
CLH队列实际并不那么像队列，它的出队和入队与实际的业务使用场景密切相关。它是一个链表队列，通过AQS的两个字段head（头节点）和tail（尾节点）来存取，这两个字段是volatile类型，初始化的时候都指向了一个空节点。如下图：
入队操作：CLH队列是FIFO队列，故新的节点到来的时候，是要插入到当前队列的尾节点之后。试想一下，当一个线程成功地获取了同步状态，其他线程将无法获取到同步状态，转而被构造成为节点并加入到同步队列中，而这个加入队列的过程必须要保证线程安全，因此同步器提供了一个CAS方法，它需要传递当前线程“认为”的尾节点和当前节点，只有设置成功后，当前节点才正式与之前的尾节点建立关联。入队操作示意图大致如下：
出队操作：因为遵循FIFO规则，所以能成功获取到AQS同步状态的必定是首节点，首节点的线程在释放同步状态时，会唤醒后续节点，而后续节点会在获取AQS同步状态成功的时候将自己设置为首节点。设置首节点是由获取同步成功的线程来完成的，由于只能有一个线程可以获取到同步状态，所以设置首节点的方法不需要像入队这样的CAS操作，只需要将首节点设置为原首节点的后续节点同时断开原节点、后续节点的引用即可。出队操作示意图大致如下：
这一小节只是简单的描述了队列的大概，目的是为了表达清楚队列的设计框架，实际上CLH队列已经和初始的CLH队列已经发生了一些变化，具体的可以看查看资料中Doug Lea的那篇论文中的3.3 Queues。
2.1.4 条件队列
上一节的队列其实是AQS的同步队列，这一节的队列是条件队列，队列的管理除了有同步队列，还有条件队列。AQS只有一个同步队列，但是可以有多个条件队列。AQS框架提供了一个ConditionObject类，给维护独占同步的类以及实现Lock接口的类使用。
ConditionObject类实现了Condition接口，Condition接口提供了类似Object管程式的方法，如await、signal和signalAll操作，还扩展了带有超时、检测和监控的方法。ConditionObject类有效地将条件与其它同步操作结合到了一起。该类只支持Java风格的管程访问规则，这些规则中，当且仅当当前线程持有锁且要操作的条件（condition）属于该锁时，条件操作才是合法的。这样，一个ConditionObject关联到一个ReentrantLock上就表现的跟内置的管程（通过Object.wait等）一样了。两者的不同仅仅在于方法的名称、额外的功能以及用户可以为每个锁声明多个条件。
ConditionObject类和AQS共用了内部节点，有自己单独的条件队列。signal操作是通过将节点从条件队列转移到同步队列中来实现的，没有必要在需要唤醒的线程重新获取到锁之前将其唤醒。signal操作大致示意图如下：
await操作就是当前线程节点从同步队列进入条件队列进行等待，大致示意图如下：
实现这些操作主要复杂在，因超时或Thread.interrupt导致取消了条件等待时，该如何处理。await和signal几乎同时发生就会有竞态问题，最终的结果遵照内置管程相关的规范。JSR133修订以后，就要求如果中断发生在signal操作之前，await方法必须在重新获取到锁后，抛出InterruptedException。但是，如果中断发生在signal后，await必须返回且不抛异常，同时设置线程的中断状态。
2.2 方法结构
如果我们理解了上一节的设计思路，我们大致就能知道AQS的主要数据结构了。
| 组件 | 数据结构 |
|---|---|
| 同步状态 | volatile int state |
| 阻塞 | LockSupport类 |
| 队列 | Node节点 |
| 条件队列 | ConditionObject |
进而再来看下AQS的主要方法及其作用。
| 属性、方法 | 描述、作用 |
|---|---|
| int getState() | 获取当前同步状态 |
| void setState(int newState) | 设置当前同步状态 |
| boolean compareAndSetState(int expect, int update) | 通过CAS设置当前状态，此方法保证状态设置的原子性 |
| boolean tryAcquire(int arg) | 钩子方法，独占式获取同步状态，AQS没有具体实现，具体实现都在子类中，实现此方法需要查询当前同步状态并判断同步状态是否符合预期，然后再CAS设置同步状态 |
| boolean tryRelease(int arg) | 钩子方法，独占式释放同步状态，AQS没有具体实现，具体实现都在子类中，等待获取同步状态的线程将有机会获取同步状态 |
| int tryAcquireShared(int arg) | 钩子方法，共享式获取同步状态，AQS没有具体实现，具体实现都在子类中，返回大于等于0的值表示获取成功，反之失败 |
| boolean tryReleaseShared(int arg) | 钩子方法，共享式释放同步状态，AQS没有具体实现，具体实现都在子类中 |
| boolean isHeldExclusively() | 钩子方法，AQS没有具体实现，具体实现都在子类中，当前同步器是否在独占模式下被线程占用，一般该方法表示是否被当前线程所独占 |
| void acquire(int arg) | 模板方法，独占式获取同步状态，如果当前线程获取同步状态成功，则由该方法返回，否则会进入同步队列等待，此方法会调用子类重写的tryAcquire方法 |
| void acquireInterruptibly(int arg) | 模板方法，与acquire相同，但是此方法可以响应中断，当前线程未获取到同步状态而进入同步队列中，如果当前线程被中断，此方法会抛出InterruptedException并返回 |
| boolean tryAcquireNanos(int arg, long nanosTimeout) | 模板方法，在acquireInterruptibly基础上增加了超时限制，如果当前线程在超时时间内没有获取到同步状态，则会返回false,如果获取到了则会返回true |
| boolean release(int arg) | 模板方法，独占式的释放同步状态，该方法会在释放同步状态后，将同步队列中的第一个节点包含的线程唤醒 |
| void acquireShared(int arg) | 模板方法，共享式的获取同步状态，如果当前系统未获取到同步状态，将会进入同步队列等待，与acquire的主要区别在于同一时刻可以有多个线程获取到同步状态 |
| void acquireSharedInterruptibly(int arg) | 模板方法，与acquireShared一致，但是可以响应中断 |
| boolean tryAcquireSharedNanos(int arg, long nanosTimeout) | 模板方法，在acquireSharedInterruptibly基础上增加了超时限制 |
| boolean releaseShared(int arg) | 模板方法，共享式的释放同步状态 |
| Collection getQueuedThreads() | 模板方法，获取等待在同步队列上的线程集合 |
| Node int waitStatus | 等待状态1、 CANCELLED，值为1，在同步队列中等待的线程等待超时或者被中断，需要从同步队列中取消等待，节点进入该状态后将不会变化；2、 SIGNAL，值为-1，后续节点的线程处于等待状态，而当前节点的线程如果释放了同步状态或者被取消，将会通知后续节点，使后续节点的线程得以运行；3、 CONDITION，值为-2，节点在条件队列中，节点线程等待在Condition上，当其他线程对Condition调用了signal()方法后，该节点将会从条件队列中转移到同步队列中，加入到对同步状态的获取中；4、 PROPAGATE，值为-3，表示下一次共享式同步状态获取将会无条件地传播下去 |
| Node prev | 前驱节点，当节点加入同步队列时被设置 |
| Node next | 后续节点 |
| Thread thread | 获取同步状态的线程 |
| Node nextWaiter | 条件队列中的后续节点，如果当前节点是共享的，那么这个字段将是一个SHARED变量，也就是说节点类型（独占和共享）和条件队列中的后续节点共用同一个字段 |
| LockSupport void park() | 阻塞当前线程，如果调用unpark方法或者当前线程被中断，才能从park方法返回 |
| LockSupport void unpark(Thread thread) | 唤醒处于阻塞状态的线程 |
| ConditionObject Node firstWaiter | 条件队列首节点 |
| ConditionObject Node lastWaiter | 条件队列尾节点 |
| void await() | 当前线程进入等待状态直到signal或中断，当前线程将进入运行状态且从await方法返回的情况，包括：其他线程调用该Condition的signal或者signalAll方法，且当前线程被选中唤醒；其他线程调用interrupt方法中断当前线程；如果当前线程从await方法返回表明该线程已经获取了Condition对象对应的锁 |
| void awaitUninterruptibly() | 和await方法类似，但是对中断不敏感 |
| long awaitNanos(long nanosTimeout) | 当前线程进入等待状态直到被signal、中断或者超时。返回值表示剩余的时间。 |
| boolean awaitUntil(Date deadline) | 当前线程进入等待状态直到被signal、中断或者某个时间。如果没有到指定时间就被通知，方法返回true，否则表示到了指定时间，返回false |
| void signal() | 唤醒一个等待在Condition上的线程，该线程从等待方法返回前必须获得与Condition相关联的锁 |
| void signalAll() | 唤醒所有等待在Condition上的线程，能够从等待方法返回的线程必须获得与Condition相关联的锁 |
看到这，我们对AQS的数据结构应该基本上有一个大致的认识，有了这个基本面的认识，我们就可以来看下AQS的源代码。
3、AQS的源代码实现
主要通过独占式同步状态的获取和释放、共享式同步状态的获取和释放来看下AQS是如何实现的。
3.1 独占式同步状态的获取和释放
独占式同步状态调用的方法是acquire，代码如下：
public final void acquire(int arg) {
if (!tryAcquire(arg) &&
acquireQueued(addWaiter(Node.EXCLUSIVE), arg))
selfInterrupt();
}
上述代码主要完成了同步状态获取、节点构造、加入同步队列以及在同步队列中自旋等待的相关工作，其主要逻辑是：首先调用子类实现的tryAcquire方法，该方法保证线程安全的获取同步状态，如果同步状态获取失败，则构造独占式同步节点（同一时刻只能有一个线程成功获取同步状态）并通过addWaiter方法将该节点加入到同步队列的尾部，最后调用acquireQueued方法，使得该节点以自旋的方式获取同步状态。如果获取不到则阻塞节点中的线程，而被阻塞线程的唤醒主要依靠前驱节点的出队或阻塞线程被中断来实现。
下面来首先来看下节点构造和加入同步队列是如何实现的。代码如下：
private Node addWaiter(Node mode) {
// 当前线程构造成Node节点
Node node = new Node(Thread.currentThread(), mode);
// Try the fast path of enq; backup to full enq on failure
// 尝试快速在尾节点后新增节点 提升算法效率 先将尾节点指向pred
Node pred = tail;
if (pred != null) {
//尾节点不为空 当前线程节点的前驱节点指向尾节点
node.prev = pred;
//并发处理 尾节点有可能已经不是之前的节点 所以需要CAS更新
if (compareAndSetTail(pred, node)) {
//CAS更新成功 当前线程为尾节点 原先尾节点的后续节点就是当前节点
pred.next = node;
return node;
}
}
//第一个入队的节点或者是尾节点后续节点新增失败时进入enq
enq(node);
return node;
}
private Node enq(final Node node) {
for (;;) {
Node t = tail;
if (t == null) { // Must initialize
//尾节点为空 第一次入队 设置头尾节点一致 同步队列的初始化
if (compareAndSetHead(new Node()))
tail = head;
} else {
//所有的线程节点在构造完成第一个节点后 依次加入到同步队列中
node.prev = t;
if (compareAndSetTail(t, node)) {
t.next = node;
return t;
}
}
}
}
节点进入同步队列之后，就进入了一个自旋的过程，每个线程节点都在自省地观察，当条件满足，获取到了同步状态，就可以从这个自旋过程中退出，否则依旧留在这个自旋过程中并会阻塞节点的线程，代码如下：
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)) {
//设置当前节点为头节点
setHead(node);
p.next = null; // help GC
failed = false;
return interrupted;
}
//是否阻塞
if (shouldParkAfterFailedAcquire(p, node) &&
parkAndCheckInterrupt())
interrupted = true;
}
} finally {
if (failed)
cancelAcquire(node);
}
}
再来看看shouldParkAfterFailedAcquire和parkAndCheckInterrupt是怎么来阻塞当前线程的，代码如下：
private static boolean shouldParkAfterFailedAcquire(Node pred, Node node) {
//前驱节点的状态决定后续节点的行为
int ws = pred.waitStatus;
if (ws == Node.SIGNAL)
/*前驱节点为-1 后续节点可以被阻塞
* This node has already set status asking a release
* to signal it, so it can safely park.
*/
return true;
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 {
/*前驱节点是初始或者共享状态就设置为-1 使后续节点阻塞
* 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.
*/
compareAndSetWaitStatus(pred, ws, Node.SIGNAL);
}
return false;
}
private final boolean parkAndCheckInterrupt() {
//阻塞线程
LockSupport.park(this);
return Thread.interrupted();
}
节点自旋的过程大致示意图如下:
整个独占式获取同步状态的流程图大致如下：
当同步状态获取成功之后，当前线程从acquire方法返回，对于锁这种并发组件而言，就意味着当前线程获取了锁。有获取同步状态的方法，就存在其对应的释放方法，该方法为release，现在来看下这个方法的实现，代码如下：
public final boolean release(int arg) {
if (tryRelease(arg)) {//同步状态释放成功
Node h = head;
if (h != null && h.waitStatus != 0)
//直接释放头节点
unparkSuccessor(h);
return true;
}
return false;
}
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;
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);
}
独占式释放是非常简单而且明确的。
总结下独占式同步状态的获取和释放：在获取同步状态时，同步器维护一个同步队列，获取状态失败的线程都会被加入到队列中并在队列中进行自旋；移出队列的条件是前驱节点为头节点且成功获取了同步状态。在释放同步状态时，同步器调用tryRelease方法释放同步状态，然后唤醒头节点的后继节点。
3.2 共享式同步状态的获取和释放
共享式同步状态调用的方法是acquireShared，代码如下：
public final void acquireShared(int arg) {
//获取同步状态的返回值大于等于0时表示可以获取同步状态
//小于0时表示可以获取不到同步状态 需要进入队列等待
if (tryAcquireShared(arg) < 0)
doAcquireShared(arg);
}
private void doAcquireShared(int arg) {
//和独占式一样的入队操作
final Node node = addWaiter(Node.SHARED);
boolean failed = true;
try {
boolean interrupted = false;
//自旋
for (;;) {
final Node p = node.predecessor();
if (p == head) {
int r = tryAcquireShared(arg);
if (r >= 0) {
//前驱结点为头节点且成功获取同步状态 可退出自旋
setHeadAndPropagate(node, r);
p.next = null; // help GC
if (interrupted)
selfInterrupt();
failed = false;
return;
}
}
if (shouldParkAfterFailedAcquire(p, node) &&
parkAndCheckInterrupt())
interrupted = true;
}
} finally {
if (failed)
cancelAcquire(node);
}
}
private void setHeadAndPropagate(Node node, int propagate) {
Node h = head; // Record old head for check below
//退出自旋的节点变成首节点
setHead(node);
/*
* Try to signal next queued node if:
* Propagation was indicated by caller,
* or was recorded (as h.waitStatus either before
* or after setHead) by a previous operation
* (note: this uses sign-check of waitStatus because
* PROPAGATE status may transition to SIGNAL.)
* and
* The next node is waiting in shared mode,
* or we don't know, because it appears null
*
* The conservatism in both of these checks may cause
* unnecessary wake-ups, but only when there are multiple
* racing acquires/releases, so most need signals now or soon
* anyway.
*/
if (propagate > 0 || h == null || h.waitStatus < 0 ||
(h = head) == null || h.waitStatus < 0) {
Node s = node.next;
if (s == null || s.isShared())
doReleaseShared();
}
}
与独占式一样，共享式获取也需要释放同步状态，通过调用releaseShared方法可以释放同步状态，代码如下：
public final boolean releaseShared(int arg) {
//释放同步状态
if (tryReleaseShared(arg)) {
//唤醒后续等待的节点
doReleaseShared();
return true;
}
return false;
}
private void doReleaseShared() {
/*
* Ensure that a release propagates, even if there are other
* in-progress acquires/releases. This proceeds in the usual
* way of trying to unparkSuccessor of head if it needs
* signal. But if it does not, status is set to PROPAGATE to
* ensure that upon release, propagation continues.
* Additionally, we must loop in case a new node is added
* while we are doing this. Also, unlike other uses of
* unparkSuccessor, we need to know if CAS to reset status
* fails, if so rechecking.
*/
//自旋
for (;;) {
Node h = head;
if (h != null && h != tail) {
int ws = h.waitStatus;
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;
}
}
unparkSuccessor方法和独占式是一样的。
4、AQS应用
AQS被大量的应用在了同步工具上。
ReentrantLock：ReentrantLock类使用AQS同步状态来保存锁重复持有的次数。当锁被一个线程获取时，ReentrantLock也会记录下当前获得锁的线程标识，以便检查是否是重复获取，以及当错误的线程试图进行解锁操作时检测是否存在非法状态异常。ReentrantLock也使用了AQS提供的ConditionObject，还向外暴露了其它监控和监测相关的方法。
ReentrantReadWriteLock：ReentrantReadWriteLock类使用AQS同步状态中的16位来保存写锁持有的次数，剩下的16位用来保存读锁的持有次数。WriteLock的构建方式同ReentrantLock。ReadLock则通过使用acquireShared方法来支持同时允许多个读线程。
Semaphore：Semaphore类（信号量）使用AQS同步状态来保存信号量的当前计数。它里面定义的acquireShared方法会减少计数，或当计数为非正值时阻塞线程；tryRelease方法会增加计数，在计数为正值时还要解除线程的阻塞。
CountDownLatch：CountDownLatch类使用AQS同步状态来表示计数。当该计数为0时，所有的acquire操作（对应到CountDownLatch中就是await方法）才能通过。
FutureTask：FutureTask类使用AQS同步状态来表示某个异步计算任务的运行状态（初始化、运行中、被取消和完成）。设置（FutureTask的set方法）或取消（FutureTask的cancel方法）一个FutureTask时会调用AQS的release操作，等待计算结果的线程的阻塞解除是通过AQS的acquire操作实现的。
SynchronousQueues：SynchronousQueues类使用了内部的等待节点，这些节点可以用于协调生产者和消费者。同时，它使用AQS同步状态来控制当某个消费者消费当前一项时，允许一个生产者继续生产，反之亦然。
除了这些j.u.c提供的工具，还可以基于AQS自定义符合自己需求的同步器。
AQS就学习到这，如果有描述不当的地方，还请留言交流。了解了AQS后下一步准备详细学习基于AQS的工具类。
CountDownLatch
1、应用场景
CountDownLatch是并发包中用来控制一个或者多个线程等待其他线程完成操作的并发工具类。现以工作中的一个场景来描述下CountDownLatch的应用，代码如下：
/*
模拟工作中的一个需求场景：
用户会选择多个算法来计算费用，最后会将所有算法计算出的费用做一个加权求平均数，这个平均数是最终的费用。
每个算法的复杂度都不一样，打算每个线程负责一个算法的实现，所有的线程执行完成，最后再求平均数。
1、为每个算法创建一个线程，每个线程负责一个算法的实现
2、通过CountDownLatch来控制所有算法线程的同步
3、全部计算完成后再求平均数
*/
public class CountDownLatchTask {
public static void main(String[] args) {
CountDownLatchTask countDownLatchTask = new CountDownLatchTask();
countDownLatchTask.startThreads(5);
}
//根据线程数和选择的算法 调度算法对应的实现
private void startThreads(int threadNumber) {
CountDownLatch countDownLatch = new CountDownLatch(threadNumber);
for (int i = 0; i < threadNumber; i++) {
new Thread(new Runnable() {
@Override
public void run() {
System.out.println("线程算法实现：" + Thread.currentThread().getName());
countDownLatch.countDown();
}
}).start();
}
try {
countDownLatch.await();
System.out.println("加权求平均数");
} catch (InterruptedException e) {
e.printStackTrace();
}
}
}
在分析原理实现前，总结下CountDownLatch的作用就是阻塞其他线程直到条件允许后才释放该阻塞，除了上述这个小案例，实际工作中还有很多可以使用CountDownLatch的场景，比如解析Excel文件时可以同时解析多个Sheet页，所有的Sheet解析完成才算完成了Excel文件的解析。从这个代码中也可以看到CountDownLatch的主要方法就是await和countDown，下面将以这两个方法来分析下CountDownLatch的原理实现。
2、 源码原理解析
2.1 await方法
调用await方法会阻塞当前线程直到计数器的数值为0，方法如下:
public void await() throws InterruptedException {
sync.acquireSharedInterruptibly(1); //共享式获取AQS的同步状态
}
调用的是AQS的acquireSharedInterruptibly方法：
public final void acquireSharedInterruptibly(int arg)
throws InterruptedException {
if (Thread.interrupted())//线程中断 说明闭锁对线程中断敏感
throw new InterruptedException();
if (tryAcquireShared(arg) < 0) //闭锁未使用完成 线程进入同步队列自旋等待
doAcquireSharedInterruptibly(arg);
}
其中tryAcquireShared依赖的是Sync的实现，CountDownLatch的Sync只提供了一种方式，而ReentrantLock、ReentrantReadWriteLock及Semaphore 提供了多重方式， CountDownLatch代码如下：
protected int tryAcquireShared(int acquires) {
return (getState() == 0) ? 1 : -1; //AQS的同步状态为0则闭锁结束 可以进行下一步操作
}
doAcquireSharedInterruptibly方法就不再赘述，和之前Semaphore的实现是一致的，本质上仍然是AQS同步队列的入队自旋等待。
2.2 countDown方法
调用countDown方法会将计数器的数值减1直到计数器为0，方法如下:
public void countDown() {
sync.releaseShared(1);
}
和Semaphore一样，调用的是AQS的releaseShared方法：
public final boolean releaseShared(int arg) {
if (tryReleaseShared(arg)) {//减少闭锁的计数器
doReleaseShared();//唤醒后续线程节点
return true;
}
return false;
}
其中tryReleaseShared依赖的是Sync的实现，和之前的ReentrantLock、ReentrantReadWriteLock及Semaphore相比，CountDownLatch的Sync只提供了一种方式，代码如下：
protected boolean tryReleaseShared(int releases) {
// Decrement count; signal when transition to zero
for (;;) {
int c = getState();
if (c == 0)
return false; //计数器已经是0了
int nextc = c-1; //计数器减1
if (compareAndSetState(c, nextc)) //CAS更新同步状态
return nextc == 0;
}
}
唤醒后续线程节点的doReleaseShared也不再赘述，和之前Semaphore的实现是一致的。
总结：CountDownLatch类使用AQS同步状态来表示计数。在await时，所有的线程进入同步队列自旋等待，在countDown时，获取闭锁成功的线程会减少闭锁的计数器，同时唤醒后续线程取获取闭锁，直到await中的计数器为0，获取到闭锁的线程才可以通过，执行下一步操作。
Semaphore
1、 应用场景
Semaphore用来控制同时访问某个特定资源的操作数量，或者同时执行某个指定操作的数量。还可以用来实现某种资源池限制，或者对容器施加边界。
(假设有10个人在银行办理业务，只有2个工作窗口)
1.1 当成锁使用
控制同时访问某个特定资源的操作数量，代码如下：
public class SemaphoreLock {
public static void main(String[] args) {
//1、信号量为1时 相当于普通的锁 信号量大于1时 共享锁
Output o = new Output();
for (int i = 0; i < 5; i++) {
new Thread(() -> o.output()).start();
}
}
}
class Output {
Semaphore semaphore = new Semaphore(1);
public void output() {
try {
semaphore.acquire();
System.out.println(Thread.currentThread().getName() + " start at " + System.currentTimeMillis());
Thread.sleep(1000);
System.out.println(Thread.currentThread().getName() + " stop at " + System.currentTimeMillis());
}catch(Exception e) {
e.printStackTrace();
}finally {
semaphore.release();
}
}
}
1.2 线程通信信号
线程间通信，代码如下：
public class SemaphoreCommunication {
public static void main(String[] args) {
//2、线程间进行通信
Semaphore semaphore = new Semaphore(1);
new SendingThread(semaphore,"SendingThread");
new ReceivingThread(semaphore,"ReceivingThread");
}
}
class SendingThread extends Thread {
Semaphore semaphore;
String name;
public SendingThread(Semaphore semaphore,String name) {
this.semaphore = semaphore;
this.name = name;
new Thread(this).start();
}
public void run() {
try {
semaphore.acquire();
for (int i = 0; i < 5; i++) {
System.out.println(name + ":" + i);
Thread.sleep(1000);
}
} catch (Exception e) {
e.printStackTrace();
}
semaphore.release();
}
}
class ReceivingThread extends Thread {
Semaphore semaphore;
String name;
public ReceivingThread(Semaphore semaphore,String name) {
this.semaphore = semaphore;
this.name = name;
new Thread(this).start();
}
public void run() {
try {
semaphore.acquire();
for (int i = 0; i < 5; i++) {
System.out.println(name + ":" + i);
Thread.sleep(1000);
}
} catch (Exception e) {
e.printStackTrace();
}
semaphore.release();
}
}
1.3 资源池限制
对资源池进行资源限制，代码如下：
public class SemaphoreConnect {
public static void main(String[] args) throws Exception {
//3、模拟连接池数量限制
ExecutorService executorService = Executors.newCachedThreadPool();
for (int i = 0; i < 200; i++) {
executorService.submit(new Runnable() {
@Override
public void run() {
Connection.getInstance().connect();
}
});
}
executorService.shutdown();
executorService.awaitTermination(1, TimeUnit.DAYS);
}
}
class Connection {
private static Connection instance = new Connection();
private Semaphore semaphores = new Semaphore(10,true);
private int connections = 0;
private Connection() {
}
public static Connection getInstance() {
return instance;
}
public void connect() {
try {
semaphores.acquire();
doConnect();
} catch (InterruptedException e) {
e.printStackTrace();
}finally {
semaphores.release();
}
}
private void doConnect() {
synchronized (this) {
connections ++;
System.out.println("current get connections is : " + connections);
}
try {
Thread.sleep(2000);
} catch (InterruptedException e) {
e.printStackTrace();
}
synchronized (this) {
connections --;
System.out.println("after release current connections is : " + connections);
}
}
}
1.4 容器边界限制
对容器进行边界限制，代码如下：
public class SemaphoreBoundedList {
public static void main(String[] args) {
//4、容器边界限制
final BoundedList ba = new BoundedList(5);
Runnable runnable1 = new Runnable() {
public void run() {
try {
ba.add("John");
ba.add("Martin");
ba.add("Adam");
ba.add("Prince");
ba.add("Tod");
System.out.println("Available Permits : " + ba.getSemaphore().availablePermits());
ba.add("Tony");
System.out.println("Final list: " + ba.getArrayList());
}catch (InterruptedException ie) {
Thread.interrupted();
}
}
};
Runnable runnable2 = new Runnable() {
public void run() {
try {
System.out.println("Before removing elements: "+ ba.getArrayList());
Thread.sleep(5000);
ba.remove("Martin");
ba.remove("Adam");
}catch (InterruptedException ie) {
Thread.interrupted();
}
}
};
Thread thread1 = new Thread(runnable1);
Thread thread2 = new Thread(runnable2);
thread1.start();
thread2.start();
}
}
class BoundedList<T> {
private final Semaphore semaphore;
private List arrayList;
BoundedList(int limit) {
this.arrayList = Collections.synchronizedList(new ArrayList());
this.semaphore = new Semaphore(limit);
}
public boolean add(T t) throws InterruptedException {
boolean added = false;
semaphore.acquire();
try {
added = arrayList.add(t);
return added;
} finally {
if (!added)
semaphore.release();
}
}
public boolean remove(T t) {
boolean wasRemoved = arrayList.remove(t);
if (wasRemoved)
semaphore.release();
return wasRemoved;
}
public void remove(int index) {
arrayList.remove(index);
semaphore.release();
}
public List getArrayList() {
return arrayList;
}
public Semaphore getSemaphore() {
return semaphore;
}
}
2、 源码原理解析
2.1 获取信号
获取信号的方法如下:
public void acquire() throws InterruptedException {
sync.acquireSharedInterruptibly(1);//共享式获取AQS的同步状态
}
调用的是AQS的acquireSharedInterruptibly方法：
public final void acquireSharedInterruptibly(int arg)
throws InterruptedException {
if (Thread.interrupted())//线程中断 说明信号量对线程中断敏感
throw new InterruptedException();
if (tryAcquireShared(arg) < 0) //获取信号量失败 线程进入同步队列自旋等待
doAcquireSharedInterruptibly(arg);
}
其中tryAcquireShared依赖的是Sync的实现，Sync提供了公平和非公平式的方式，先看非公平式。
protected int tryAcquireShared(int acquires) {
return nonfairTryAcquireShared(acquires);
}
final int nonfairTryAcquireShared(int acquires) {
for (;;) {
int available = getState();//同步状态 当前的信号量许可数
int remaining = available - acquires;//减去释放的信号量 剩余信号量许可数
if (remaining < 0 ||//剩余信号量小于0 直接返回remaining 不做CAS
compareAndSetState(available, remaining))//CAS更新
return remaining;
}
}
再看下公平式的。
protected int tryAcquireShared(int acquires) {
for (;;) {
if (hasQueuedPredecessors())//判断同步队列如果存在前置节点 获取信号量失败 其他和非公平式是一致的
return -1;
int available = getState();
int remaining = available - acquires;
if (remaining < 0 ||
compareAndSetState(available, remaining))
return remaining;
}
}
最后来看下，如果未获取到信号量的处理方法doAcquireSharedInterruptibly。
private void doAcquireSharedInterruptibly(int arg)
throws InterruptedException {
final Node node = addWaiter(Node.SHARED);//线程进入同步队列
boolean failed = true;
try {
for (;;) {//自旋
final Node p = node.predecessor();
if (p == head) {//当前节点的前置节点是AQS的头节点 即自己是AQS同步队列的第一个节点
int r = tryAcquireShared(arg); //再去获取信号量
if (r >= 0) {//获取成功
setHeadAndPropagate(node, r);//退出自旋
p.next = null; // help GC
failed = false;
return;
}
}
if (shouldParkAfterFailedAcquire(p, node) &&
parkAndCheckInterrupt())
throw new InterruptedException();
}
} finally {
if (failed)
cancelAcquire(node); //获取失败 就取消获取
}
}
2.2 释放信号
释放信号的方法如下：
public void release() {
sync.releaseShared(1);
}
调用的是AQS的releaseShared方法：
public final boolean releaseShared(int arg) {
if (tryReleaseShared(arg)) {//释放信号量
doReleaseShared();//唤醒后续的线程节点
return true;
}
return false;
}
tryReleaseShared交由子类Sync实现，代码如下：
protected final boolean tryReleaseShared(int releases) {
for (;;) {
int current = getState();//当前信号量许可数
int next = current + releases; //当前信号量许可数+释放的信号量许可数
if (next < current) // overflow 这个分支我看着永远走不进来呢
throw new Error("Maximum permit count exceeded");
if (compareAndSetState(current, next))//CAS更新当前信号量许可数
return true;
}
}
释放成功后，则继续调用doReleaseShared，唤醒后续线程节点可以来争取信号量了。
private void doReleaseShared() {
for (;;) {
Node h = head; //头节点
if (h != null && h != tail) {//同步队列中存在线程等待
int ws = h.waitStatus; //头节点线程状态
if (ws == Node.SIGNAL) {//头节点线程状态为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;
}
}
总结：Semaphore使用AQS同步状态来保存信号量的当前计数。它里面定义的acquireSharedInterruptibly方法会减少计数，当计数为非正值时阻塞线程，releaseShared方法会增加计数，在计数不超过信号量限制时要解除线程的阻塞。
CyclicBarrier
栅栏类似于闭锁，它能阻塞一组线程直到某个事件的发生。栅栏与闭锁的关键区别在于，所有的线程必须同时到达栅栏位置，才能继续执行。闭锁用于等待事件，而栅栏用于等待其他线程。
CyclicBarrier可以使一定数量的线程反复地在栅栏位置处汇集。当线程到达栅栏位置时将调用await方法，这个方法将阻塞直到所有线程都到达栅栏位置。如果所有线程都到达栅栏位置，那么栅栏将打开，此时所有的线程都将被释放，而栅栏将被重置以便下次使用。
1、应用程序示例
我们看一个CyclicBarrier的应用示例：
public class CyclicBarrierTest {
// 自定义工作线程
private static class Worker extends Thread {
private CyclicBarrier cyclicBarrier;
public Worker(CyclicBarrier cyclicBarrier) {
this.cyclicBarrier = cyclicBarrier;
}
@Override
public void run() {
super.run();
try {
System.out.println(Thread.currentThread().getName() + "开始等待其他线程");
cyclicBarrier.await();
System.out.println(Thread.currentThread().getName() + "开始执行");
// 工作线程开始处理，这里用Thread.sleep()来模拟业务处理
Thread.sleep(1000);
System.out.println(Thread.currentThread().getName() + "执行完毕");
} catch (Exception e) {
e.printStackTrace();
}
}
}
public static void main(String[] args) {
int threadCount = 3;
CyclicBarrier cyclicBarrier = new CyclicBarrier(threadCount);
for (int i = 0; i < threadCount; i++) {
System.out.println("创建工作线程" + i);
Worker worker = new Worker(cyclicBarrier);
worker.start();
}
}
}
运行结果（不唯一）：
创建工作线程0
创建工作线程1
Thread-0开始等待其他线程
创建工作线程2
Thread-1开始等待其他线程
Thread-2开始等待其他线程
Thread-2开始执行
Thread-0开始执行
Thread-1开始执行
Thread-1执行完毕
Thread-0执行完毕
Thread-2执行完毕
在上述代码中，我们自定义的工作线程必须要等所有参与线程开始之后才可以执行，我们可以使用CyclicBarrier类来帮助我们完成。从程序的执行结果中也可以看出，所有的工作线程都运行await()方法之后都到达了栅栏位置，然后，3个工作线程才开始执行业务处理。
2 CyclicBarrier源码解析
通过类图我们可以看到，CyclicBarrier内部使用了ReentrantLock和Condition两个类。它有两个构造函数：
public CyclicBarrier(int parties) {
this(parties, null);
}
public CyclicBarrier(int parties, Runnable barrierAction) {
if (parties <= 0) throw new IllegalArgumentException();
this.parties = parties;
this.count = parties;
this.barrierCommand = barrierAction;
}
CyclicBarrier默认的构造方法是CyclicBarrier(int parties)，其参数表示屏障拦截的线程数量，每个线程使用await()方法告诉CyclicBarrier我已经到达了屏障，然后当前线程被阻塞。
CyclicBarrier的另一个构造函数CyclicBarrier(int parties, Runnable barrierAction)，用于线程到达屏障时，优先执行barrierAction，方便处理更复杂的业务场景。
2.1 await方法
调用await方法的线程告诉CyclicBarrier自己已经到达同步点，然后当前线程被阻塞。直到parties个参与线程调用了await方法，CyclicBarrier同样提供带超时时间的await和不带超时时间的await方法：
public int await() throws InterruptedException, BrokenBarrierException {
try {
// 不超时等待
return dowait(false, 0L);
} catch (TimeoutException toe) {
throw new Error(toe); // cannot happen
}
}
public int await(long timeout, TimeUnit unit)
throws InterruptedException,
BrokenBarrierException,
TimeoutException {
return dowait(true, unit.toNanos(timeout));
}
这两个方法最终都会调用dowait(boolean, long)方法，它也是CyclicBarrier的核心方法，该方法定义如下：
private int dowait(boolean timed, long nanos)
throws InterruptedException, BrokenBarrierException,
TimeoutException {
// 获取独占锁
final ReentrantLock lock = this.lock;
lock.lock();
try {
// 当前代
final Generation g = generation;
// 如果这代损坏了，抛出异常
if (g.broken)
throw new BrokenBarrierException();
// 如果线程中断了，抛出异常
if (Thread.interrupted()) {
// 将损坏状态设置为true
// 并通知其他阻塞在此栅栏上的线程
breakBarrier();
throw new InterruptedException();
}
// 获取下标
int index = --count;
// 如果是 0，说明最后一个线程调用了该方法
if (index == 0) { // tripped
boolean ranAction = false;
try {
final Runnable command = barrierCommand;
// 执行栅栏任务
if (command != null)
command.run();
ranAction = true;
// 更新一代，将count重置，将generation重置
// 唤醒之前等待的线程
nextGeneration();
return 0;
} finally {
// 如果执行栅栏任务的时候失败了，就将损坏状态设置为true
if (!ranAction)
breakBarrier();
}
}
// loop until tripped, broken, interrupted, or timed out
for (;;) {
try {
// 如果没有时间限制，则直接等待，直到被唤醒
if (!timed)
trip.await();
// 如果有时间限制，则等待指定时间
else if (nanos > 0L)
nanos = trip.awaitNanos(nanos);
} catch (InterruptedException ie) {
// 当前代没有损坏
if (g == generation && ! g.broken) {
// 让栅栏失效
breakBarrier();
throw ie;
} else {
// 上面条件不满足，说明这个线程不是这代的
// 就不会影响当前这代栅栏的执行，所以，就打个中断标记
Thread.currentThread().interrupt();
}
}
// 当有任何一个线程中断了，就会调用breakBarrier方法
// 就会唤醒其他的线程，其他线程醒来后，也要抛出异常
if (g.broken)
throw new BrokenBarrierException();
// g != generation表示正常换代了，返回当前线程所在栅栏的下标
// 如果 g == generation，说明还没有换代，那为什么会醒了？
// 因为一个线程可以使用多个栅栏，当别的栅栏唤醒了这个线程，就会走到这里，所以需要判断是否是当前代。
// 正是因为这个原因，才需要generation来保证正确。
if (g != generation)
return index;
// 如果有时间限制，且时间小于等于0，销毁栅栏并抛出异常
if (timed && nanos <= 0L) {
breakBarrier();
throw new TimeoutException();
}
}
} finally {
// 释放独占锁
lock.unlock();
}
}
dowait(boolean, long)方法的主要逻辑处理比较简单，如果该线程不是最后一个调用await方法的线程，则它会一直处于等待状态，除非发生以下情况：
- 最后一个线程到达，即index == 0
- 某个参与线程等待超时
- 某个参与线程被中断
- 调用了CyclicBarrier的reset()方法。该方法会将屏障重置为初始状态
在上面的源代码中，我们可能需要注意Generation 对象，在上述代码中我们总是可以看到抛出BrokenBarrierException异常，那么什么时候抛出异常呢？如果一个线程处于等待状态时，如果其他线程调用reset()，或者调用的barrier原本就是被损坏的，则抛出BrokenBarrierException异常。同时，任何线程在等待时被中断了，则其他所有线程都将抛出BrokenBarrierException异常，并将barrier置于损坏状态。
同时，Generation描述着CyclicBarrier的更新换代。在CyclicBarrier中，同一批线程属于同一代。当有parties个线程到达barrier之后，generation就会被更新换代。其中broken标识该当前CyclicBarrier是否已经处于中断状态。
private static class Generation {
boolean broken = false;
}
默认barrier是没有损坏的。当barrier损坏了或者有一个线程中断了，则通过breakBarrier()来终止所有的线程：
private void breakBarrier() {
generation.broken = true;
count = parties;
trip.signalAll();
}
在breakBarrier()中除了将broken设置为true，还会调用signalAll将在CyclicBarrier处于等待状态的线程全部唤醒。
当所有线程都已经到达barrier处（index == 0），则会通过nextGeneration()进行更新换地操作，在这个步骤中，做了三件事：唤醒所有线程，重置count，generation：
private void nextGeneration() {
// signal completion of last generation
trip.signalAll();
// set up next generation
count = parties;
generation = new Generation();
}
除了上面讲到的栅栏更新换代以及损坏状态，我们在使用CyclicBarrier时还要要注意以下几点：
- CyclicBarrier使用独占锁来执行await方法，并发性可能不是很高
- 如果在等待过程中，线程被中断了，就抛出异常。但如果中断的线程所对应的CyclicBarrier不是这代的，比如，在最后一次线程执行signalAll后，并且更新了这个“代”对象。在这个区间，这个线程被中断了，那么，JDK认为任务已经完成了，就不必在乎中断了，只需要打个标记。该部分源码已在dowait(boolean, long)方法中进行了注释。
- 如果线程被其他的CyclicBarrier唤醒了，那么g肯定等于generation，这个事件就不能return了，而是继续循环阻塞。反之，如果是当前CyclicBarrier唤醒的，就返回线程在CyclicBarrier的下标。完成了一次冲过栅栏的过程。该部分源码已在dowait(boolean, long)方法中进行了注释。
3 CyclicBarrier和CountDownLatch的区别
CountDownLatch的计数器只能使用一次，而CyclicBarrier的计数器可以使用reset()方法重置，可以使用多次，所以CyclicBarrier能够处理更为复杂的场景；
CyclicBarrier还提供了一些其他有用的方法，比如getNumberWaiting()方法可以获得CyclicBarrier阻塞的线程数量，isBroken()方法用来了解阻塞的线程是否被中断；
CountDownLatch允许一个或多个线程等待一组事件的产生，而CyclicBarrier用于等待其他线程运行到栅栏位置。
ReentrantLock
1、 产生背景
前面我们已经学习过了synchronized，这个关键字可以确保对象在并发访问中的原子性、可见性和有序性，这个关键字的底层交由了JVM通过C++来实现，既然是JVM实现，就依赖于JVM，程序员就无法在Java层面进行扩展和优化，肯定就灵活性不高，比如程序员在使用时就无法中断一个正在等待获取锁的线程，或者无法在请求一个锁时无限的等待下去。基于这样一个背景，Doug Lea构建了一个在内存语义上和synchronized一样效果的Java类，同时还扩展了其他一些高级特性，比如定时的锁等待、可中断的锁等待和公平性等，这个类就是ReentrantLock。
2、 源码原理解析
2.1 可重入性原理
ReentrantLock实现了在内存语义上的synchronized，固然也是支持可重入的，那么ReentrantLock是如何支持的呢，让我们以非公平锁的实现看下ReentrantLock的可重入，代码如下：
final boolean nonfairTryAcquire(int acquires) {
final Thread current = Thread.currentThread();//当前线程
int c = getState();
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;
}
return false;
}
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;//只有线程全部释放才返回true
setExclusiveOwnerThread(null); //同步队列的线程都可以去获取同步状态了
}
setState(c);
return free;
}
看到这也就明白了上文说的ReentrantLock类使用AQS同步状态来保存锁重复持有的次数。当锁被一个线程获取时，ReentrantLock也会记录下当前获得锁的线程标识，以便检查是否是重复获取，以及当错误的线程试图进行解锁操作时检测是否存在非法状态异常。
2.2 获取和释放锁
如下是获取和释放锁的方法：
public void lock() {
sync.lock();//获取锁
}
public void unlock() {
sync.release(1); //释放锁
}
获取锁的时候依赖的是内部类Sync的lock()方法，该方法又有2个实现类方法，分别是非公平锁NonfairSync和公平锁FairSync，具体咱们下一小节分析。再来看下释放锁，释放锁的时候实际调用的是AQS的release方法，代码如下：
public final boolean release(int arg) {
if (tryRelease(arg)) {//调用子类的tryRelease 实际就是Sync的tryRelease
Node h = head;//取同步队列的头节点
if (h != null && h.waitStatus != 0)//同步队列头节点不为空且不是初始状态
unparkSuccessor(h);//释放头节点 唤醒后续节点
return true;
}
return false;
}
Sync的tryRelease就是上一小节的重入释放方法，如果是同一个线程，那么锁的重入次数就依次递减，直到重入次数为0，此方法才会返回true,此时断开头节点唤醒后续节点去获取AQS的同步状态。
2.3 公平锁和非公平锁
公平锁还是非公平锁取决于ReentrantLock的构造方法，默认无参构造方法是NonfairSync，含参构造方法，入参true为FairSync，入参false为NonfairSync。
public ReentrantLock() {
sync = new NonfairSync();
}
public ReentrantLock(boolean fair) {
sync = fair ? new FairSync() : new NonfairSync();
}
再分别来看看非公平锁和公平锁的实现。
static final class NonfairSync extends Sync {
private static final long serialVersionUID = 7316153563782823691L;
/**
* Performs lock. Try immediate barge, backing up to normal
* acquire on failure.
*/
final void lock() {
if (compareAndSetState(0, 1))//通过CAS来获取同步状态 也就是锁
setExclusiveOwnerThread(Thread.currentThread());//获取成功线程占有锁
else
acquire(1);//获取失败 进入AQS同步队列排队等待 执行AQS的acquire方法
}
protected final boolean tryAcquire(int acquires) {
return nonfairTryAcquire(acquires);
}
}
在AQS的acquire方法中先调用子类tryAcquire，也就是nonfairTryAcquire，见2.1小节。可以看出非公平锁中，抢到AQS的同步状态的未必是同步队列的首节点，只要线程通过CAS抢到了同步状态或者在acquire中抢到同步状态，就优先占有锁，而相对同步队列这个严格的FIFO队列来说，所以会被认为是非公平锁。
static final class FairSync extends Sync {
private static final long serialVersionUID = -3000897897090466540L;
final void lock() {
acquire(1);//严格按照AQS的同步队列要求去获取同步状态
}
/**
* Fair version of tryAcquire. Don't grant access unless
* recursive call or no waiters or is first.
*/
protected final boolean tryAcquire(int acquires) {
final Thread current = Thread.currentThread();//获取当前线程
int c = getState();
if (c == 0) {//锁未被抢占
if (!hasQueuedPredecessors() &&//没有前驱节点
compareAndSetState(0, acquires)) {//CAS获取同步状态
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;
}
}
公平锁的实现直接调用AQS的acquire方法，acquire中调用tryAcquire。和非公平锁相比，这里不会执行一次CAS，接下来在tryAcquire去抢占锁的时候，也会先调用hasQueuedPredecessors看看前面是否有节点已经在等待获取锁了，如果存在则同步队列的前驱节点优先。
public final boolean hasQueuedPredecessors() {
// The correctness of this depends on head being initialized
// before tail and on head.next being accurate if the current
// thread is first in queue.
Node t = tail; // Read fields in reverse initialization order 尾节点
Node h = head;//头节点
Node s;
return h != t &&//头尾节点不是一个 即队列存在排队线程
((s = h.next) == null || s.thread != Thread.currentThread());//头节点的后续节点为空或者不是当前线程
}
虽然公平锁看起来在公平性上比非公平锁好，但是公平锁为此付出了大量线程切换的代价，而非公平锁在锁的获取上不能保证公平，就有可能出现锁饥饿，即有的线程多次获取锁而有的线程获取不到锁，没有大量的线程切换保证了非公平锁的吞吐量。
3、 应用
3.1普通的线程锁
标准形式如下：
ReentrantLock lock = new ReentrantLock();
try {
lock.lock();
//……
}finally {
lock.unlock();
}
这种用法和synchronized效果是一样的，但是必须显示的声明lock和unlock。
3.2 带限制的锁
public boolean tryLock()// 尝试获取锁,立即返回获取结果 轮询锁
public boolean tryLock(long timeout, TimeUnit unit)//尝试获取锁,最多等待 timeout 时长 超时锁
public void lockInterruptibly()//可中断锁,调用线程 interrupt 方法,则锁方法抛出 InterruptedException 中断锁
3.3 等待/通知模型
内置队列存在一些缺陷，每个内置锁只能关联一个条件队列(_WaitSet)，这导致多个线程可能会在同一个条件队列上等待不同的条件谓词，如果每次使用notify唤醒条件队列，可能会唤醒错误的线程导致唤醒失败，但是如果使用notifyAll的话，能唤醒到正确的线程，因为所有的线程都会被唤醒，这也带来一个问题，就是不应该被唤醒的在被唤醒后发现不是自己等待的条件谓词转而又被挂起。这样的操作会带来系统的资源浪费，降低系统性能。这个时候推荐使用显式的Lock和Condition来替代内置锁和条件队列，从而控制多个条件谓词的情况，达到精确的控制线程的唤醒和挂起。具体后面再来分析下JVM的内置锁、条件队列模型和显式的Lock、Condition模型，实际上在AQS里面也提到了Lock、Condition模型。
Condition
在使用Lock之前，我们使用的最多的同步方式应该是synchronized关键字来实现同步方式了。配合Object的wait()、notify()系列方法可以实现等待/通知模式。Condition接口也提供了类似Object的监视器方法，与Lock配合可以实现等待/通知模式，但是这两者在使用方式以及功能特性上还是有差别的。Object和Condition接口的一些对比
1、Condition接口介绍和示例
首先我们需要明白condition对象是依赖于lock对象的，意思就是说condition对象需要通过lock对象进行创建出来(调用Lock对象的newCondition()方法)。consition的使用方式非常的简单。但是需要注意在调用方法前获取锁。
package com.ydl.test.juc;
import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;
import java.util.concurrent.locks.Condition;
import java.util.concurrent.locks.Lock;
import java.util.concurrent.locks.ReentrantLock;
public class ConditionUseCase {
public Lock lock = new ReentrantLock();
public Condition condition = lock.newCondition();
public static void main(String[] args) {
ConditionUseCase useCase = new ConditionUseCase();
ExecutorService executorService = Executors.newFixedThreadPool (2);
executorService.execute(new Runnable() {
@Override
public void run() {
useCase.conditionWait();
}
});
executorService.execute(new Runnable() {
@Override
public void run() {
useCase.conditionSignal();
}
});
}
public void conditionWait() {
lock.lock();
try {
System.out.println(Thread.currentThread().getName() + "拿到锁了");
System.out.println(Thread.currentThread().getName() + "等待信号");
condition.await();
System.out.println(Thread.currentThread().getName() + "拿到信号");
}catch (Exception e){
}finally {
lock.unlock();
}
}
public void conditionSignal() {
lock.lock();
try {
Thread.sleep(5000);
System.out.println(Thread.currentThread().getName() + "拿到锁了");
condition.signal();
System.out.println(Thread.currentThread().getName() + "发出信号");
}catch (Exception e){
}finally {
lock.unlock();
}
}
}
1 pool-1-thread-1拿到锁了
2 pool-1-thread-1等待信号
3 pool-1-thread-2拿到锁了
4 pool-1-thread-2发出信号
5 pool-1-thread-1拿到信号
如示例所示，一般都会将Condition对象作为成员变量。当调用await()方法后，当前线程会释放锁并在此等待，而其他线程调用Condition对象的signal()方法，通知当前线程后，当前线程才从await()方法返回，并且在返回前已经获取了锁。
2、Condition接口常用方法
condition可以通俗的理解为条件队列。当一个线程在调用了await方法以后，直到线程等待的某个条件为真的时候才会被唤醒。这种方式为线程提供了更加简单的等待/通知模式。Condition必须要配合锁一起使用，因为对共享状态变量的访问发生在多线程环境下。一个Condition的实例必须与一个Lock绑定，因此Condition一般都是作为Lock的内部实现。
-
await() ：造成当前线程在接到信号或被中断之前一直处于等待状态。
-
await(long time, TimeUnit unit) ：造成当前线程在接到信号、被中断或到达指定等待时间之前一直处于等待状态。
-
awaitNanos(long nanosTimeout) ：造成当前线程在接到信号、被中断或到达指定等待时间之前一直处于等待状态。返回值表示剩余时间，如果在nanosTimesout之前唤醒，那么返回值 = nanosTimeout - 消耗时间，如果返回值 <= 0 ,则可以认定它已经超时了。
-
awaitUninterruptibly() ：造成当前线程在接到信号之前一直处于等待状态。【注意：该方法对中断不敏感】。
-
awaitUntil(Date deadline) ：造成当前线程在接到信号、被中断或到达指定最后期限之前一直处于等待状态。如果没有到指定时间就被通知，则返回true，否则表示到了指定时间，返回返回false。
-
signal() ：唤醒一个等待线程。该线程从等待方法返回前必须获得与Condition相关的锁。
-
signal()All ：唤醒所有等待线程。能够从等待方法返回的线程必须获得与Condition相关的锁。
1615
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
