前言
看完 CountDownLatch 正筹备示意一番,忽然看到了一个 CyclicBarrier —— 回环屏障。沃特?回环还屏障?说比 CountDownLatch 要多一个回环,那咱可得瞧一瞧,看一看了!
公众号:『刘志航』,记录工作学习中的技术、开发及源码笔记;时不时分享一些生存中的见闻感悟。欢送大佬来领导!
介绍
一个同步辅助,它容许一组线程的所有期待彼此达成独特屏障点。
CyclicBarrier 在波及固定线程数且必须期待彼此的程序十分有用。
该屏障被称为回环屏障,因为它在期待的线程被开释后能够被从新利用。
CyclicBarrier 反对一个可选的 Runnable 命令,该命令在阻碍中的最初一个线程达到之后,但在开释任何线程之前,每个屏障点运行一次。
此屏障操作对于在任何一方持续之前更新共享状态很有用。
通过下面的源码正文根本能够得出以下论断:
- CyclicBarrier 和 CountDownLatch 相似,但它是一组线程期待,直到在其余线程中执行的一组操作实现为止。
- CountDownLatch 是计数递加,完结后再调用 await 或者 countdown 都会立刻返回,然而 CyclicBarrier 能够重置屏障。
- CyclicBarrier 还能够传入参数 Runnable,Runnable 会在开释线程之前执行。
根本应用
既然下面总结了三个论断,上面当然从三个方面演示如何应用的:
– 屏障性能
public class CyclicBarrierTest {private static final CyclicBarrier CYCLIC_BARRIER = new CyclicBarrier(11);
public static void main(String[] args) throws BrokenBarrierException, InterruptedException {
ExecutorService pool = new ThreadPoolExecutor(10, 10, 0L, TimeUnit.MILLISECONDS,
new LinkedBlockingQueue<>(1024),
new ThreadFactoryBuilder().setNameFormat("Thread-pool-%d").build(),
new ThreadPoolExecutor.AbortPolicy());
for (int i = 0; i < 10; i++) {pool.submit(() -> {
try {System.out.println(Thread.currentThread().getName() + "开始执行");
Thread.sleep(5000);
System.out.println(Thread.currentThread().getName() + "执行完结,筹备调用 await");
CYCLIC_BARRIER.await();} catch (InterruptedException | BrokenBarrierException e) {e.printStackTrace();
}
});
}
System.out.println("主线程执行 —————————————— >>>");
CYCLIC_BARRIER.await();
System.out.println("主线程继续执行 —————————————— >>>");
pool.shutdown();}
}
通过下面代码其实模仿了个相似 CountDownLatch 的性能,让所有线程期待,直到都调用 await 之后,各个线程继续执行,同时主线程也持续往下执行。
不过绝对 CountDownLatch 的指定一个线程或多个期待,直到其余线程执行完结,期待的线程才继续执行来说,CyclicBarrier 相对来说还是逊色。
差异总结如下:
- CountDownLatch 是指定期待的线程,其余线程进行 countDown,等计数为 0 时,期待的线程继续执行。
- CyclicBarrier 是一组线程调用 await 进行期待,当所有的都进入期待的时候,这一组就会一起冲破屏障继续执行。
– 回环性能
public class CyclicBarrierTest2 {private static final CyclicBarrier CYCLIC_BARRIER = new CyclicBarrier(5);
public static void main(String[] args) throws BrokenBarrierException, InterruptedException {
ExecutorService pool = new ThreadPoolExecutor(5, 5, 0L, TimeUnit.MILLISECONDS,
new LinkedBlockingQueue<>(1024),
new ThreadFactoryBuilder().setNameFormat("Thread-pool-%d").build(),
new ThreadPoolExecutor.AbortPolicy());
for (int i = 0; i < 5; i++) {pool.submit(() -> {
try {System.out.println(Thread.currentThread().getName() + "开始执行");
CYCLIC_BARRIER.await();
System.out.println(Thread.currentThread().getName() + "冲破屏障 >>> 1");
CYCLIC_BARRIER.await();
System.out.println(Thread.currentThread().getName() + "冲破屏障 >>>>> 2");
CYCLIC_BARRIER.await();} catch (InterruptedException | BrokenBarrierException e) {e.printStackTrace();
}
});
}
pool.shutdown();}
}
下面演示的回环的用法。
– 回环 Runnable
这块只须要在申明的 CyclicBarrier 批改为以下即可:
private static final CyclicBarrier CYCLIC_BARRIER = new CyclicBarrier(5, new Runnable() {
@Override
public void run() {System.out.println("执行一次 Runnable");
}
});
打印后果如下:
能够看出只是在下一个计数开始之前,先执行 Runnable。至于是不是在开释屏障之前,那很容易,间接 Debug 走一遭就晓得了!专门录制了个视频:
通过 debug 能够看出Runnable 会在开释线程之前执行。
问题疑难?
- CyclicBarrier 和 AQS 有什么关系?
- CyclicBarrier 的实现原理是什么?
- CyclicBarrier 是如何实现回环的?
上面就带着疑难去源码浏览,一探到底!
源码剖析
根本构造
通过 UML 乍一看,CyclicBarrier 和 AQS 并无什么关系,那上面开始从 参数 、 结构器 、await() 办法 别离看源码。
参数
public class CyclicBarrier {
/**
* 屏障的每次应用都示意为一个生成实例。* broken 示意屏障是否被突破。*/
private static class Generation {boolean broken = false;}
/** 锁 */
private final ReentrantLock lock = new ReentrantLock();
/** 条件期待,直到屏障 */
private final Condition trip = lock.newCondition();
/** 期待计数 */
private final int parties;
/* The command to run when tripped */
private final Runnable barrierCommand;
/** 以后 generation 新创建的 */
private Generation generation = new Generation();
/** 仍在期待的 parties 数量,递加 为 0 会重置 */
private int count;
}
通过下面能够看出:
外部应用了一个动态类 Generation,它有什么性能呢?通过正文理解到,每次应用屏障的时候都会生成,具体有什么用,其实就是用来标示屏障是否被突破。
外部还有一个 parties 示意期待计数,count 示意仍在期待的计数。
那就持续往下看吧!
结构器
public CyclicBarrier(int parties, Runnable barrierAction) {if (parties <= 0) throw new IllegalArgumentException();
this.parties = parties;
this.count = parties;
this.barrierCommand = barrierAction;
}
这里的入参有两个:
- parties(期待计数):记录多少个线程调用 await 之后,才会一起突破屏障。
- barrierAction:冲破屏障前执行的行为。
- 然而会同时对 parties 和 count 赋值为传入的 parties。
单参数结构,其实就是将 barrierAction 赋值为 null。
await() 办法
在示例中用的 await() 办法,那就从 await() 办法动手:
public int await() throws InterruptedException, BrokenBarrierException {
try {return dowait(false, 0L);
} catch (TimeoutException toe) {throw new Error(toe); // cannot happen
}
}
await() 才是重头戏,先来依据源码正文,理解是干嘛的,看看作者怎么讲:
- 等到所有各方都在此阻碍上调用 await。
-
如果以后线程不是最初达到的线程,则出于线程调度目标将其禁用,并使其处于休眠状态,直到产生以下状况之一:
- 最初一个线程达到;
- 其余一些线程中断以后线程;
- 其余一些线程中断其余正在期待的线程之一;
- 期待屏障的时候其余线程超时;
- 其余一些线程在此屏障上调用 reset。
看到这些,咱们最想看的当然是 2.1,期待最初一个线程达到屏障,之后所有的线程一起继续执行。
private int dowait(boolean timed, long nanos)
throws InterruptedException, BrokenBarrierException,
TimeoutException {
// 加锁
final ReentrantLock lock = this.lock;
lock.lock();
try {
// 在这里用到了这个代
final Generation g = generation;
if (g.broken)
throw new BrokenBarrierException();
// 线程终中断标示
if (Thread.interrupted()) {breakBarrier();
throw new InterruptedException();}
// 对计数进行递加
int index = --count;
// 如果是 0 则
if (index == 0) { // tripped
boolean ranAction = false;
try {
final Runnable command = barrierCommand;
// 不是 null 先执行行为
if (command != null)
// 这里不是新开线程
command.run();
ranAction = true;
// 下一代
nextGeneration();
return 0;
} finally {
// 工作未胜利时,即 ranAction 还是 false 突破屏障
if (!ranAction)
breakBarrier();}
}
// loop until tripped, broken, interrupted, or timed out
// 自旋
for (;;) {
try {
// 没有设置超时工夫
if (!timed)
// 进入期待
trip.await();
else if (nanos > 0L)
nanos = trip.awaitNanos(nanos);
} catch (InterruptedException ie) {if (g == generation && ! g.broken) {breakBarrier();
throw ie;
} else {Thread.currentThread().interrupt();}
}
if (g.broken)
throw new BrokenBarrierException();
// 曾经下一代了
if (g != generation)
return index;
if (timed && nanos <= 0L) {breakBarrier();
throw new TimeoutException();}
}
} finally {lock.unlock();
}
}
这一大坨代码,齐全没有看的欲望,间接划过去吧!
所以…… 间接看到了这里吧。
代码还是要浏览的,离开来看(异样流程省略):
- 应用了 ReentrantLock 互斥锁,因而对 count、broken 的批改是原子性的。
- 对 count 进行 –count 操作,这样就了解为什么说 count 是仍在期待的计数,或者说还有多少能力达到屏障点。
-
当 count 为 0,示意达到屏障点了
- command 不为 null,会先执行 command.run(),值得注意的是这里并不是新开了个线程。
- nextGeneration()开始新的下一代,即重置 count 为 parties。
- 在 finally 外面应用 breakBarrier() 突破屏障。
-
当 count 不是 0
- 自旋,直到是 0.
这前面还有两个办法不能少:
private void nextGeneration() {
// 唤醒线程
trip.signalAll();
// 更新 count 为 parties
count = parties;
// 更新 Generation
generation = new Generation();}
// 突破屏障,并唤醒全副
private void breakBarrier() {
generation.broken = true;
count = parties;
trip.signalAll();}
reset()
public void reset() {
final ReentrantLock lock = this.lock;
lock.lock();
try {breakBarrier(); // break the current generation
nextGeneration(); // start a new generation} finally {lock.unlock();
}
}
将屏障重置为其初始状态,reset() 办法其实还是调用的 breakBarrier() 和 nextGeneration(),前者时突破以后代,后者是开始新的一轮。
总结
Q: CyclicBarrier 和 AQS 有什么关系?
A: 通过浏览源码,其实发现是应用了 ReentrantLock 互斥锁 以及 Condition 的期待唤醒性能。
Q: CyclicBarrier 的实现原理是什么?
A: 外部含有两个计数,别离是 parties 和 count,初始是二者相等,当有线程调用 await() 时,count 递加,只有 count 不为 0,就会阻塞线程,直到 count 递加为 0 时,此时会所有线程一起开释,同时将 count 重置为 parties。
Q: CyclicBarrier 是如何实现回环的?
A: 应用两个计数,count 递加,当 count 为 0 时,会重置为 parties,从而达到回环成果。
Q: 为什么 count 的 –count 操作没有应用 CAS?
A: 因为曾经 lock.lock() 了,应用了 ReentrantLock 锁可能保障 count 的原子性。
CyclicBarrier 和 CountDownLatch 的区别
- 回环:CyclicBarrier 能够回环,从新计数。CountDownLatch 只能一轮。
- 计数器:CyclicBarrier 的计数器本人保护递加,CountDownLatch 的计数器保护则是交给使用者。
- 阻塞线程:CyclicBarrier 阻塞的是本身,当达到屏障后,所有被阻塞的线程一起开释。CountDownLatch 能够指定阻塞线程。
结束语
本文次要介绍了 CyclicBarrier 的罕用形式,通过源码形式,剖析如何达到屏障以及回环的成果。不对之处,请多斧正。