聊聊高并发（三十）解析java.util.concurrent各个组件（十二）理解CyclicBarrier栅栏

这篇讲讲CyclicBarrier栅栏，从它的名字可以看出，它是可循环使用的。它的功能和CountDownLatch类似，也是让一组线程等待，然后一起开始往下执行。但是两者还是有几个区别

1. 等待的对象不同。CountDownLatch的一组线程等待的是一个事件，或者说是一个计数器归0的事件。而CyclicBarrier等待的对象是线程，只有线程都到齐了才往下执行

2. 使用方式不同，这个也是由等待的对象不同引起的，CountDownLatch需要调用await()来让线程等待，调用countDown()来修改状态，直到触发状态为0的事件。而CyclicBarrier只需要调用await()让线程等待，当调用await()方法的线程数满足条件，就自动唤醒所有线程往下执行

3. CyclicBarrier可以自动循环使用，当一次拦截被打开后，会自动创建下一个拦截。CountDownLatch的计数器归0后不能再次使用

4. 底层实现不同，CountDownLatch使用AQS来实现底层同步，CyclicBarrier基于更上层的ReetrantLock + Condition条件队列实现

5. 失效机制不同，在CountDownLatch等待的线程如果被中断或者超时取消，不会影响其他线程。而CyclicBarrier采用all-or-none的机制，要么全部不通过，要么全部都通过，也就是说一旦在CyclicBarrier等待的线程有一个被中断或者超时取消，那么其他所有在这个CyclicBarrier等待的线程都被唤醒，通过栅栏往下执行

6. CyclicBarrier支持线程全部通过之后的回调功能，通过传入一个Runnable对象，由最后一个到达的线程来执行。而CountDownLatch不支持回调机制

下面看看CyclicBarrier的源代码，它有一个内部类Generation来处理循环使用的问题，维护了一个broker状态表示当前的栅栏是否失效。如果失效，可以重置栅栏的状态。当栅栏被打破时，就设置当前generation的broker为true表示失效，并唤醒所有等待的线程，即all-or-none机制

private static class Generation {
boolean broken = false;
}
private void nextGeneration() {
// signal completion of last generation
trip.signalAll();
// set up next generation
count = parties;
generation = new Generation();
}
private void breakBarrier() {
generation.broken = true;
count = parties;
trip.signalAll();
}

维护了一个ReentrantLock来作同步，并创建了一个相关的条件队列Condition，使用Condition的await()方法让线程在同一个条件队列等待，使用Condition.signalAll()唤醒所有在通过一条件队列等待的线程。

/** The lock for guarding barrier entry */
private final ReentrantLock lock = new ReentrantLock();
/** Condition to wait on until tripped */
private final Condition trip = lock.newCondition();

维护了一个Runnable引用来支持回调功能

/* The command to run when tripped */
private final Runnable barrierCommand;
public CyclicBarrier(int parties, Runnable barrierAction) {
if (parties <= 0) throw new IllegalArgumentException();
this.parties = parties;
this.count = parties;
this.barrierCommand = barrierAction;
}

维护了一个count来计数，当await()方法被调用一次, count就减1，直到count为0打开栅栏。

private int count;

可以看到CyclicBarrier的实例属性都没有使用volatile变量，那它怎么保证状态的可见性呢？CyclicBarrier使用了加显式锁的方式。我们知道显式锁和内置锁一样，都保证了可见性，有序性和原子性。

1. 进入锁相当于读volatile，会清空CPU缓存，强制从内存读取

2. 离开锁相当于写volatile，会把CPU写缓冲区的数据强制刷新到内存

CyclicBarrier常用支持普通的等待和限时的等待。最后都是落到了dowait()方法。

public int await() throws InterruptedException, BrokenBarrierException {
try {
return dowait(false, 0L);
} catch (TimeoutException toe) {
throw new Error(toe); // cannot happen;
}
}
public int await(long timeout, TimeUnit unit)
throws InterruptedException,
BrokenBarrierException,
TimeoutException {
return dowait(true, unit.toNanos(timeout));
}

来看看dowait方法

1. 必须先获取锁，保证了可见性，有序性，原子性

2. 判断当前栅栏的状态，如果已经失效，抛出BrokerBarrierException异常

3. 如果线程被中断，那么让栅栏失效，会唤醒所有等待线程往下执行

4. 执行一次dowait就对count减一，用index记录下当前线程执行是的count值作为索引

5. 如果index == 0表示是最后到达的线程，可以打开栅栏了。首先如果有回调，就执行回调。然后重置栅栏状态，使之可以循环使用，返回0

6. 如果index不为0，表示不是最后到达的线程，就轮询等待，这里支持了限时操作，使用了Condition条件队列的await()机制。直到超时或者栅栏被正常失效。栅栏失效后会使用Condition来唤醒所有在同一个条件队列等待的线程。

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;
if (index == 0) { // tripped
boolean ranAction = false;
try {
final Runnable command = barrierCommand;
if (command != null)
command.run();
ranAction = true;
nextGeneration();
return 0;
} finally {
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 {
// We're about to finish waiting even if we had not
// been interrupted, so this interrupt is deemed to
// "belong" to subsequent execution.
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();
}
}

下面使用一个测试用例来测试CyclicBarrier的功能

1. 创建一个5个容量的CyclicBarrier，并设置回调

2. 运行12个线程

package com.lock.test;
import java.util.concurrent.CyclicBarrier;
public class CyclicBarrierUsecase {
private CyclicBarrier barrier = new CyclicBarrier(5, new Runnable(){
@Override
public void run() {
System.out.println("Callback is running");
}
});
public void race() throws Exception{
System.out.println("Thread " + Thread.currentThread().getName() + " is waiting the resource");
barrier.await();
System.out.println("Thread " + Thread.currentThread().getName() + " got the resource");
}
public static void main(String[] args){
final CyclicBarrierUsecase usecase = new CyclicBarrierUsecase();
for(int i = 0; i < 12; i++){
Thread t = new Thread(new Runnable(){
@Override
public void run() {
try {
usecase.race();
} catch (Exception e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
}
}, String.valueOf(i));
t.start();
}
}
}

测试结果：

1. 可以看到5个线程在等待，直到满5个线程到达之后打开栅栏，这5个线程往下执行，并执行回调

2. 栅栏被循环使用了，又有5个线程等待，直到满5个线程到达又打开栅栏往下执行，并执行回调

3. 栅栏又被循环使用，但是只有2个线程，不满5个，就一直等待

Thread 0 is waiting the resource
Thread 4 is waiting the resource
Thread 5 is waiting the resource
Thread 3 is waiting the resource
Thread 2 is waiting the resource
Callback is running
Thread 1 is waiting the resource
Thread 0 got the resource
Thread 2 got the resource
Thread 6 is waiting the resource
Thread 7 is waiting the resource
Thread 4 got the resource
Thread 9 is waiting the resource
Thread 8 is waiting the resource
Thread 3 got the resource
Thread 5 got the resource
Callback is running
Thread 8 got the resource
Thread 1 got the resource
Thread 7 got the resource
Thread 6 got the resource
Thread 10 is waiting the resource
Thread 11 is waiting the resource
Thread 9 got the resource

聊聊高并发（三十）解析java.util.concurrent各个组件（十二）理解CyclicBarrier栅栏相关推荐

聊聊高并发（二十）解析java.util.concurrent各个组件（二） 12个原子变量相关类
这篇说说java.util.concurrent.atomic包里的类,总共12个,网上有很多文章解析这几个类,这里挑些重点说说. 这12个类可以分为三组: 1. 普通类型的原子变量 2. 数组类型的 ...
聊聊高并发（二十一）解析java.util.concurrent各个组件（三）深入理解AQS（一）
AQS是AbstractQueuedSynchronizer的缩写,AQS是Java并包里大部分同步器的基础构件,利用AQS可以很方便的创建锁和同步器.它封装了一个状态,提供了一系列的获取和释放操作, ...
聊聊高并发（二十九）解析java.util.concurrent各个组件（十一）再看看ReentrantReadWriteLock可重入读-写锁
上一篇聊聊高并发(二十八)解析java.util.concurrent各个组件(十) 理解ReentrantReadWriteLock可重入读-写锁讲了可重入读写锁的基本情况和主要的方法,显示了如何 ...
聊聊高并发（二十五）解析java.util.concurrent各个组件（七）理解Semaphore
前几篇分析了一下AQS的原理和实现,这篇拿Semaphore信号量做例子看看AQS实际是如何使用的. Semaphore表示了一种可以同时有多个线程进入临界区的同步器,它维护了一个状态表示可用的票据, ...
聊聊高并发（二十二）解析java.util.concurrent各个组件（四）深入理解AQS（二）
上一篇介绍了AQS的基本设计思路以及两个内部类Node和ConditionObject的实现聊聊高并发(二十一)解析java.util.concurrent各个组件(三) 深入理解AQS(一) 这篇 ...
聊聊高并发（二十九）解析java.util.concurrent各个组件（十一）再看看ReentrantReadWriteLock可重入读-写锁...
上一篇聊聊高并发(二十八)解析java.util.concurrent各个组件(十) 理解ReentrantReadWriteLock可重入读-写锁讲了可重入读写锁的基本情况和基本的方法,显示了怎样 ...
聊聊高并发（二十八）解析java.util.concurrent各个组件（十）理解ReentrantReadWriteLock可重入读-写锁
这篇讲讲ReentrantReadWriteLock可重入读写锁,它不仅是读写锁的实现,并且支持可重入性. 聊聊高并发(十五)实现一个简单的读-写锁(共享-排他锁) 这篇讲了如何模拟一个读写锁. 可重 ...
聊聊高并发（三十一）解析java.util.concurrent各个组件（十三）理解Exchanger交换器
这篇讲讲Exchanger交互器,它是一种比较特殊的两方(Two-Party)栅栏,可以理解成Exchanger是一个栅栏,两边一方是生产者,一方是消费者, 1. 生产者和消费者各自维护了一个容器,生 ...
聊聊高并发（二十六）解析java.util.concurrent各个组件（八）理解CountDownLatch闭锁
CountDownLatch闭锁也是基于AQS实现的一种同步器,它表示了"所有线程都等待,直到锁打开才继续执行"的含义.它和Semaphore的语意不同, Semaphore的获取 ...

聊聊高并发（三十）解析java.util.concurrent各个组件（十二）理解CyclicBarrier栅栏

聊聊高并发（三十）解析java.util.concurrent各个组件（十二）理解CyclicBarrier栅栏相关推荐

最新文章

热门文章

聊聊高并发（三十）解析java.util.concurrent各个组件（十二） 理解CyclicBarrier栅栏

聊聊高并发（三十）解析java.util.concurrent各个组件（十二） 理解CyclicBarrier栅栏相关推荐

最新文章

热门文章

聊聊高并发（三十）解析java.util.concurrent各个组件（十二）理解CyclicBarrier栅栏

聊聊高并发（三十）解析java.util.concurrent各个组件（十二）理解CyclicBarrier栅栏相关推荐