感觉join就可以解决问题啊，为什么要有CyclicBarrier和CountDownLatch
业精于勤，荒于嬉;行成于思，毁于随。
第一个. 用Thread.join只能部分的实现CountDownLatch的功能. 这个看看CountDownLatch的java doc就可以了. 不多说
第二个. Thread.join用了Object.wait/notify机制. java.lang.Thread.join(long millis) java doc里写道:
This implementation uses a loop of this.wait calls conditioned on this.isAlive. As a thread terminates the this.notifyAll method is invoked. It is recommended that applications not use wait, notify, or notifyAll on Thread instances.
Effective Java第二版里说的很好, wait/nofify 和java.util.concurrent提供的功能比起来, 就好像是 并发汇编语言(concurrency assembly language) 一样. 更难用而且也更容易出bug.
总结下: 从java1.5 有了并发包之后, 以前的 wait/notify/timer/synchorinized/同步容器 等等, 都应该尽可能的 用java 1.5并发包取代.
http://stackoverflow.com/questions/21808814/whats-the-difference-between-cyclicbarrier-countdownlatch-and-join-in-java
![[Web フロントエンド] Node.js クイック スタート](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
第一个. 用Thread.join只能部分的实现CountDownLatch的功能. 这个看看CountDownLatch的java doc就可以了. 不多说
第二个. Thread.join用了Object.wait/notify机制. java.lang.Thread.join(long millis) java doc里写道:
Effective Java第二版里说的很好, wait/nofify 和java.util.concurrent提供的功能比起来, 就好像是 并发汇编语言(concurrency assembly language) 一样. 更难用而且也更容易出bug.
总结下: 从java1.5 有了并发包之后, 以前的 wait/notify/timer/synchorinized/同步容器 等等, 都应该尽可能的 用java 1.5并发包取代.
http://stackoverflow.com/questions/21808814/whats-the-difference-between-cyclicbarrier-countdownlatch-and-join-in-java