countdownlatch 是一次性同步工具，state 归零后永久锁定，不可重置；其设计契约保障“等待一批操作完成”场景的语义清晰与线程安全，需重复使用时应换用 cyclicbarrier、新建实例或 completablefuture.allof。
因为它的设计就是“只响一次的闹钟”——计数归零后，状态永久锁定，没有重置入口，也不该有。
底层机制决定它无法回头
CountDownLatch 内部靠一个 state 变量（AQS 的共享状态）做倒计时。构造时设为 N，每次 countDown() 都用 CAS 原子递减；一旦减到 0，所有阻塞在 await() 的线程立刻被唤醒，且 state 永远停在 0。
- 没有 reset 方法，JDK 源码里也完全没提供任何重置逻辑
- 后续再调
await()，直接判断 state == 0 就立即返回，看似“没卡住”，实则是“已过期” - 这不是 bug，是明确的设计契约：终止态不可逆
一次性语义保障逻辑清晰
它解决的是“等待一批事做完就走”的问题，比如：
- 主线程等 5 个初始化任务全部完成，才启动主流程
- 服务关闭时，等所有清理线程退出后再真正停机
这类场景天然不需要“再来一遍”。如果硬要复用，等于把“完成信号”变成“可撤销承诺”，反而让协作关系模糊、出错时难以诊断。
强行重置会破坏线程安全
假设开放 reset 接口，就会面临这些现实难题：
- 有线程正卡在
await()等待，此时 reset —— 它该继续等？还是中断？行为不确定 - 多个线程同时调
countDown()和假想的reset()，需额外锁或复杂状态机，违背轻量同步工具的定位 - state 从 0 被强行拉回 N，但已有线程因上次归零被唤醒并继续执行了，新旧轮次混在一起，数据可能错乱
需要重复等待？换工具，不是修它
这不是功能缺陷，而是职责划分：
- 用 CyclicBarrier：适合固定数量线程反复“齐步走”，比如每轮采集 → 计算 → 汇总 → 下一轮
- 每次新建 CountDownLatch：简单干净，适用于批次独立的场景（如循环发 HTTP 请求并等全部返回）
- 用 CompletableFuture.allOf()：函数式风格，天然支持异常传播与链式后续动作
