CountDownLatch 初始化时count值错误会导致await永久阻塞；必须确保count等于实际countDown调用次数，避免遗漏异常路径或线程池中调用时机错位，且不可重用。

CountDownLatch 初始化时 count 值设错会导致 await 永久阻塞

初始化 CountDownLatch 时传入的 count 必须等于预期调用 countDown() 的总次数，否则 await() 可能永远不返回。常见错误是把线程数当成 count，却漏掉了主线程或某些分支路径未调用 countDown()。

实操建议：

• 在创建前明确「谁负责倒计时」：通常是每个工作线程完成时调用一次 countDown()，主线程调用 await()
• 避免在异常路径中遗漏 countDown()，推荐用 try-finally 包裹
• 调试时可临时加日志：在每次 countDown() 前打印当前线程名和剩余计数（通过 getCount()）

await() 被中断时会抛出 InterruptedException，必须处理

await() 是可中断的阻塞方法，如果等待期间线程被中断，会立即抛出 InterruptedException 并清空中断状态。不捕获该异常会导致程序意外终止，或掩盖真正的中断意图。

实操建议：

• 不要简单吞掉异常，至少恢复中断状态：Thread.currentThread().interrupt()
• 若业务允许超时等待，优先用带超时的 await(long timeout, TimeUnit unit)，返回 false 表示超时而非中断
• 在 catch 块里不要直接 return，除非你确认可以放弃后续逻辑

CountDownLatch 无法重用，重复 await 会一直阻塞

CountDownLatch 是一次性同步器：一旦 count 减到 0，所有后续 await() 调用都会立即返回；但若还没归零就重复调用 await()，后调用者仍会阻塞——这不是 bug，是设计使然。误以为它像 CyclicBarrier 那样可重置，就会卡住。

实操建议：

• 需要多次同步场景（如循环任务），改用 CyclicBarrier 或每次新建 CountDownLatch
• 若用新建方式，注意对象创建开销极小，无需池化或复用实例
• 检查是否无意中在循环内多次调用同一实例的 await()，尤其在 while 或递归逻辑中

与线程池配合时，务必确保 countDown 在任务真正完成时调用

用 ExecutorService 提交 Runnable 或 Callable 时，容易在提交后立刻 countDown()，而实际任务尚未执行。这会让 await() 提前返回，导致主线程误判为“全部完成”。

实操建议：

• countDown() 必须放在任务体内部，即 run() 或 call() 的末尾（或 finally 块）
• 不要在 submit() 返回的 Future 上做同步（如 get()），那会退化成串行；CountDownLatch 的价值正在于异步 + 等待
• 若任务本身有嵌套异步操作（如回调、CompletableFuture），需确保最内层完成时才触发 countDown()

最容易被忽略的是「异常路径下的 countDown 缺失」和「与线程池混用时的调用时机错位」——这两个点不出问题时一切正常，一出就是偶发、难复现的同步失败。