CountDownLatch 和 CyclicBarrier

一、CountDownLatch

　　其实要完成这种某个线程等待其他线程结果才能开始任务的业务，直接在需要准备的线程中join()依赖的线程就能完成要求，但是在博客的上一篇《三个线程顺序输出》中也说到过，join的线程返回，必须是子线程已经结束。而CountDownLatch提供了更灵活的方案，可在子线程完成好其他线程依赖的工作后调用countDown()方法主动减少计数，同时继续做线程间业务无依赖的其他工作。

　　这里CountDownLatch只提供了一个构造方法，参数为大于0整数：

 public CountDownLatch(int count) {
        if (count < 0) throw new IllegalArgumentException("count < 0");
        this.sync = new Sync(count);
    }

　　具体演示如下：

public class CountDownLatchTest {

    private static CountDownLatch counter = new CountDownLatch(2);

    public static void main(String[] args) throws InterruptedException {
        Thread threadA = new Thread(new Runnable() {
            @Override
            public void run() {
                System.out.println("子线程：" + Thread.currentThread().getName() + " start working！");
                try {
                    Thread.sleep(2000);
                    counter.countDown();
                    System.out.println("子线程：" + Thread.currentThread().getName() + " working finish!");
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
            }
        }, "thread_A");
        Thread threadB = new Thread(new Runnable() {
            @Override
            public void run() {
                System.out.println("子线程：" + Thread.currentThread().getName() + " start working！");
                try {
                    Thread.sleep(1000);
                    counter.countDown();
                    System.out.println("子线程：" + Thread.currentThread().getName() + " working finish!");
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
            }
        }, "thread_B");
        threadA.start();
        threadB.start();
        counter.await();
        System.out.println("A、B准备就绪！");
        // do something C...
    }
}

　　结果：

　　可以看到在counter.countDown()被调用两次后，主线程便继续执行，同时子线程A、B仍可继续完成各自的工作。需要注意的是，这里初始化的计数值为2，调用2次正好返回，如果初始值为3，而实际只调用2次，那么程序就会在await()处无限等待。因此await()也提供了带等待时间的使用方法：

public boolean await(long timeout, TimeUnit unit)
        throws InterruptedException {
        return sync.tryAcquireSharedNanos(1, unit.toNanos(timeout));
    }

　　例如把测试程序中的await()改成如下：

counter.await(1000,TimeUnit.MILLISECONDS);

　　可以看到结果中，await()在没有等到计数归0，就回到主线程继续执行：

　　另外CountDownLatch也提供了getCount()方法随时获取当前剩余计数。

　 

二、CyclicBarrier

　　译作同步屏障，提供了2种初始化方法，第一种为简单int参数：

    public CyclicBarrier(int parties) {
        this(parties, null);
    }

　　即挂起当前线程，直到所有设定的线程都到达Barrier状态，再一起执行后续任务。

    public CyclicBarrier(int parties, Runnable barrierAction) {
        if (parties <= 0) throw new IllegalArgumentException();
        this.parties = parties;
        this.count = parties;
        this.barrierCommand = barrierAction;
    }

　　第二种方法可以设定一个任务，在程序都到达设定的barrier后，再执行barrierAction，截取部分源码如下：

        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();
                }
            }    

　　可以看到在index为0时，如果command不为null，会执行run()方法。注意run()方法并不是start()，也就是并没有再起一个线程，而是在最后到达barrier的线程中继续执行barrierCommand，再返回。

　　这里直接演示第二种初始化下的使用，代码如下：

public class CyclicBarrierTest {

    private static int N = 3;

    private static CyclicBarrier barrier = new CyclicBarrier(N, new Runnable() {

        @Override
        public void run() {
            // TODO Auto-generated method stub
            System.out.println("barrierAction：" + Thread.currentThread().getName() + " 开始工作");
            try {
                Thread.sleep(9000);
                System.out.println("barrierAction：" + Thread.currentThread().getName() + " 结束工作");
            } catch (InterruptedException e) {
                // TODO Auto-generated catch block
                e.printStackTrace();
            }
        }
    });

    static class Writer extends Thread {

        private CyclicBarrier cyclicBarrier;

        public Writer(CyclicBarrier barr) {
            this.cyclicBarrier = barr;
        }

        @Override
        public void run() {
            System.out.println("线程" + Thread.currentThread().getName() + "开始写入数据到文件...");
            long sleepTime = (long) (Math.random() * 1000 + 1000);
            try {
                Thread.sleep(sleepTime);
                System.out
                        .println("线程" + Thread.currentThread().getName() + "用时" + sleepTime + "ms写入数据完毕，等待其他线程完成写入...");
                cyclicBarrier.await();
            } catch (InterruptedException | BrokenBarrierException e) {
                // TODO Auto-generated catch block
                e.printStackTrace();
            }
            System.out.println("所有线程写入完毕，继续处理其他任务...");
        }
    }

    public static void main(String[] args) {
        for (int i = 0; i < N; i++) {
            new Writer(barrier).start();
        }

    }
}

　　运行结果：

         

　　特意多运行了几次，从结果中可以看出:

　　　　1、在barrier处等待的线程数到达设定值（这里为3）前，当前线程会在cyclicBarrier.await()处挂起；

　　　　2、如果设定了barrierAction任务，当最后到达barrier处的线程在执行await()方法时，会执行barrierAction任务，图中打出了每个任务的执行时间，可以看到每次都是执行任务时间最长，即最后到达barrier处的线程，会继续执行barrierAction方法；

　　　　3、虽然到达了设定的await()线程数，但是必须在最后一个到达的线程执行完barrierAction方法，等await()返回后，所有线程才会继续执行后续的代码，示例中barrierActio()方法故意设定了较长的等待时间，但是程序依然在等待await()返回。

　　另外，为了避免await()无休止的等待，JDK同样提供了带等待时间的await方法，观察源码片段：

if (timed && nanos <= 0L) {
    breakBarrier();
    throw new TimeoutException();
}

　　这里要特别注意的时当某个线程抛出TimeoutException异常后会调用breakBarrier()方法把broken值设置为true： 

    private void breakBarrier() {
        generation.broken = true;
        count = parties;
        trip.signalAll();
    }

　　之所以这里提到这个，是因为在dowait()方法中，如果broken为真，函数将直接返回，抛出BrokenBarrierException，造成结果：

　　　　1、如果使用了带barrierCommand方法的构造函数，这里barrierCommand将不会执行；

　　　　2、如果多个线程设置的await()时间不一样，例如A设置的等待时间较短，假设1秒后超时返回，那么B、C即使设置更长的等待时间，他们也不会在await()处等待，而是在运行到await()后立刻抛出BrokenBarrierException。

/**
     * 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();
        }
    }

　　使用带等待参数的await()，运行上文中的代码，故意使等待超时，结果如下：

　　另外CyclicBarrier是可以重用的，这里直接给出@海子博客中的例子：

public class Test {
    public static void main(String[] args) {
        int N = 2;
        CyclicBarrier barrier = new CyclicBarrier(N);

        for (int i = 0; i < N; i++) {
            new Writer(barrier).start();
        }

        try {
            Thread.sleep(25000);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }

        System.out.println("CyclicBarrier重用");

        for (int i = 0; i < N; i++) {
            new Writer(barrier).start();
        }
    }

    static class Writer extends Thread {
        private CyclicBarrier cyclicBarrier;

        public Writer(CyclicBarrier cyclicBarrier) {
            this.cyclicBarrier = cyclicBarrier;
        }

        @Override
        public void run() {
            System.out.println("线程" + Thread.currentThread().getName() + "正在写入数据...");
            try {
                Thread.sleep(5000); // 以睡眠来模拟写入数据操作
                System.out.println("线程" + Thread.currentThread().getName() + "写入数据完毕，等待其他线程写入完毕");

                cyclicBarrier.await();
            } catch (InterruptedException e) {
                e.printStackTrace();
            } catch (BrokenBarrierException e) {
                e.printStackTrace();
            }
            System.out.println(Thread.currentThread().getName() + "所有线程写入完毕，继续处理其他任务...");
        }
    }
}

　　运行效果如图：

　　

三、CountDownLatch 和 CyclicBarrier区别

　　1、从使用上可以发现二者侧重点不同，在CountDownLatch使用时其实是存在主线程和子线程的概念，子线程在准备好主线程需要的资源后，主线程结束等待，继续剩下的工作；而在CyclicBarrier使用中，并不存在主和次的说法，更像是一组线程在互相等待后，然后在同一时间，继续后面的操作，可以类比于现实中跑步比赛的场景，一组运动员在各自准备好起跑动作后，由裁判员发令后，统一起跑（额，这里想不到合适的业务场景，尴想了一个强行解释，或许，在优化资源利用时，设置一定的请求数，攒满了后再一起请求？有实际的应用场景欢迎补充）。

　　2、等待超时CountDownLatch会直接返回，继续后续工作，CyclicBarrier首先会抛TimeoutException，同时如果barrier要等的线程数大于1，其他线程不会按设定的等待时间等待，而是抛出BrokenBarrierException后直接返回，所以使用CyclicBarrier要注意异常处理的逻辑。

　　3、使用细节差异如下表：

　　    

 　　4、最后要提的是CountDownLatch 和 CyclicBarrier虽然基本都是在多线程中使用，但是同一个线程多次调用countDown()和await()其实也会使计数改变。

参考资料：

　　1、http://www.importnew.com/21889.html

　　2、https://blog.csdn.net/tolcf/article/details/50925145