前言
CountDownLatch 是基于AQS共享模式特定场景开发的一种同步器,也是在JUC并发包里面的内容。功能:一个同步辅助类,在完成一组正在其他线程中执行的操作之前,它允许一个或多个线程一直等待。 countdown英文是倒数的意思,"latch"在英文中也是锁的意思。组合在一起可以理解为倒计时锁,当你调用了这个类型对象中的await方法后,必须要等待这个锁倒数到0,才能继续运行。下面就一起学习下。
CountDownLatch 原理
CountDownLatch 定义了一个计数器,和一个阻塞队列, 通过设置一个计数器来实现的,当计数器的值递减为0之前,阻塞队列里面的线程处于挂起状态,计时器的初始化值为线程个数,当线程完成自身的任务后,调用countDown函数计数器会进行减一操作,直到计数器个数为0,意味着当前的所有任务已经完成,可以进行后续的任务操作。
说明: 需要注意的一点是CountDownLatch的计数是无法被重置的,计数为0结束。
CountDownLatch使用场景
- 多个人等一个信号后继续执行操作。 例如:5个运动员,等一个发令员的枪响。
- 一个人等多个人的信号。 例如:颁奖者等5个运动员全部跑完才开始进行颁奖。
使用实列
//用于聚合所有的统计指标
private static Map map=new HashMap();
//创建计数器,这里需要统计3个指标
private static CountDownLatch countDownLatch=new CountDownLatch(3);
public static void main(String[] args) {
//记录开始时间
long startTime=System.currentTimeMillis();
Thread countOrderThread=new Thread(new Runnable() {
public void run() {
try {
System.out.println("正在统计订单数量");
Thread.sleep(3000);//任务执行需要3秒
map.put("countOrder",2);//保存结果值
countDownLatch.countDown();//标记已经完成一个任务
System.out.println("统计订单数量完毕");
} catch (InterruptedException e) {
e.printStackTrace();
}
}
});
Thread countGoodsThread=new Thread(new Runnable() {
public void run() {
try {
System.out.println("正在商品销量");
Thread.sleep(3000);//任务执行需要3秒
map.put("countGoods",3);//保存结果值
countDownLatch.countDown();//标记已经完成一个任务
System.out.println("统计商品销量完毕");
} catch (InterruptedException e) {
e.printStackTrace();
}
}
});
Thread countmoneyThread=new Thread(new Runnable() {
public void run() {
try {
System.out.println("正在总销售额");
Thread.sleep(3000);//任务执行需要3秒
map.put("countmoney",4);//保存结果值
countDownLatch.countDown();//标记已经完成一个任务
System.out.println("统计销售额完毕");
} catch (InterruptedException e) {
e.printStackTrace();
}
}
});
//启动子线程执行任务
countGoodsThread.start();
countOrderThread.start();
countmoneyThread.start();
try {
//主线程等待所有统计指标执行完毕
countDownLatch.await();
long endTime=System.currentTimeMillis();//记录结束时间
System.out.println("------统计指标全部完成--------");
System.out.println("统计结果为:"+map.toString());
System.out.println("任务总执行时间为"+(endTime-startTime)/1000+"秒");
} catch (InterruptedException e) {
e.printStackTrace();
}
}
CountDownLatch 常用方法说明
CountDownLatch(int count); //构造方法,创建一个值为count 的计数器。
await();//阻塞当前线程,将当前线程加入阻塞队列。
await(long timeout, TimeUnit unit);//在timeout的时间之内阻塞当前线程,时间一过则当前线程可以执行,
countDown();//对计数器进行递减1操作,当计数器递减至0时,当前线程会去唤醒阻塞队列里的所有线程。
CountDownLatch 源码解析
CountDownLatch中最主要的两个函数是 countDown()和await() ,现在就假设存在A、B、C、D 四个线程是进行countdown操作(也就是执行任务),线程E、F 是await操作(等待ABCD四个任务完成后方可通过栅栏)
在使用过程中,计数器格式是线程执行任务的个数,本文中也就是4,在起初设置的时候应该有 new CountDownLatch(4),调用CountDownLatch(int count)构造方法时会实例化一个sync实例: CountDownLatch中的AQS同步状态被用作记录剩余倒数次数
首先看下构造函数源码:
public CountDownLatch(int count) {
if (count < 0) throw new IllegalArgumentException("count < 0");
//实例化sync同步器
this.sync = new Sync(count);
}
Sync(int count) {
//这里AQS的state代表计数器的值
setState(count);
}
private static final class Sync extends AbstractQueuedSynchronizer {
private static final long serialVersionUID = 4982264981922014374L;
Sync(int count) {
setState(count);
}
}
然后看看await方法,现在假设E、F线程是await操作的
public void await() throws InterruptedException {
// 支持中断的共享模式锁
sync.acquireSharedInterruptibly(1);
}
public final void acquireSharedInterruptibly(int arg)
throws InterruptedException {
if (Thread.interrupted())
// 当前的线程如果出现中断了,则抛出一个新的中断异常事件
throw new InterruptedException();
if (tryAcquireShared(arg) < 0)
// 返回true,也就表示还包含了没有完成任务的线程,当前线程需要尝试获取锁
doAcquireSharedInterruptibly(arg);
}
protected int tryAcquireShared(int acquires) {
return (getState() == 0) ? 1 : -1;
// 尝试获取当前状态是否是0
// 如果当前计时器数据为0,则认为可以获取了,返回1,否则返回-1
}
到现在EF两个线程在执行await时,肯定都会进入到doAcquireSharedInterruptibly中
private void doAcquireSharedInterruptibly(int arg)
throws InterruptedException {
// 情况1 创建一个共享模式的节点插入到CHL队列中,会确保线程安全的
final Node node = addWaiter(Node.SHARED);
boolean failed = true;
try {
for (;;) {
final Node p = node.predecessor();
if (p == head) {
// 如果当前节点的前节点是head,头节点
int r = tryAcquireShared(arg);
// 不调用countdown,不可能进入到这里。直接去堵塞线程吧
if (r >= 0) {
// 大于0 则意味着任务线程计数器减小到0了,可以唤醒下一个节点操作了
// 将当前节点设置为头结点并唤醒doReleaseShared()下个节点
setHeadAndPropagate(node, r);
p.next = null; // help GC
failed = false;
return;
}
}
if (shouldParkAfterFailedAcquire(p, node) &&
parkAndCheckInterrupt())
// 把前节点状态设置为-1,然后返回false
// 然后再次运行到这里时,进入到park中,线程挂起
// 注意!被唤醒的线程也是在这里继续执行的,等下还会回过头来到这里的
throw new InterruptedException();
}
} finally {
if (failed)
cancelAcquire(node);
}
}
private void setHeadAndPropagate(Node node, int propagate) {
Node h = head; // Record old head for check below
setHead(node);
if (propagate > 0 || h == null || h.waitStatus < 0 ||
(h = head) == null || h.waitStatus < 0) {
Node s = node.next;
if (s == null || s.isShared())
doReleaseShared();
}
}
private static boolean shouldParkAfterFailedAcquire(Node pred, Node node) {
int ws = pred.waitStatus;
if (ws == Node.SIGNAL)
return true;
if (ws > 0) {
do {
node.prev = pred = pred.prev;
} while (pred.waitStatus > 0);
pred.next = node;
} else {
// 第一个节点ws=0 直接进这里值为SIGNAL 然后下面返回False进到上层方法二次循环返回true,意味需要线程挂起。
compareAndSetWaitStatus(pred, ws, Node.SIGNAL);
}
return false;
}
private final boolean parkAndCheckInterrupt() {
LockSupport.park(this);
return Thread.interrupted();
}
至此,await()方法就分析完了,如果还不理解就通过图解回顾下:
- 在线程E通过addWaiter方法操作后,CHL队列变成
- 在for循环的第一遍把头结点的waitStatus值设置为-1,返回false
- 在for循环的第二部发现头结点状态位-1,返回true,进入到park中线程挂起
- 然后在线程F进来的时候,同理也会进入到该CHL队列中,最后的情况如下图
现在EF就是执行了await函数后进入到CHL队列中被挂起了,一直在等待直到ABCD四个线程完成了各自的任务使得status=0
现在再看看第二个函数countDown函数的操作细节
public void countDown() {
sync.releaseShared(1);
}
public final boolean releaseShared(int arg) {
// 调取countDown函数尝试去将state减为0,判断等于0时返回true,此时则去释放线程
if (tryReleaseShared(arg)) {
// 只有最后一个通过CAS操作后把status变成0的线程会返回true
// 否则都是返回false
doReleaseShared();
return true;
}
return false;
}
protected boolean tryReleaseShared(int releases) {
for (;;) {
int c = getState();
// 这块为啥=0返回false下面等于0确返回true?首次进入不可能为0,刚进入就为0就不用后续操作了
if (c == 0)
return false;
int nextc = c-1;
if (compareAndSetState(c, nextc))
return nextc == 0;
}
}
ABCD四个线程调用countDown 方法时,基本上只会进行CAS减一操作,而只有最后一个完成任务的线程会返回true,然后调用doReleaseShared方法,也就是说只有一个线程会去开启唤醒CHL队列的线程
现在假设D线程执行了最后一个CAS减一操作,然后触发了唤醒操作
private void doReleaseShared() {
for (;;) {
Node h = head;
if (h != null && h != tail) {
// 如果队列存在有效节点数据
int ws = h.waitStatus;
if (ws == Node.SIGNAL) {
// 头结点的状态位-1,可以唤醒头部后置节点
if (!compareAndSetWaitStatus(h, Node.SIGNAL, 0))
continue;
// 此时头部节点状态位0,修改头部节点而且进行唤醒操作
// 这个地方就是开始唤醒头结点的下个节点的操作,也就是样例中的E节点
unparkSuccessor(h);
}
else if (ws == 0 &&
!compareAndSetWaitStatus(h, 0, Node.PROPAGATE))
continue; // loop on failed CAS
}
if (h == head) // loop if head changed
break;
}
}
private void unparkSuccessor(Node node) {
int ws = node.waitStatus;
if (ws < 0)
compareAndSetWaitStatus(node, ws, 0);
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);
}
现在由当前执行中的任务线程D通过unpark操作,唤醒了CHL队列的E节点所在线程,再次来到了doAcquireSharedInterruptibly方法中,E线程继续运行
final Node p = node.predecessor();
if (p == head) {
// E节点的前节点就是head,node节点就是E本身
int r = tryAcquireShared(arg);
if (r >= 0) {
// 现在所有的任务现场都进行了减一操作,r一定大于0的
setHeadAndPropagate(node, r);
// node节点设置为head节点
p.next = null; // help GC
failed = false;
return;
}
}
private void setHead(Node node) {
head = node;
node.thread = null;
node.prev = null;
}
private void setHeadAndPropagate(Node node, int propagate) {
Node h = head; // Record old head for check below
setHead(node);
// 把node节点设置为head节点
if (propagate > 0 || h == null || h.waitStatus < 0 ||
(h = head) == null || h.waitStatus < 0) {
Node s = node.next;
if (s == null || s.isShared())
// 然后又开始了唤醒CHL队列的其他节点线程(此处是F线程节点)
doReleaseShared();
}
}
E线程经过了setHeadAndPropagate方法之后,CHL队列变成了如下图所示,图中并未画出线程E节点,是因为现在E节点正处于运行中,不在CHL队列中
doAcquireSharedInterruptibly 函数中每个步骤看上去并不具备线程安全的特性,那么其是如何保证线程安全的呢?因为每次添加节点都是在tail处添加节点,而唤醒则是都是从head节点开始进行唤醒操作的,能够很好的从业务上避免线程安全的问题
后续又经过了把原头结点进行GC回收操作,其await操作完成,也进行了现在F的唤醒操作
现在CHL队列如下图所示
现在进行唤醒F线程的操作,又来到了doReleaseShared方法,注意是E线程调用的此方法
private void doReleaseShared() {
for (;;) {
Node h = head;
if (h != null && h != tail) {
// 如果队列存在有效节点数据
int ws = h.waitStatus;
if (ws == Node.SIGNAL) {
// 头结点的状态位-1,可以唤醒头部后置节点
// 现在的头结点状态位确实为-1,可以唤醒
if (!compareAndSetWaitStatus(h, Node.SIGNAL, 0))
// CAS设置头结点失败,继续轮询操作
// 此处为问题1,后面会重点解释为什么会出现该类情况
continue;
// 此时头部节点状态位0,修改头部节点而且进行唤醒操作
// 这里就是唤醒F节点的操作入口LockSupport.unpark(s.thread);
unparkSuccessor(h);
}
else if (ws == 0 &&
!compareAndSetWaitStatus(h, 0, Node.PROPAGATE))
// 头结点为0,然后进行CAS设置为-3失败了,继续轮询
// 问题2,为什么会出现CAS失败的情况
continue; // loop on failed CAS
}
if (h == head) // loop if head changed
// 经过上面的操作,E线程唤醒任务完成,本身退出该for循环
break;
}
}
然后又进入到unpark中唤醒F线程的操作,而E线程本身进入到break中,完成任务。
E线程经历了加入到CHL队列中、主动挂起、被前置节点(头节点)唤醒、CAS操作设置自身状态为0、唤醒下一个节点等五个主要步骤后完成await操作,进入到下一步。
总结
相比AQS而言,CountDownLatch还是相对简单的,使用了AQS的共享模式,当任务完成后,由最后一个线程开启唤醒的操作,然后由头结点开始一个接着一个进行唤醒,因为线程的无序性,加上CAS乐观的保证线程安全,CountDownLatch分享至此结束。
参考:
Demo:https://www.cnblogs.com/linjiqin/p/4509882.html
https://www.jianshu.com/p/fb454a523a0f
https://yq.aliyun.com/articles/689069