CountDownLatch仅负责线程等待的时序协调，不控制并行度、不提供同步保护；它只确保所有工作线程调用countDown()后，等待线程才继续执行，但不保证内部线程安全。
CountDownLatch 本身不参与“并行与同步的权衡”设计——它不控制并行度，也不提供同步保护，只做一件事：让等待线程停在某个点，直到指定数量的完成信号全部到达。所谓“权衡”，其实是开发者在任务拆分、线程调度和结果协调层面做的决策，CountDownLatch 只是忠实执行这个逻辑的“门闩”。
明确职责边界：它不并行，也不同步
CountDownLatch 不创建线程、不分配任务、不保护共享变量。它只是配合已有并发结构工作的协调器：
- 并行由线程池或显式 new Thread() 实现，不是 CountDownLatch 的责任
- 数据同步（如 List.add()）需额外加锁或用线程安全容器，CountDownLatch 不提供任何内存可见性保障
- 它只保证“时间上的先后顺序”：所有工作线程 已执行完 countDown()，等待线程才继续——但不保证这些工作线程内部是否线程安全
真正需要权衡的三个关键点
用得好不好，取决于你如何设计任务划分与异常处理：
- 任务粒度与线程数匹配：启动 100 个线程处理 100 条记录，就 new CountDownLatch(100)；若用固定大小线程池（比如 core=4），则计数器应设为实际提交的任务数，而非线程数
- countDown() 必须在 finally 中调用：哪怕任务抛异常、超时中断、甚至 return 早于预期，也要确保计数器被减。漏调一次，await() 就卡死
- 超时设置要贴合业务容忍度：批量查询等 IO 密集型任务，建议设为 P95 延迟 × 1.5；用户请求链路中同步等待，通常不超过 800ms，超时后应降级而非重试
典型误用：把门闩当锁用
常见错误是混淆职责，导致逻辑脆弱或假成功：
立即学习“Java免费学习笔记（深入）”；
- 在同一个线程里既 await() 又 countDown()：破坏“等待方 vs 执行方”的角色分离，容易引发死锁或提前释放
- 用完后试图 reset 或重复 await()：计数归零后 await() 立即返回，看似“成功”，实则掩盖了后续任务未执行的问题
- 把 latch 当状态标志反复使用：比如循环中每次都 new 同一个 latch 对象但没重置——这是设计错位，该换 CyclicBarrier 或 CompletableFuture
推荐组合模式：Latch + 安全容器 + 超时判断
一个健壮的并行汇总流程，通常这样组织：
- 用 ConcurrentHashMap 或 CopyOnWriteArrayList 收集各线程结果（解决同步问题）
- 每个工作线程在 try-finally 块末尾调用 latch.countDown()（保障计数可靠）
- 主线程用 latch.await(5, SECONDS)，超时则检查收集容器大小、记录告警、走备用逻辑（避免雪崩）
