CountDownLatch初始化count为0会导致await()立即返回、countDown()无效，引发静默失败；await()须在协调线程调用，countDown()须在每个子任务的finally中执行；超时后latch不可重用，需手动处理超时逻辑；它不传递结果或异常，须配合Future等机制使用。
CountDownLatch 初始化时 count 值必须大于 0
如果传入 0，构造函数不会报错，但后续调用 await() 会立即返回，countDown() 也无效——这常导致“协作逻辑看似执行了，实则没等任何线程”的静默失败。
典型误用场景：动态计算任务数但结果为 0（比如空集合遍历），却仍创建 new CountDownLatch(0)。应提前校验：
int taskCount = tasks.size();
if (taskCount == 0) {
// 直接执行后续逻辑，或抛异常提示
return;
}
CountDownLatch latch = new CountDownLatch(taskCount);
await() 调用位置决定谁在等待、等什么
await() 必须在「需要被所有子任务触发后才继续执行」的线程中调用，通常是主线程或协调线程；而 countDown() 应在每个子任务完成时调用（无论成功或异常）。
常见错误包括：
立即学习“Java免费学习笔记（深入）”；
- 在子线程里调用
await()—— 导致子线程自己卡住，无法触发计数 - 只在 try 块里调用
countDown()，忽略 catch/finally —— 异常时漏减，latch 永不释放 - 多个线程重复调用
countDown()同一实例多次 —— 计数过早归零，破坏协作语义
正确写法示例（确保 finally 中扣减）：
executor.submit(() -> {
try {
doWork();
} finally {
latch.countDown(); // 即使抛异常也要执行
}
});
await() 支持超时但不自动重试，需手动处理超时逻辑
await(long timeout, TimeUnit unit) 返回 boolean：true 表示计数归零，false 表示超时。它不会抛出异常，也不会重试，更不会自动恢复状态。
这意味着：
- 超时后
latch仍处于未完成状态，后续再调用await()还会阻塞（除非已有其他线程继续countDown()） - 业务上需明确超时后的动作：是取消剩余任务？记录告警？还是降级处理？
- 不能依赖超时来“重置”latch——
CountDownLatch不可重用，超时后只能废弃
例如：
if (!latch.await(10, TimeUnit.SECONDS)) {
log.warn("Tasks timed out, proceeding with partial result");
cancelPendingTasks(); // 需自行实现
}
CountDownLatch 不传递结果，也不感知异常，需配合其他机制
它只解决“等待全部完成”的同步问题，不处理子任务的返回值或异常传播。若需收集结果或统一异常处理，必须额外组合：
- 用
Future<?>包裹每个任务，通过executor.invokeAll()或逐个get()获取结果 - 用
ThreadLocal或共享容器（如ConcurrentHashMap）暂存各线程结果，但要注意线程安全 - 异常不能靠 latch 捕获，必须在子任务内部 try-catch 并显式记录或抛给上层
一个轻量组合示例：
List<Future<String>> futures = new ArrayList<>();
for (Runnable task : tasks) {
futures.add(executor.submit(() -> {
try { return doWork(); }
catch (Exception e) { errors.add(e); return null; }
}));
}
latch.await(); // 等所有 submit 完成（注意：不是等 Future 完成）
// 再遍历 futures.get() 拿结果
真正容易被忽略的是：latch 的语义是“门栓”，一旦打开就不可逆；它不关心内容，只管数量。如果你需要结果、异常、重试或重用，得立刻想到它只是拼图的一块，而不是整幅画。 
