其他系列文章导航
Java基础合集
设计模式合集
多线程合集
分布式合集
ES合集
文章目录
- 其他系列文章目录
- 文章目录
- 前言
前言
我现在有个场景:现在我有50个任务，这50个任务在完成之后，才能执行下一个函数，要是你，你怎么设计?
可以用JDK给我们提供的线程工具类，CountDownLatch和CyclicBarrier都可以完成这个需求。
一、CountDownLatch和CyclicBarrier
CountDownLatch允许一个或多个线程直等待，直到这些线程完成它们的操作。
而CyclicBarrier不一样，它往往是当线程到达某状态后，暂停下来等待其他线程等到所有线程均到达以后，才继续执行。
可以发现这两者的等待主体是不一样的。
CountDownLatch调用await（）通常是主线程/调用线程，而CyclicBarrier调用await（）是在任务线程调用的。
所以，CyclicBarrier中的阻塞的是任务的线程，而主线程是不受影响的。
二、CountDownLatch源码分析
CountDownLatch也是基于AQS实现的，它的实现机制很简单。
Java 中 AQS（AbstractQueuedSynchronizer）的 state 一般有以下值：
0：表示当前没有任何线程占有锁或者资源。
1：表示当前有一个线程占有锁或者资源。
大于等于 2：表示当前有多个线程占有锁或者资源，即存在竞争状态。
负数：表示当前有等待获取锁或者资源的线程，这些线程处于阻塞状态。
特殊值：AQS 实现类可以根据自己的需求自定义特殊的 state 值，例如 ReentrantLock 就使用了一个表示重入次数的 state 值。
当我们在构建CountDownLatch对象时，传入的值其实就会赋值给AQS的关键变量state。
执行countDown方法时，其实就是利用CAS将state -1。
执行await方法时，其实就是判断state是否为0，不为0则加入到队列中，将该线程66阻塞掉(除了头结点)。
因为头节点会一直自旋等待state为0，当state为0时，头节点把剩余的在队列中阻塞的节点也一并唤醒。
三、CyclicBarrier源码分析
回到CyclicBarrier代码也不难，重点也就是await方法。
从源码不难发现的是，它没有像CountDownLatch和ReentrantLock使用AQS的state变量，而CyclicBarrier是直接借助ReentrantLock加上Condition 等待唤醒的功能进而实现的。
在构建CyclicBarrier时，传入的值会赋值给CyclicBarrier内部维护count变量，也会赋值给parties变量(这是可以复用的关键)。
每次调用await时，会将count -1，操作count值是直接使用ReentrantLock来保证线程安全性。
如果count不为0，则添加则condition队列中。
如果count等于0时，则把节点从condition队列添加至AQS的队列中进行全部唤醒并且将parties的值重新赋值为count的值(实现复用)。
四、总结
CountDownlatch基于AQS实现，会将构造CountDownLatch的入参传递至statecountDown()就是在利用CAS将state减1，await)实际就是让头节点一直在等待state为0时，释放所有等待的线程。
CyclicBarrier则利用ReentrantLock和Condition，自身维护了count和parties变量。每次调用await将count-1，并将线程加入到condition队列上。等到count为0时，则将condition队列的节点移交至AQS队列，并全部释放。
