并发工具：CyclicBarrier（循环屏障）

1 CyclicBarrier介绍

CyclicBarrier（循环屏障），它也是一个同步助手工具，它允许多个线程在执行完相应的操作之后彼此等待共同到达一个障点（barrier point）

CyclicBarrier也非常适合用于某个串行化任务被分拆成若干个并行执行的子任务，当所有的子任务都执行结束之后再继续接下来的工作。从这一点来看，Cyclic Barrier与CountDownLatch非常类似，但是它们之间的运行方式以及原理还是存在着比较大的差异的，并且CyclicBarrier所能支持的功能CountDownLatch是不具备的：

• CyclicBarrier可以被重复使用，而CountDownLatch当计数器为0的时候就无法再次利用

]

2 入门：等待所有子任务结束

注意和CountDownLatch的使用区别：并发工具：CountDownLatch

import java.util.ArrayList;
import java.util.List;
import java.util.concurrent.BrokenBarrierException;
import java.util.concurrent.CountDownLatch;
import java.util.concurrent.CyclicBarrier;
import java.util.concurrent.TimeUnit;

/**
 * @author wyaoyao
 * @date 2021/4/20 11:09
 */
public class CyclicBarrierDemo1 {

    public static void main(String[] args) {
        // 定义了一个CyclicBarrier，虽然要求传入大于0的int数字，但是它所代表的含义是“分片”而不再是计数器，虽然它的作用与计数器几乎类似。
        CyclicBarrier cyclicBarrier = new CyclicBarrier(3);
        // 构建三个线程
        List<Thread> threads = new ArrayList<>();
        for (int i = 1; i <= 3; i++){
            int finalI = i;
            Thread thread = new Thread(() -> {
                try {
                    // 模拟线程执行
                    TimeUnit.SECONDS.sleep(finalI);
                    System.out.println(Thread.currentThread().getName() + " 执行结束");
                } catch (InterruptedException e) {
                    e.printStackTrace();
                } finally {
                    // 在此等待其他子线程到达barrier point
                    try {
                        cyclicBarrier.await();
                        // 还会抛出BrokenBarrierException异常
                    } catch (BrokenBarrierException | InterruptedException e) {
                        e.printStackTrace();
                    }
                }
            }, "T-" + i);
            threads.add(thread);
            thread.start();
        }
        // 等待所有子任务线程结束
        threads.forEach(t-> {
            try {
                t.join();
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
        });
        System.out.println("三个子线程全部执行结束，主线程可以继续执行了");
    }
}

输出：

T-1 执行结束
T-2 执行结束
T-3 执行结束
三个子线程全部执行结束，主线程可以继续执行了

• 调用await方法等待其他子线程也运行结束到达一个共同的barrier point，该await方法还会返回一个int的值，该值所代表的意思是当前任务到达的次序
• 逐一调用每一个子线程的join方法，使当前线程进入阻塞状态等待所有的子线程运行结束。

和CountDownLatch执行方式的差异：

• CyclicBarrier，在子任务线程中，当执行结束后调用await方法使当前的子线程进入阻塞状态，直到其他所有的子线程都结束了任务的运行之后，它们才能退出阻塞
• CountDownLatch，是主线程等待CountDownLatch计数器降为0，退出阻塞

可以通过一个小技巧使代码变得更加简洁：

public static void main(String[] args) {
    // 定义4个分片，让主线程也成为一个子任务
    CyclicBarrier cyclicBarrier = new CyclicBarrier(4);
    // 构建三个线程
    for (int i = 1; i <= 3; i++){
        int finalI = i;
        Thread thread = new Thread(() -> {
            try {
                // 模拟线程执行
                TimeUnit.SECONDS.sleep(finalI);
                System.out.println(Thread.currentThread().getName() + " 执行结束");
            } catch (InterruptedException e) {
                e.printStackTrace();
            }finally {
                try {
                    cyclicBarrier.await();
                } catch (InterruptedException | BrokenBarrierException e) {
                    e.printStackTrace();
                }
            }
        }, "T-" + i);
        thread.start();
    }
    try {
    	// 在主线程中调用await方法，等待其他子任务线程也到达barrier point
        cyclicBarrier.await();
    } catch (InterruptedException | BrokenBarrierException e) {
        e.printStackTrace();
    }
    System.out.println("三个子线程全部执行结束，主线程可以继续执行了");
}

3 CyclicBarrier的循环特性和源码解读

CyclicBarrier的另一个很好的特性是可以被循环使用，也就是说当其内部的计数器为0之后还可以在接下来的使用中重置而无须重新定义一个新的

简单演示，刚刚的逻辑执行两遍，使用同一个CyclicBarrier

public static void main(String[] args) {
    // 定义4个分片，让主线程也成为一个子任务
    CyclicBarrier cyclicBarrier = new CyclicBarrier(4);
    // 构建三个线程
    for (int i = 1; i <= 3; i++){
        int finalI = i;
        Thread thread = new Thread(() -> {
            try {
                // 模拟线程执行
                TimeUnit.SECONDS.sleep(finalI);
                System.out.println(Thread.currentThread().getName() + " 执行结束");
            } catch (InterruptedException e) {
                e.printStackTrace();
            }finally {
                try {
                    cyclicBarrier.await();
                } catch (InterruptedException | BrokenBarrierException e) {
                    e.printStackTrace();
                }
            }
        }, "T-" + i);
        thread.start();
    }
    try {
        cyclicBarrier.await();
    } catch (InterruptedException | BrokenBarrierException e) {
        e.printStackTrace();
    }
    System.out.println("三个子线程全部执行结束，主线程可以继续执行了");

    // 重新构建三个线程
    for (int i = 1; i <= 3; i++){
        int finalI = i;
        Thread thread = new Thread(() -> {
            try {
                // 模拟线程执行
                TimeUnit.SECONDS.sleep(finalI);
                System.out.println(Thread.currentThread().getName() + " 执行结束");
            } catch (InterruptedException e) {
                e.printStackTrace();
            }finally {
                try {
                	// 使用同一个CyclicBarrier
                    cyclicBarrier.await();
                } catch (InterruptedException | BrokenBarrierException e) {
                    e.printStackTrace();
                }
            }
        }, "T-C-" + i);
        thread.start();
    }
    try {
        cyclicBarrier.await();
    } catch (InterruptedException | BrokenBarrierException e) {
        e.printStackTrace();
    }
    System.out.println("三个子线程全部执行结束，主线程可以继续执行了");
}

输出：

T-1 执行结束
T-2 执行结束
T-3 执行结束
三个子线程全部执行结束，主线程可以继续执行了
T-C-1 执行结束
T-C-2 执行结束
T-C-3 执行结束
三个子线程全部执行结束，主线程可以继续执行了

使用同一个CyclicBarrier来进行控制的，在这里需要注意的是，在主线程中的两次await中间为何没有对barrier进行reset的操作，那是因为在CyclicBarrier内部维护了一个count。当所有的await调用导致其值为0的时候，reset相关的操作会被默认执行:
看一下源码：

public int await()
    throws InterruptedException, BrokenBarrierException{
    try {
            return dowait(false, 0L);
        } catch (TimeoutException toe) {
            throw new Error(toe); // cannot happen
        }
}

private int dowait(boolean timed, long nanos)
   throws InterruptedException, BrokenBarrierException,
          TimeoutException {
...省略
       int index = --count;
       / 当count为0的时候
       if (index == 0) {  // tripped
           boolean ranAction = false;
           try {
               final Runnable command = barrierCommand;
               if (command != null)
                   command.run();
               ranAction = true;
               // 生成新的Generation，并且直接返回
               nextGeneration();
               return 0;
           } finally {
               if (!ranAction)
                   breakBarrier();
           }
       }
...省略
   }
}
private void nextGeneration() {
    // 唤醒阻塞中的所有线程
    trip.signalAll();
    // set up next generation
    // 修改count的值使其等于构造CyclicBarrier转入的parties值
    count = parties;
    // 创建新的Generation
    generation = new Generation();
}

当count的值为0的时候，最后会重新生成新的Generation，并且将count的值设定为构造CyclicBarrier转入的parties值。

接下里看一下CyclicBarrier reset的源码片段。

public void reset() {
    final ReentrantLock lock = this.lock;
    lock.lock();
    try {
        // 调用break barrier方法
        breakBarrier();   // break the current generation
        // 重新生成新的generation
        nextGeneration(); // start a new generation
    } finally {
        lock.unlock();
    }
}

private void breakBarrier() {
    // generation的broken设置为true，标识该barrier已经被broken了
    generation.broken = true;
    // 重置count的值
    count = parties;
    // 唤醒阻塞的其他线程
    trip.signalAll();
}

虽然在reset方法中调用了breakBarrier方法和唤醒其他新阻塞线程，但是它们都会被忽略掉，根本不会影响到dowait方法中的线程（因为执行该方法的线程已经没有了），紧接着generation又会被重新创建，因此在主线程的两次await方法调用之间完全可以不用调用reset方法

4 CyclicBarrier的其他方法

/**
构造CyclicBarrier并且传入parties。
**/
CyclicBarrier(int parties)
/**
构造CyclicBarrier不仅传入parties，而且指定一个Runnable接口，
当所有的线程到达barrier point的时候，该Runnable接口会被调用，
有时我们需要在所有任务执行结束之后执行某个动作，这时就可以使用这种CyclicBarrier的构造方式了。
**/
CyclicBarrier(int parties, Runnable barrierAction);

/**
获取CyclicBarrier在构造时的parties，该值一经CyclicBarrier创建将不会被改变。
**/
int getParties();
/**
调用该方法之后，当前线程将会进入阻塞状态，等待其他线程执行await()方法进入barrier point，
进而全部退出阻塞状态，
当CyclicBarrier内部的count为0时，调用await()方法将会直接返回而不会进入阻塞状态。
**/
int await() throws InterruptedException, BrokenBarrierException 

/**
与无参的await方法类似，只不过增加了超时的功能
当其他线程在设定的时间内没有到达barrier point时，当前线程也会退出阻塞状态
**/
int await(long timeout, TimeUnit unit)
/**
返回barrier的broken状态，某个线程由于执行await方法而进入阻塞状态，
如果该线程被执行了中断操作，那么isBroken()方法将会返回true。
**/
boolean isBroken()
/**
该方法返回当前barrier有多少个线程执行了await方法
而不是还有多少个线程未到达barrier point
**/
int getNumberWaiting()
/**
其主要作用是中断当前barrier，并且重新生成一个generation，
还有将barrier内部的计数器count设置为parties值，
但是需要注意的是，如果还有未到达barrier point的线程，
则所有的线程将会被中断并且退出阻塞，此时isBroken()方法将返回false而不是true。
**/
void reset()

演示isBroken方法

public static void main(String[] args) throws InterruptedException {
    final CyclicBarrier barrier = new CyclicBarrier(2);
    Thread thread = new Thread(() -> {
        try {
            barrier.await();
        } catch (InterruptedException e) {
            System.out.println("捕获中断信号");
        } catch (BrokenBarrierException e) {
            e.printStackTrace();
        }
    });
    thread.start();
    // 两秒后在main线程中执行thread的中断操作
    TimeUnit.SECONDS.sleep(2);
    // 调用中断
    thread.interrupt();
    // 短暂休眠，确保thread的执行动作发生在main线程读取broken状态之前
    TimeUnit.SECONDS.sleep(2);
    // 输出barrier的broken状态，这种情况下该返回值肯定为true
    System.out.println(barrier.isBroken());
}

可见：

• 当一个线程由于在执行CyclicBarrier的await方法而进入阻塞状态时，这个时候对该线程执行中断操作会导致CyclicBarrier被broken。
• 被broken的CyclicBarrier此时已经不能再直接使用了，如果想要使用就必须使用reset方法对其重置。
• 如果有其他线程此时也由于执行了await方法而进入阻塞状态，那么该线程会被唤醒并且抛出BrokenBarrierException异常。

演示reset方法

public static void main(String[] args) throws InterruptedException {
     final CyclicBarrier barrier = new CyclicBarrier(3);

     Thread thread = new Thread(() ->
     {
         try {
             barrier.await();
         } catch (InterruptedException | BrokenBarrierException e) {
             e.printStackTrace();
         }
     });
     thread.start();
     TimeUnit.SECONDS.sleep(2);
     // 执行reset方法，thread线程将会被中断
     barrier.reset();
     // 此时isBroken()为false而不是true
     System.out.println(barrier.isBroken());
 }

输出：

false
java.util.concurrent.BrokenBarrierException
	at java.util.concurrent.CyclicBarrier.dowait(CyclicBarrier.java:250)
	at java.util.concurrent.CyclicBarrier.await(CyclicBarrier.java:362)
	at study.wyy.juc.utils.CyclicBarrierDemo2.lambda$main$0(CyclicBarrierDemo2.java:44)
	at java.lang.Thread.run(Thread.java:748)

5 CyclicBarrier VS CountDownLatch

CyclicBarrier和CoundDownLatch两者都可用于管理和控制子任务线程的执行，在某些场景下，它们都可以实现类似的功能，但是它们在本质上存在着很多差别：

• CoundDownLatch的await方法会等待计数器被count down到0，而执行CyclicBarrier的await方法的线程将会等待其他线程到达barrier point。
• CyclicBarrier内部的计数器count是可被重置的，进而使得CyclicBarrier也可被重复使用，而CoundDownLatch则不能。
• CyclicBarrier是由Lock和Condition实现的，而CountDownLatch则是由同步控制器AQS（AbstractQueuedSynchronizer）来实现的。
• 在构造CyclicBarrier时不允许parties为0，而CountDownLatch则允许count为0