countDown()必须在子任务逻辑执行完毕后调用，即run()/call()最后一行代码执行完或异常被捕获处理后；若含异步回调则须在回调内调用，且catch块中也需调用，确保精确匹配初始化次数，不可逆、无锁、轻量。
countDown() 必须在子任务真正结束之后调用
很多人误以为只要启动了子线程就该立刻 countDown()，结果 CountDownLatch.await() 提前返回，主流程拿到的是未完成的数据。关键在于：倒计数触发时机必须与「任务逻辑执行完毕」严格对齐，不是线程启动、也不是 submit() 返回，而是 run() 或 call() 执行完最后一行代码（或异常抛出后被正确捕获处理）。
常见错误现象：await() 返回了，但子任务的数据库写入还没刷盘、文件还没 close、HTTP 响应体还没解析完。
- 使用
ExecutorService时，在Runnable.run()结尾或Callable.call()return 前调用countDown() - 若子任务含异步回调（如 Netty 的
ChannelFuture.addListener()），countDown()必须放在回调内部，不能放在线程提交处 - 遇到异常时，务必在
catch块里也调用countDown()，否则门闩永远无法打开
多个子任务共用一个 CountDownLatch 时，countDown() 调用次数必须精确匹配初始化值
初始化时传入 n，就必须且仅能成功调用 n 次 countDown()。少一次，await() 死等；多一次，虽不报错但语义错误——后续等待者可能误判所有任务已完成。
使用场景：并行拉取 3 个 API，初始化 new CountDownLatch(3)，每个 HTTP 请求回调里各调一次 countDown()。
- 不要在循环外统一调用，比如「for 循环 submit 10 个任务后，外面调一次
countDown()」——这等于只计 1 次 - 避免在 finally 块无条件调用多次（例如嵌套 try-finally 或重复 catch）
- 可配合原子计数器（如
AtomicInteger）做日志调试：每次countDown()前打印当前剩余值，确认递减节奏
countDown() 是无锁、轻量、不可逆的操作
countDown() 底层基于 AQS 的 state 变更，不阻塞、不加锁、不抛异常，即使在中断状态下也能成功执行。但它不可逆：一旦 state 减到 0，再调用 countDown() 不会报错，但也不改变状态，后续 await() 会立即返回。
性能影响极小，单次调用耗时通常在纳秒级；但滥用（如在高频循环里误用）可能掩盖逻辑错误。
- 它不关心调用线程身份，任意线程都可调用 —— 这是它适合协调异步任务的关键
- 没有「重置」能力，state=0 后不能恢复，需要重用请换
CyclicBarrier或新建实例 - 如果子任务本身是短生命周期的（如毫秒级计算），
countDown()的开销基本可忽略，无需优化
和 await() 配合时，别忽略中断和超时参数
countDown() 只管减数，开门动作由 await() 完成。但若主流程没设防，可能无限等待或忽略中断信号。
错误写法：latch.await() —— 一旦某个子任务卡死或漏调 countDown()，主线程永久挂起。
- 始终优先用带超时的
await(long timeout, TimeUnit unit)，比如latch.await(30, TimeUnit.SECONDS) - 检查返回值：返回
false表示超时，此时需主动清理资源（如 cancel 未完成的Future） - 若业务允许响应中断，捕获
InterruptedException后应恢复中断状态（Thread.currentThread().interrupt()），而非吞掉
最常被忽略的一点：countDown() 成功不代表子任务结果可用——它只表示「执行流程结束了」。结果是否正确、是否为空、是否含异常，得靠额外机制（如 Future.get()、共享变量 + volatile、回调参数）来传递。
