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 缺失」和「与线程池混用时的调用时机错位」——这两个点不出问题时一切正常，一出就是偶发、难复现的同步失败。
