CountDownLatch构造参数必须为正整数，因内部volatile int计数器要求非负，负数抛IllegalArgumentException；0虽合法但导致await立即返回，易误判任务完成。
CountDownLatch 构造参数为什么必须是正整数
因为 CountDownLatch 内部用一个 volatile int 计数器实现，构造时传入负数会直接抛 IllegalArgumentException：“count must be non-negative”。这不是设计疏漏，而是语义强制：闭锁的“等待次数”只能是明确、有限的正向倒计时。
常见错误现象：new CountDownLatch(-1) 或 new CountDownLatch(0) —— 后者虽不报错，但会导致 await() 立即返回，无法起到等待作用，容易误判为“线程已全部完成”，实际可能一个都没启动。
- 使用场景：你明确知道有 N 个并行任务要等（比如启动 5 个数据拉取线程，主线程等它们全结束再合并结果）
- 参数差异：
new CountDownLatch(1)适合“一等一”信号；new CountDownLatch(n)才是典型多线程协同场景 - 性能影响：构造本身无开销，但频繁新建大量
CountDownLatch实例（尤其在循环里）会增加 GC 压力
await() 调用后没等到就继续执行了？检查是否漏掉 countDown()
await() 阻塞的前提是计数器 > 0。如果某个线程没调用 countDown()，或者调用被异常吞掉、写在 try-catch 里却没处理异常分支，主线程就会无限阻塞（或超时后失败）。
常见错误现象：await() 返回 false（超时），或程序卡死；日志显示部分子线程已结束，但闭锁未释放。
立即学习“Java免费学习笔记（深入）”；
在调试 Java 后端 API 故障时使用此技能，尤其适用于以下任务：分析日志、跨 Controller、Service 和 Mapper 层追踪请求、定位异常根因、检查 SQL 执行或参数流转，以及生成简洁的诊断结论与修复方案。
- 务必确保每个参与协作的线程，在逻辑完成（无论成功或失败）后都执行
countDown() - 推荐写法：在
finally块中调用countDown()，避免因异常跳过 - 不要在子线程中多次调用
countDown()——计数器只减不增，多调一次可能导致主线程提前唤醒，引发竞态
CountDownLatch 和 join() 的关键区别在哪
join() 是 Thread 级等待，只能等特定线程结束；CountDownLatch 是逻辑级等待，不绑定具体线程对象，只要凑够 N 次 countDown() 就行。这意味着你可以跨线程池、跨 Runnable、甚至混合使用不同来源的任务。
使用场景差异：
- 用
join()：你手动生成并持有Thread对象，且只等它；适合简单脚本式多线程 - 用
CountDownLatch：任务提交给ExecutorService，你拿不到具体Thread引用；或需要“任意 N 个任务完成即可”，而非固定那几个线程 - 兼容性影响：JDK 1.5+ 支持
CountDownLatch，而join()一直存在；但CountDownLatch不能替代join()的中断响应能力（await(long, TimeUnit)可响应中断，join(long)不可）
别把 CountDownLatch 当成可重用的同步器
CountDownLatch 是一次性用品。一旦计数器归零，所有后续 await() 调用都会立即返回，countDown() 也不再有效。想重复使用？不行。Java 没提供 reset 方法，这是设计使然。
容易踩的坑：
- 在循环中复用同一个
CountDownLatch实例，第二次await()不阻塞，导致逻辑错乱 - 误以为
await()返回后还能再次等待，结果发现“什么都没等就往下走了” - 替代方案：需要重复等待，改用
CyclicBarrier；需要条件触发，考虑Phaser或CompletableFuture
真正难处理的是“部分失败仍要 countDown”的边界逻辑——比如 10 个任务，3 个抛异常退出，剩下 7 个正常完成。这时候你得确保异常路径也调用了 countDown()，否则主线程永远卡住。这点很容易被忽略，调试时又难复现。
