CountDownLatch和CyclicBarrier是jdk concurrent包下非常有用的两个并发工具类，它们提供了一种控制并发流程的手段。本文将会提供一些应用场景，结合源码，对它们的具体实现以及如何使用做一个具体分析。
CountDownLatch
CountDownLatch允许一个或多个线程等待其他线程完成操作。
CountDownLatch使用案例
需求：解析一个文件下多个txt文件数据，可以考虑使用多线程并行解析以提高解析效率。每一个线程解析一个文件里的数据，等到所有数据解析完毕之后再进行其他操作。
设计分析：在这个需求中，需要实现主线程等待所有线程完成文件解析操作，CountDownLatch正好可以做到。
代码实现：
注：只给一个简单的架子，表明CountDownLatch的具体使用方式，txt文件解析在这里就不做详细的代码实现了。
- CountDownLatch声明：
CountDownLatch的构造函数接受int型参数作为它的计数器，如果想等待N个点完成，就传入N； - 调用CountDownLatch的countDown方法时，N会减1，CountDownLatch的await方法会阻塞主线程直到N减少到0。
CountDownLatch源码分析
CountDownLatch是自定义AQS同步组件，接下来就以自定义同步器Sync、countDown方法和await方法为切入点，分析CountDownLatch的具体实现。
自定义同步器Sync实现
同步器Sync实现了共享式获取同步状态的acquire和release，前文中已经详细介绍过AQS相关内容，在这里我就不再做详细介绍分析了。构造方法
从构造方法的具体实现可以看出，通过构造方法传入的int型参数count其实就是同步器的状态。countDown实现
整个countDown只做了一件事情，释放同步状态，同步状态在这里的实际意义也就是需要等待的完成的点的数量，只要每完成一个点，就调用countDown方法释放同步状态。await实现
CountDownLatch提供带超时时间的await和不带超时时间的await：
await的实质是在获取同步状态，同步状态state == 0成立，当前等待完成的点均已完成，主线程继续往下执行，否则，主线程进入等待队列自旋等待直到同步状态释放后state == 0。有些时候主线程是不能一直自旋等待，这个时候带超时时间的await就派上用场了，设置超时时间，如果在指定时间内N个点都未完成，返回false，主线程不再等待，继续往下执行。
总结：CountDownLatch实质上就是一个AQS计数器，通过AQS来实现线程的等待与唤醒。
CyclicBarrier
CyclicBarrier，让一组线程到达一个同步点后再一起继续运行，在其中任意一个线程未达到同步点，其他到达的线程均会被阻塞。
CyclicBarrier源码分析
-
构造方法
CyclicBarrier提供两个构造方法CyclicBarrier(int parties)和CyclicBarrier(int parties, Runnable barrierAction)：
CyclicBarrier(int parties)
默认构造方法，参数表示拦截的线程数量。CyclicBarrier(int parties, Runnable barrierAction)
由于线程之前的调度是由CPU决定的，所以默认的构造方法无法设置线程执行优先级，CyclicBarrier提供一个更高级的构造函数CyclicBarrier(int parties, Runnable barrierAction)，用于在线程到达同步点时，优先执行线程barrierAction，这样可以更加方便的处理一些负责的业务场景。
创建CyclicBarrier后，每个线程调用await方法告诉CyclicBarrier自己已经到达同步点，然后当前线程被阻塞。接下来我们来看看await方法的具体实现。
await实现
CyclicBarrier同样提供带超时时间的await和不带超时时间的await：
整个await方法的核心是dowait方法的调用，我们来看看dowait的具体实现。-
dowait实现
在dowait的前段部分，主要完成了当所有线程都到达同步点（barrier）时，唤醒所有的等待线程，一起往下继续运行，可根据参数barrierAction决定优先执行的线程。
在dowait的实现后半部分，主要实现了线程未到达同步点（barrier）时，线程进入Condition自旋等待，直到等待超时或者所有线程都到达barrier时被唤醒。
在整个dowait：
- 使用ReentrantLock保证每一次操作线程安全；
- 线程等待/唤醒使用Lock配合Condition来实现；
- 线程被唤醒的条件：等待超时或者所有线程都到达barrier。
到这里为止，CyclicBarrier的重要实现源码分析就结束了，接下来还是照样给出一个具体的使用案例，方便掌握CyclicBarrier的具体用法。
CyclicBarrier使用案例
需求：多线程计算数据，merge计算结果。
代码实现：
运行结果：
CyclicBarrier和CountDownLatch都可以实现线程等待，那么它俩之间的区别是什么呢？
CyclicBarrier和CountDownLatch的区别
看了各种资料和书，大家一致的意见都是CountDownLatch是计数器，只能使用一次，而CyclicBarrier的计数器提供reset功能，可以多次使用。但是我不那么认为它们之间的区别仅仅就是这么简单的一点。我们来从jdk作者设计的目的来看，javadoc是这么描述它们的：
CountDownLatch: A synchronization aid that allows one or more threads to wait until a set of operations being performed in other threads completes.
CyclicBarrier : A synchronization aid that allows a set of threads to all wait for each other to reach a common barrier point.
从javadoc的描述可以得出：
- CountDownLatch：一个或者多个线程，等待其他多个线程完成某件事情之后才能执行；
- CyclicBarrier：多个线程互相等待，直到到达同一个同步点，再继续一起执行。
对于CountDownLatch来说，重点是“一个线程（多个线程）等待”，而其他的N个线程在完成“某件事情”之后，可以终止，也可以等待。而对于CyclicBarrier，重点是多个线程，在任意一个线程没有完成，所有的线程都必须等待。
CountDownLatch是计数器，线程完成一个记录一个，只不过计数不是递增而是递减，而CyclicBarrier更像是一个阀门，需要所有线程都到达，阀门才能打开，然后继续执行。