JavaCountDownLatch线程同步方法解析

大家好，我们又见面了啊~本文《Java如何用CountDownLatch实现线程同步》的内容中将会涉及到等等。如果你正在学习文章相关知识，欢迎关注我，以后会给大家带来更多文章相关文章，希望我们能一起进步！下面就开始本文的正式内容~

CountDownLatch 是一次性同步辅助类，用于让线程等待其他线程完成指定数量的操作；典型场景包括主线程等待多个子任务结束、测试并发起跑线、多异步初始化完成等。

CountDownLatch 是什么，什么时候该用它

CountDownLatch 是一个一次性同步辅助类，核心作用是让一个或多个线程等待，直到其他线程完成一组操作。它不用于保护共享资源，也不替代 synchronized 或 ReentrantLock；它的典型场景是「等全部任务做完再继续」，比如：

• 主线程启动多个子任务后，统一等待它们全部结束
• 测试中模拟并发请求到达的“起跑线”
• 初始化阶段依赖多个异步加载项完成

它内部维护一个计数器，调用 countDown() 递减，调用 await() 的线程会阻塞直到计数器归零。计数器归零后，所有等待线程被唤醒，且后续再调用 await() 会立即返回——它不可重置，用完即弃。

怎么正确初始化和触发等待

构造时必须传入正整数作为初始计数：new CountDownLatch(3) 表示要等 3 次 countDown()。常见错误包括：

• 传入 0：虽然合法，但 await() 立即返回，容易掩盖逻辑误判
• 计数与实际任务数不一致：比如启动了 5 个线程却只 countDown() 4 次，主线程永远卡在 await()
• 在非预期位置调用 countDown()：例如在异常分支遗漏调用，导致计数无法归零

推荐写法是在每个任务执行完毕（无论成功或失败）后确保调用 countDown()，通常放在 finally 块里：

executor.submit(() -> {
    try {
        doWork();
    } finally {
        latch.countDown(); // 保证计数一定减少
    }
});

await() 要不要加超时？为什么

无参 await() 会无限等待，一旦漏调 countDown() 或某个任务卡死，整个流程就挂住。生产环境强烈建议使用带超时的版本：latch.await(10, TimeUnit.SECONDS)。

• 返回 true 表示计数已归零，可安全继续
• 返回 false 表示超时，此时应主动处理：记录告警、中断任务、清理资源
• 超时单位别写错：TimeUnit.MILLISECONDS 和 TimeUnit.SECONDS 差 1000 倍，容易误判

注意：超时后 await() 返回 false，但计数器状态不变；如果之后别的线程又调了 countDown() 归零，不会重新唤醒已超时返回的线程——它已经走完了。

和 CyclicBarrier、Phaser 有什么关键区别

选错工具会导致逻辑难维护或行为异常：

• CyclicBarrier 可重复使用，适合多轮协作（如多轮计算迭代），且支持到达时触发 Runnable 动作；而 CountDownLatch 一旦触发就失效
• Phaser 更灵活，能动态增删参与者、分阶段等待，但复杂度高；简单“等 N 件事做完”场景，CountDownLatch 更轻量、语义更清晰
• 它们都不解决线程安全问题：如果多个线程共用同一份结果容器（如 ArrayList），仍需额外同步机制

别为了“看起来高级”硬套 Phaser，多数初始化等待、批量任务汇合场景，CountDownLatch 就是最直接的选择。真正容易被忽略的是：它不传递异常，子线程抛出的异常不会自动冒泡到 await() 调用方，得靠额外机制（比如 Future.get() 或共享 AtomicReference）捕获。

好了，本文到此结束，带大家了解了《JavaCountDownLatch线程同步方法解析》，希望本文对你有所帮助！关注golang学习网公众号，给大家分享更多文章知识！