我通读了一下java.util.concurrent API,发现
CountDownLatch
:一种同步辅助工具,允许一个或多个线程等待,直到一组操作在其他线程中执行。completes.CyclicBarrier
:一种同步辅助工具,允许一组线程相互等待以达到共同的障碍点。在我看来,两者似乎是平等的,但我相信还有更多的原因。
例如,在CoundownLatch, the countdown value could not be reset, that can happen in the case of CyclicBarrier
中。
这两者之间还有什么不同吗?
什么是有人想要重置倒计时的值的use cases
?
发布于 2010-11-13 04:37:33
一个主要的区别是,CyclicBarrier接受一个(可选的)可运行的任务,该任务在满足公共障碍条件时运行。
它还允许您获取在屏障处等待的客户端数量以及触发屏障所需的数量。一旦触发,屏障将被重置,并可再次使用。
对于简单的用例-服务启动等。CountdownLatch就可以了。CyclicBarrier对于更复杂的协调任务很有用。这类事情的一个例子是并行计算--计算中涉及多个子任务--有点像MapReduce。
发布于 2011-03-01 12:53:33
还有一个不同之处。
在使用CyclicBarrier
时,假设您指定触发屏障的等待线程的数量。如果指定5,则必须至少有5个线程才能调用await()
。
在使用CountDownLatch
时,您可以指定对countDown()
的调用次数,这将导致所有等待的线程都被释放。这意味着您只能将CountDownLatch
与单个线程一起使用。
“你为什么要这么做?”你可能会说。想象一下,您正在使用一个由其他人编写的执行回调的神秘API。您希望其中一个线程等待,直到某个回调被多次调用。您不知道将在哪些线程上调用回调。在这种情况下,CountDownLatch
是完美的,而我想不出任何使用CyclicBarrier
实现这一点的方法(实际上,我可以,但它涉及到超时...讨厌!)。
我只希望CountDownLatch
能被重置!
发布于 2012-10-08 00:03:03
还没有人提到的一点是,在CyclicBarrier
中,如果一个线程有问题(超时、中断...),所有其他到达await()
的线程都会得到一个异常。参见Javadoc:
CyclicBarrier对失败的同步尝试使用全有或全无中断模型:如果线程由于中断、故障或超时而过早离开障碍点,则在该障碍点等待的所有其他线程也将通过BrokenBarrierException异常离开(如果它们几乎在同一时间也被中断,则为InterruptedException )。
https://stackoverflow.com/questions/4168772
复制相似问题