CountDownLatch与CyclicBarrier

对于AbstractQueuedSynchronizer衍生出来的并发工具类，这一篇再介绍俩。

场景1：有4个大文件的数据需要统计，最终将所有的统计结果进行加工，得到最后的分析数据。为了加速处理过程，当然是利用多线程：开启4个线程去分别统计每个文件的数据，开启1个线程对之前4个线程的数据加工。

这里的难点是加工线程必须等到4个统计线程都结束了，才能开始工作，不然加工出来的数据肯定是脏的。

如何保证这一点呢，synchronized、wait-notify、Condition这些机制实现起来好像特别麻烦，需要自己实现很多逻辑的控制。正是基于这个痛点，并发大师提供了一个工具类---CountDownLatch。

先来看看如何使用：

package countdownlatch;

import java.util.concurrent.CountDownLatch;

public class CountDownLatchTest {

    public static void main(String[] args) {
        CountDownLatch latch = new CountDownLatch(4);

        new Thread() {
            @Override
            public void run() {
                System.out.println("加工线程：" + Thread.currentThread().getName() + "开始等待数据");
                try {
                    latch.await();
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
                System.out.println("数据都到齐了！！！");
            }
        }.start();

        for (int i=0; i<4; i++) {
            new Thread() {
                @Override
                public void run() {
                    System.out.println(Thread.currentThread().getName() + "开始统计数据");
                    try {
                        sleep(1000);  // 模拟统计过程
                    } catch (InterruptedException e) {
                        e.printStackTrace();
                    }
                    System.out.println(Thread.currentThread().getName() + "统计完成");
                    latch.countDown();
                }
            }.start();
        }
    }
}

运行结果

加工线程：Thread-0开始等待数据
Thread-1开始统计数据
Thread-2开始统计数据
Thread-3开始统计数据
Thread-4开始统计数据
Thread-1统计完成
Thread-4统计完成
Thread-3统计完成
Thread-2统计完成
数据都到齐了！！！

通过CountDownLatch的await和countDown方法轻松的实现了控制逻辑，从源码进去看看，发现await方法的执行逻辑跟上一篇的Semaphore的逻辑几乎一模一样，只不过tryAcquireShared方法的逻辑实现不一样

        protected int tryAcquireShared(int acquires) {
            return (getState() == 0) ? 1 : -1;
        }

简单吧。CountDownLatch里面的内部类把从AbstractQueuedSynchronizer继承来的state属性，当作需等待的线程数量，tryAcquireShared方法只是判断这个数量是否到0了。如果没有到0，返回-1，后续会执行AbstractQueuedSynchronizer的doAcquireSharedInterruptibly方法，将当前线程封装成共享模式的节点，添加到等待队列。具体内容不再赘述。

再看看countDown方法的主要逻辑：

       protected boolean tryReleaseShared(int releases) {
            // Decrement count; signal when transition to zero
            for (;;) {
                int c = getState();
                if (c == 0)  // c为0说明已经release了，比如说4个已经线程完事，第5个线程又调用了countDown方法，不会产生任何影响
                    return false;
                int nextc = c-1;  // 只是减1，参数releases没起作用
                if (compareAndSetState(c, nextc))
                    return nextc == 0;
            }
        }

又见无限循环里面的CAS操作。每个被等待的线程调用一次countDown方法，state减1，最后一次调用的时候，nextc == 0为true，就会执行AbstractQueuedSynchronizer的doReleaseShared方法

    private void doReleaseShared() {
        /*
         * Ensure that a release propagates, even if there are other
         * in-progress acquires/releases.  This proceeds in the usual
         * way of trying to unparkSuccessor of head if it needs
         * signal. But if it does not, status is set to PROPAGATE to
         * ensure that upon release, propagation continues.
         * Additionally, we must loop in case a new node is added
         * while we are doing this. Also, unlike other uses of
         * unparkSuccessor, we need to know if CAS to reset status
         * fails, if so rechecking.
         */
        for (;;) {
            Node h = head;
            if (h != null && h != tail) {
                int ws = h.waitStatus;
                if (ws == Node.SIGNAL) {
                    if (!compareAndSetWaitStatus(h, Node.SIGNAL, 0))
                        continue;            // loop to recheck cases
                    unparkSuccessor(h);
                }
                else if (ws == 0 &&
                         !compareAndSetWaitStatus(h, 0, Node.PROPAGATE))
                    continue;                // loop on failed CAS
            }
            if (h == head)                   // loop if head changed
                break;
        }
    }

虽然实现逻辑略显复杂，一句话概括就是，将等待队列里的等待线程都unpark，之前的例子就是将加工线程唤醒。

好了，CountDownLatch就到这里。

场景2：有4个大文件的数据需要处理，每个文件处理过程分2步，1）先检查文件数据是否正确，2）然后统计这个文件的某个指标；但是只要有一个文件检查没有完成（比如数据有错），所有的统计就失去意义。

思路：开启4个线程分别对应每个文件，每个线程执行完步骤1，不能马上执行步骤2，必须等待其他的3个线程都执行完步骤1，然后4个线程才能进行步骤2。

所以这里的难点是如何保证一个线程执行到某一点（步骤1完成），必须等待其他的线程也执行到这个点。

乍一看，好像是一个简单的线程通信问题。但是wait-notify、Condition的唤醒机制是一个线程唤醒另一个（或多个）线程，而这里是互相牵制，一个线程是不知道能不能进行唤醒操作的，因为有别的线程还没有执行完步骤1。

问题变得既抽象又复杂，但是并发大师有完美的解决方案---CyclicBarrier。

看例子

package cyclicbarrier;

import java.util.concurrent.BrokenBarrierException;
import java.util.concurrent.CyclicBarrier;

public class CyclicBarrierTest {

    public static void main(String[] args) {
        CyclicBarrier barrier = new CyclicBarrier(4);

        for (int i=0; i<4; i++) {
            new Thread() {
                @Override
                public void run() {
                    System.out.println(Thread.currentThread().getName() + "开始检查文件");
                    try {
                        sleep(2000);  // 模拟检查过程
                    } catch (InterruptedException e) {
                        e.printStackTrace();
                    }
                    System.out.println(Thread.currentThread().getName() + "检查文件结束，等待其他线程");
                    try {
                        barrier.await();  // 等待
                    } catch (InterruptedException | BrokenBarrierException e) {
                        e.printStackTrace();
                    }
                    System.out.println(Thread.currentThread().getName() + "统计");
                }
            }.start();
        }
    }
}

运行结果

Thread-2开始检查文件
Thread-3开始检查文件
Thread-0开始检查文件
Thread-1开始检查文件
Thread-0检查文件结束，等待其他线程
Thread-3检查文件结束，等待其他线程
Thread-2检查文件结束，等待其他线程
Thread-1检查文件结束，等待其他线程
Thread-1统计
Thread-2统计
Thread-0统计
Thread-3统计

规整有序结果，说明线程之间的控制很到位，但是我们只是调用了一个await方法，那实现的代码必定复杂，硬着头皮看看

await方法的核心逻辑都在dowait方法里面：

    /**
     * Main barrier code, covering the various policies.
     */
    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();
        }
    }

这里的实现还是借助了ReentrantLock和Condition，看看CyclicBarrier里面的属性

    /** The lock for guarding barrier entry */
    private final ReentrantLock lock = new ReentrantLock();
    /** Condition to wait on until tripped */
    private final Condition trip = lock.newCondition();
    /** The number of parties */
    private final int parties;
    /* The command to run when tripped */
    private final Runnable barrierCommand;
    /** The current generation */
    private Generation generation = new Generation();

    /**
     * Number of parties still waiting. Counts down from parties to 0
     * on each generation.  It is reset to parties on each new
     * generation or when broken.
     */
    private int count;

parties是刚开始互相等待的线程数；count是还在让别的线程等待的线程数；barrierCommand是所有线程都执行到指定位置之后马上执行的任务，就像场景1中最后的加工任务；generation标识分代信息。举个例子，左轮手枪可以装6发子弹，某一时刻，还剩2发；parties就是6，count就是2；当6发子弹全部打出，如果要执行一个动作（比如维修、清洗），这个动作就是barrierCommand；然后需要重新装入子弹，这就是一个换代的过程。

CyclicBarrier引入分代的概念就是想重复利用，Cyclic就是可循环的意思。

再回到dowait方法，参数timed和nanos代表是否考虑超时的问题，大致梳理一下执行流程：

1、先加锁，同一时刻，只有一个线程可以执行后续逻辑。

2、count减1后，如果为0，说明这个线程就是最后一个被等待的线程，就可以执行barrierCommand，然后执行更新换代：先唤醒所有的还在等待的线程，然后将parties、count、generation统统更新；

3、如果不为0，线程自己也会被加入Condition的等待队列

4、时刻要考虑超时问题、中断异常处理、换代的意外等

最后比较一下CountDownLatch和CyclicBarrier：

1、从场景1和场景2来看，这两个工具类的关注点不一样，CountDownLatch关注的是某一类线程等待另一类线程的信号（执行countDown方法），而CyclicBarrier关注的是同一类线程互相等待彼此的信号（执行await方法）

2、CyclicBarrier可以重复使用，而CountDownLatch只能使用一次