CountDownLatch原理简介和使用过程

前言

本文介绍下面试的高能考点 countDownLatch 的原理和应用

countDownLatch具有的功能

CountDownLatch主要有两个方法，当一个或多个线程调用await方法时，这些线程会阻塞。
其它线程调用countDown方法会将计数器减1(调用countDown方法的线程不会阻塞)
当计数器的值变为0时，因await方法阻塞的线程会被唤醒，继续执行。

应用场景

典型的应用场景

如并行计算，当某个处理的运算量很大时，可以将该运算任务拆分成多个子任务，等待所有的子任务都完成之后，父任务再拿到所有子任务的运算结果进行汇总。

原理简介

上图解释

TA线程实例化 CountDownLatch对象并初始count为3
TA调用await 使得当前线程等待count为0 类似于看视屏的时候按了暂停键
另外一个T1线程调用了该CountDownLatch对象的countDown方法使得count变为2
T2线程使得count变为1
T3线程使得count变为0
此时就会唤醒处于“暂停”状态的TA线程让其继续往下执行

进一步说明

CountDownLatch是一个计数器闭锁，通过它可以完成类似于阻塞当前线程的功能，即：一个线程或多个线程一直等待，直到其他线程执行的操作完成。
CountDownLatch用一个给定的计数器来初始化，该计数器的操作是原子操作，即同时只能有一个线程去操作该计数器。
调用该类await方法的线程会一直处于阻塞状态，直到其他线程调用countDown方法使当前计数器的值变为零，每次调用countDown计数器的值减1。
当计数器值减至零时，所有因调用await()方法而处于等待状态的线程就会继续往下执行。
这种现象只会出现一次，因为计数器不能被重置，如果业务上需要一个可以重置计数次数的版本，可以考虑使用CycliBarrier

DEMO代码分析

这个示例包含了 线程池和CountDownLatch 的内容 ，更加符合实际使用场景

详细说明上述示例

针对CountDownLatch的说明

初始化一个CountDownLatch 初始值count=5
调用countDownLatch方法 count+-1即 count=count-1 每次调用count值都会减少1个
调用await方法就是让初始化CountDownLatch的线程等待count值变为0 然后才会继续执行下面的内容

结合线程池对CountDownDatch的说明

主线程创建了一个count为5的CountDownLatch
主线程创建了一个线程池里面有5个核心线程
往线程池中提交了5个线程并且传入countDownLatch对象到子线程中去
每一个子线程执行时会调用countDown方法将count减1
主线程调用await 等待count变为0
count变为0 主线程将继续执行

源码分析

java.util.concurrent.CountDownLatch

分析源码的过程中大家把关注点放在我截图上圈红的地方 然后咱们慢慢的一点一点的把源码看完

这里将count值设置给state变量 调用了AQS类中setState方法

这个变量被volatile修饰
保证了这个变量 具有
1、可见性
2、有序性 防止指令重排序
3、原子性

这里先简单介绍下可见性

上图解释

每一个线程都会有一个本地内存比如图中线程A有本地内存A 该内存中保留了一份主内存中共享变量的副本
线程A对本地内存A中的共享变量的副本修改了之后然后会立刻同步刷新到主内存中
并且会让强制缓存了该变量的线程中的数据清空
必须从主内存中重新读取最新的数据

接着说CountDownLatch源码分析

在初始化CountDownLatch的时候会实例化这个继承了AQS的内部类Sync并且将count传给AQS的state变量

countDownLatch的await方法 调用了 AQS的acquireSharedInterruptibly方法并且传入了参数1 接下来对该方法分析

『tryAcquireShared』
在共享模式下尝试获取。这个方法需要查询是否对象的状态允许在共享模式下被获取，如果允许则去获取它。
这个方法总是被线程执行获取共享锁时被调用。如果这个方法报告失败，那么获取方法可能会使线程排队等待，如果它（即，线程）还没入队的话，直到其他的线程发出释放的信号。
默认实现抛出一个“UnsupportedOperationException”
返回：
a）< 0 : 一个负数的返回表示失败；
b) 0 : 0表示在共享模式下获取锁成功，但是后续的获取共享锁将不会成功
c）> 0 : 大于0表示共享模式下获取锁成功，并且后续的获取共享锁可能也会成功，在这种情况下后续等待的线程必须检查是否有效。


看下AQS的子类Sync的tryAcquireShared方法的实现

这个逻辑过程中使用了大量的CAS来进行原子性的修改，当修改失败的时候，是会通过for(;;)来重新循环的，也就是说『doAcquireSharedInterruptibly』使用自旋锁（自旋+CAS）来保证在多线程并发的情况下，队列节点状态也是正确的以及在等待队列的正确性，最终使得当前节点要么获取共享锁成功，要么被挂起等待唤醒

我们需要一个通知信号，主要是因为当前线程要被挂起了（park）。
而如果waitStatus已经是’SIGNAL’的话就无需修改，直接挂起就好，
而如果waitStatus是’CANCELLED’的话，说明prev已经被取消了，是个无效节点了，那么无需修改这个无效节点的waitStatus，而是需要先找到一个有效的prev。
因此，剩下的情况就只有当waitStatus为’0’和’PROPAGAET’了（注意，waitStatus为’CONDITION’是节点不在等待队列中，所以当下情况waitStatus不可能为’CONDITION’），这时我们需要将prev的waitStatus使用CAS的方式修改为’SIGNAL’，而且只有修改成功的情况下，当前的线程才能安全被挂起。
还值得注意的时，因此该方法的CAS操作都是没有自旋的，所以当它操作完CAS后都会返回false，在外层的方法中会使用自旋，当发现返回的是false时，会再次调用该方法，以检查保证有当前node有一个有效的prev，并且其waitStatus为’SIGNAL’，在此情况下当前的线程才会被挂起（park）。

双向链表数据结构

源码分析未完待续 下篇文章继续分析

DEMO代码链接

https://gitee.com/pingfanrenbiji/myconcurrent/tree/master/src/main/java/pers/hanchao/concurrent/eg14

参考文章

https://www.jianshu.com/p/9ee0194d598c