JUnit测试中Thread.join()表现异常：与CountDownLatch行为差异原因？

核心原因在于两者对线程并发时机的控制精度不同，再结合JUnit测试环境的线程调度特性，最终导致了差异：

1. 先明确ConcurrentModificationException的触发条件 #

这个异常是集合的fail-fast快速失败机制抛出的，只有当：

• 一个线程通过迭代器遍历集合（比如for-each循环）
• 同时另一个线程直接修改集合（非迭代器的remove()方法）
• 且修改操作发生在遍历过程中（而非遍历开始前或结束后）

才会触发——它本身是概率性的，依赖线程调度的时机重叠。

2. Thread.join()和CountDownLatch的本质差异 #

（1）Thread.join()的局限性 #

当你调用thread1.start(); thread2.start(); thread1.join(); thread2.join();时，只是保证主线程等待两个子线程执行完毕，但无法控制子线程何时开始执行核心的遍历/修改操作。

在JUnit的测试环境中，线程调度可能会出现“有序执行”的情况：比如遍历线程先快速完成所有迭代，修改线程才开始修改；或者修改线程先完成所有添加操作，遍历线程才启动。这种情况下，遍历和修改没有时间重叠，自然不会触发异常。

（2）CountDownLatch的精准同步 #

CountDownLatch可以实现多线程的同步起点：

• 你可以让遍历线程和修改线程在执行核心操作前，先调用latch.await()阻塞等待
• 主线程在启动两个子线程后，调用两次latch.countDown()，让两个子线程几乎同时开始执行遍历和修改操作

这种强制的并发启动，直接确保了遍历和修改操作的时间重叠，大大提升了触发ConcurrentModificationException的概率——甚至可以说是必然触发。

3. JUnit测试环境的额外影响 #

JUnit的测试线程运行环境和普通main方法有差异：

• 测试线程可能属于守护线程，JVM对其调度策略更偏向“有序性”
• JUnit框架本身对线程的管理可能弱化了并发冲突的概率

这就导致join()方式下，线程调度的随机性被降低，更难出现遍历和修改重叠的情况；而CountDownLatch的强制同步机制，直接打破了这种有序调度，让并发冲突必然发生。

内容的提问来源于stack exchange，提问作者Martin521Wang