有一次听到同事谈及AQS时,我有很多点懵,
只知道入队和出队,CLH(Craig,Landin and Hagersten)锁,并不了解AQS的应用,
同时结合之前遇到的多线程等待应用场景,发现CountDownLatch是使用AQS实现的线程等待,
本文即通过实战和源码分析,探究CountDownLatch是如何利用AQS实现线程等待的,
帮助读者轻松应对知识交流与考核。
同步辅助工具,允许一个或多个线程等待其他线程操作完成。
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获取结果。
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;
}
@Override
public 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执行结束后,释放线程,继续执行后续的逻辑。
下面根据源码分析CountDownLatch是如何实现线程等待以及释放资源的。
首先从初始化CountDownLatch开始讲解,源码如下图所示,
由源码可知,通过count参数初始化AQS的同步状态数state,
Sync即CountDownLatch中继承AbstractQueuedSynchronizer的内部类,
通过setState(count)初始化state,这个放在Sync中讲,先提示一下。
位置:java.util.concurrent.CountDownLatch#CountDownLatch
下面进入Sync源码,如下图所示,
由图可知,Sync是CountDownLatch的内部私有静态类,继承AbstractQueuedSynchronizer类,
构造函数参数为count,用于初始化state,即setState(count),
通过getCount()调用getState方法获取同步状态数量。
同时重写了tryAcquireShared和tryReleaseShared两个方法,
用于获取共享资源和释放共享资源。
位置:java.util.concurrent.CountDownLatch.Sync
获取共享资源和释放共享资源的源码如下图所示,
由图可知,tryAcquireShared通过获取同步状态数量标识当前资源状态,
同步状态不为0时,返回-1,为0时返回1,为后续提供操作标识,后文会反复用到,到时详解。
同步状态减1通过countDown方法实现,源码如下图所示,
由图可知,该方法调用了releaseShared方法,实现状态减1,这里还看不出具体的逻辑,
接着往下看,进入方法releaseShared。
位置:java.util.concurrent.CountDownLatch#countDown
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。
综上分析,CountDownLatch控制线程等待的逻辑是在await中实现的,
因为,上面的逻辑只是实现了同步状态减1,以及释放线程标记等工作,没有阻塞线程,
所以,在await阻塞线程,当所有线程均完成各自逻辑时,即同步状态state=0,才开启“闸门”,释放锁。
await源码如下图所示,由图可知,await调用acquireSharedInterruptly方法,
当同步状态state=0时,立即返回。
位置:java.util.concurrent.CountDownLatch#await()
线程等待。同步状态state不为0时,线程间相互等待。
acquireSharedInterruptibly源码如下图所示,
由图可知,判断条件通过tryAcquireShared获取,当state不为0时,返回-1,参见上文的tryAcquireShared方法,
调用doAcquireSharedInterrutly方法,实现线程等待。
位置:java.util.concurrent.locks.AbstractQueuedSynchronizer#acquireSharedInterruptibly
线程等待具体实现,源码如下图所示,
由图可知,每次调用都会向队列插入一个新的节点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多线程同步状态递减以及相互等待的分析。
(1)CountDownLatch是一次性的线程等待工具,实现多线程相互等待,直到所有线程均完成执行逻辑,用完即抛,无法重用;
(2)countDown方法使同步状态减1,当一个线程执行完成后,调用countDown,标识当前线程已完成,当state=0时,释放节点的线程占用,这也是CountDownLatch无法重用的直接原因,当然,没有重复保存state也是另一个原因;
(3)await是线程等待的核心,当同步状态state不为0时,会自旋等待,而不触发跳出自旋,当state=0时,才会立即返回,跳出自旋,结束线程等待;
(4)当某个线程出现异常时,这里需要格外注意,为保证程序正常中断,需要手动捕获异常,同时调用countDown方法,或者使用重试机制,否则线程不会退出,因为state最终的状态不为0,有一个线程线程而没有减1。