JUC包：CountDownLatch源码+实例讲解

1 缘起

有一次听到同事谈及AQS时，我有很多点懵，
只知道入队和出队，CLH（Craig，Landin and Hagersten）锁，并不了解AQS的应用，
同时结合之前遇到的多线程等待应用场景，发现CountDownLatch是使用AQS实现的线程等待，
本文即通过实战和源码分析，探究CountDownLatch是如何利用AQS实现线程等待的，
帮助读者轻松应对知识交流与考核。

2 CountDownLatch

同步辅助工具，允许一个或多个线程等待其他线程操作完成。
CountDownLatch通过给定同步状态数量初始化，即state数量（参见AQS，AbstractQueuedSynchronizer）。
执行过程中，会通过调用countDown方法来阻塞await方法，直到同步状态state为0时，释放所有阻塞的线程，立即返回结果。
CountDownLatch的同步状态数量是一次性的操作，无法重置次数。
如果需要多次使用计数，可以使用CyclicBarrier。
CountDownLatch是通用的同步工具，用途广泛。
CountDownLatch初始化同步状态数量为1，可以作为一个简单的开/关锁存器或门：所有调用await方法的线程都在门处等待，直到线程调用countDown方法开启门。
CountDownLatch初始化同步状态数量为N，线程等待N个线程完成操作或某个线程完成N次。
CountDownLatch非常有用的一个特性是：执行前不要求调用countDown的线程等待同步状态数量达到0，仅仅是通过await方法阻止线程通过，直到所有任务都完成，一次性通过所有线程。
内存一致性影响：同步状态数量达到0之前，先调用countDown()的线程执行优先于其他线程调用await获取结果。

2.1 测试样例

CountDownLatch两个核心方法：countDown和await，
其中，
countDown同步状态数量减1，CountDownLatch继承AbstractQueuedSynchronizer（AQS），通过state属性检测是否获取或释放当前资源，所以，countDown方法主要的任务就是减少state值，释放资源。
await则是阻塞线程，state未达到0时持续自旋，等待，最终所有线程任务执行完成后立即返回，继续执行后面的逻辑。
下面给出具体的测试样例，新建CountDownLatch，初始化同步状态数state=3，执行三次countDown，释放线程，继续执行。

package com.monkey.java_study.juc;import org.apache.commons.lang3.time.StopWatch;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;import java.util.Random;
import java.util.concurrent.CountDownLatch;/*** CountDownLatch测试.** @author xindaqi* @since 2023-02-20 15:00*/
public class CountDownLatchTest {private static final Logger logger = LoggerFactory.getLogger(CountDownLatchTest.class);/*** 线程执行器，* 执行countDown，计数器减一*/static class ThreadRunner implements Runnable {private final CountDownLatch countDownLatch;public ThreadRunner(CountDownLatch countDownLatch) {this.countDownLatch = countDownLatch;}@Overridepublic void run() {try {StopWatch stopWatch = new StopWatch();stopWatch.start();Random random = new Random();int randomBound = 1000;Thread.sleep(random.nextInt(randomBound));stopWatch.stop();logger.info(">>>>>>>>{}, time cost:{}", Thread.currentThread().getName(), stopWatch.formatTime());countDownLatch.countDown();} catch (Exception ex) {throw new RuntimeException(ex);}}}public static void main(String[] args) {StopWatch stopWatch = new StopWatch();stopWatch.start();int threadCount = 3;CountDownLatch countDownLatch = new CountDownLatch(threadCount);for (int i = 0; i < 3; i++) {new Thread(new ThreadRunner(countDownLatch)).start();}try {countDownLatch.await();stopWatch.stop();logger.info(">>>>>>>>Time cost:{}", stopWatch.formatTime());} catch (Exception ex) {throw new RuntimeException(ex);}}
}

测试结果如下图所示，
由结果可知，三个线程各自执行，通过不同的延迟时间模拟程序执行的时间，
执行耗时最长的Thread-2执行结束后，释放线程，继续执行后续的逻辑。

3 源码分析

下面根据源码分析CountDownLatch是如何实现线程等待以及释放资源的。

3.1 初始化

首先从初始化CountDownLatch开始讲解，源码如下图所示，
由源码可知，通过count参数初始化AQS的同步状态数state，
Sync即CountDownLatch中继承AbstractQueuedSynchronizer的内部类，
通过setState(count)初始化state，这个放在Sync中讲，先提示一下。
位置：java.util.concurrent.CountDownLatch#CountDownLatch

3.2 Sync

下面进入Sync源码，如下图所示，
由图可知，Sync是CountDownLatch的内部私有静态类，继承AbstractQueuedSynchronizer类，
构造函数参数为count，用于初始化state，即setState(count)，
通过getCount()调用getState方法获取同步状态数量。
同时重写了tryAcquireShared和tryReleaseShared两个方法，
用于获取共享资源和释放共享资源。
位置：java.util.concurrent.CountDownLatch.Sync

获取共享资源和释放共享资源的源码如下图所示，
由图可知，tryAcquireShared通过获取同步状态数量标识当前资源状态，
同步状态不为0时，返回-1，为0时返回1，为后续提供操作标识，后文会反复用到，到时详解。

3.3 countDown

同步状态减1通过countDown方法实现，源码如下图所示，
由图可知，该方法调用了releaseShared方法，实现状态减1，这里还看不出具体的逻辑，
接着往下看，进入方法releaseShared。
位置：java.util.concurrent.CountDownLatch#countDown

3.3.1 releaseShared

releaseShared源码如下图所示，由图可知，
判断条件中调用了tryReleaseShared方法，为true时才会调用doReleaseShared，否则，直接返回。
其中，tryReleasShared方法由前文可知，
Sync内部类继承AQS，重写了该方法，实现同步状态state减1，state=0返回fasle，否则返回true，
由此可知，releaseShared方法通过tryReleasShared实现状态减1，在state不为0时，不会调用doReleaseShared方法。
当state=0时，才会调用doReleaseShared方法，此时，所有线程已经完成任务，将要全部通过latch（门闩），
由上述可推测，doReleaseShared用于释放资源。
这个方法并没有实现自旋等待，而是在await方法中进行等待的，在state没有达到0时，不会让线程通过。
位置：java.util.concurrent.locks.AbstractQueuedSynchronizer#releaseShared

tryReleaseShared源码标注如下图所示，
由图可知，通过自旋的方式使同步状态减1，state=0返回true，否则返回false，供后续方法判断。
位置：java.util.concurrent.CountDownLatch.Sync#tryReleaseShared

doReleaseShared则是释放资源，源码如下图所示，
由图可知，通过修改节点等待状态（waitStatus）为0，以及取消标记unparkSuccessor释放线程（这个放在后面讲），
通过自旋的方式，依次释放节点标记的线程资源，最终释放所有标记的资源。
位置：java.util.concurrent.locks.AbstractQueuedSynchronizer#doReleaseShared

unparkSuccessor释放节点标记的线程，源码如下图所示，
由源码可知，获取当前节点的后继节点，
后继节点不为空时，通过LockSupport.unpark释放线程标记，
当节点的后继节点不为空时，会释放当前节点标记的线程，即节点不再等待线程，直接释放，
实现最后一个线程执行结束后，取消节点对线程的占用，释放资源。
这里直接取消线程标记，也是导致同步状态state无法重用的直接原因，已经取消标记，后续自然无法使用，
同时，state置为0后，没有重新配置，所以依旧不能重用state。

3.4 await

综上分析，CountDownLatch控制线程等待的逻辑是在await中实现的，
因为，上面的逻辑只是实现了同步状态减1，以及释放线程标记等工作，没有阻塞线程，
所以，在await阻塞线程，当所有线程均完成各自逻辑时，即同步状态state=0，才开启“闸门”，释放锁。
await源码如下图所示，由图可知，await调用acquireSharedInterruptly方法，
当同步状态state=0时，立即返回。
位置：java.util.concurrent.CountDownLatch#await()

3.4.1 acquireSharedInterruptibly

线程等待。同步状态state不为0时，线程间相互等待。
acquireSharedInterruptibly源码如下图所示，
由图可知，判断条件通过tryAcquireShared获取，当state不为0时，返回-1，参见上文的tryAcquireShared方法，
调用doAcquireSharedInterrutly方法，实现线程等待。
位置：java.util.concurrent.locks.AbstractQueuedSynchronizer#acquireSharedInterruptibly

3.4.2 doAcquireSharedInterruptily

线程等待具体实现，源码如下图所示，
由图可知，每次调用都会向队列插入一个新的节点Node.SHARED，
然后自旋，即线程等待，当前节点的前驱节点为头节点时，获取同步状态state，
state不为0时，tryAcquireShared=-1，不会跳出自旋，
继续等待countDown操作，
当countDown使state减为0时，tryAcquireShared返回1，开始执行r>=0后续的逻辑，
跳出自旋，立即返回，即await立即返回，继续执行await后续的逻辑，释放线程等待。

位置：java.util.concurrent.locks.AbstractQueuedSynchronizer#doAcquireSharedInterruptibly

上面提到获取当前节点的前驱节点，通过predecessor方法，
源码如下图所示，由图可知，返回节点的前驱节点。
位置：java.util.concurrent.locks.AbstractQueuedSynchronizer.Node#predecessor

至此完成CountDownLatch多线程同步状态递减以及相互等待的分析。

4 小结

（1）CountDownLatch是一次性的线程等待工具，实现多线程相互等待，直到所有线程均完成执行逻辑，用完即抛，无法重用；
（2）countDown方法使同步状态减1，当一个线程执行完成后，调用countDown，标识当前线程已完成，当state=0时，释放节点的线程占用，这也是CountDownLatch无法重用的直接原因，当然，没有重复保存state也是另一个原因；
（3）await是线程等待的核心，当同步状态state不为0时，会自旋等待，而不触发跳出自旋，当state=0时，才会立即返回，跳出自旋，结束线程等待；
（4）当某个线程出现异常时，这里需要格外注意，为保证程序正常中断，需要手动捕获异常，同时调用countDown方法，或者使用重试机制，否则线程不会退出，因为state最终的状态不为0，有一个线程线程而没有减1。