await()是“等归零才放行”，countDown()是“减一不唤醒，直到归零才批量通知”；前者检查state是否为0决定是否入队挂起，后者通过CAS递减并在state变为0时广播唤醒所有await线程。

await() 是“等归零才放行”，countDown() 是“减一不唤醒，直到归零才批量通知”——这是区分两者底层行为最核心的一句话。

await() 的本质：共享模式下的条件等待

调用 await() 的线程不会立刻执行，而是检查内部计数器 state 是否为 0：

• 如果 state == 0，直接通过，不入队
• 如果 state > 0，则基于 AQS（AbstractQueuedSynchronizer）以共享模式加入同步等待队列，挂起线程
• 它不争抢锁，也不修改 state，只是“守着门看数字”
• 多个线程同时 await()，会全部排队，但共用同一把共享锁

countDown() 的本质：原子减一 + 归零时触发唤醒

每次调用 countDown() 都尝试对 state 做一次 CAS 原子递减：

• state > 0 时：成功减一，但不唤醒任何线程
• state == 1 时：减为 0，此时才真正触发“释放共享资源”逻辑
• 一旦 state 变为 0，AQS 会遍历整个等待队列，将所有因 await() 而阻塞的线程一次性唤醒
• 注意：countDown() 可被任意线程多次调用，甚至同一线程重复调用，只要没超初始值，都有效

关键细节：为什么不是“减一就唤醒一个”？

CountDownLatch 的设计目标是“等全部完成”，不是“逐个放行”：

• 它没有“许可池”概念，不像 Semaphore 那样可增可减、按需分配
• 它的 state 是一次性消耗型计数器，归零即终态，不可重置（reset）
• 唤醒动作只在 state 从 1→0 这一刻发生，且是广播式唤醒全部 await 线程，不是点对点通知

一个小例子帮你印证

设 CountDownLatch latch = new CountDownLatch(3)：

• 线程 A、B、C 同时调用 latch.await() → 全部入 AQS 队列挂起
• 线程 D 调用一次 countDown() → state 变为 2，无唤醒
• 线程 E 再调用一次 countDown() → state 变为 1，仍无唤醒
• 线程 F 第三次调用 countDown() → state 变为 0，AQS 立即唤醒 A、B、C 三个线程