AQS共享模式源码解析CountDownLatch逻辑

CountDownLatch 的核心并非简单的线程计数协调，而是基于 AQS 共享模式构建的“状态驱动批量唤醒”机制——它极度简洁而严谨：state 归零是唯一且不可逆的触发点，不区分线程身份、无视中间状态、拒绝重置；await 线程一旦挂起便彻底“失联”，对 countDown 的每一次递减都毫无感知，唯有最后一次将 state 从 1 原子变为 0 的 CAS 成功时，才瞬间唤醒所有等待者；这种设计剔除了所有模糊性与竞态风险，但也意味着任何依赖中间值的逻辑（如 state == 3 时通知）必须另寻他法——理解这一点，才能真正避开使用陷阱，用对这个看似简单却暗藏精妙的设计。

CountDownLatch 的“对齐”本质不是协调线程进度，而是用 AQS 共享模式实现「状态驱动的批量唤醒」——state 归零是唯一触发点，没有中间态、不可重置、不感知线程身份。

tryAcquireShared 返回值为什么只能是 1 或 -1？

因为 AQS 共享模式对 tryAcquireShared 的语义有硬性约定：返回值 0 才会尝试唤醒后继节点。
CountDownLatch 的实现是：return (getState() == 0) ? 1 : -1。
这意味着：

• state != 0 → 直接返回 -1，当前线程必然进等待队列
• state == 0 → 返回 1，AQS 会调用 setHeadAndPropagate 尝试向后传播唤醒（即唤醒所有排队线程）
• 它不关心“谁在等”“等了多久”，只认 state 值；哪怕 100 个线程在 await，只要 state 变 0，全部被释放

countDown 中的 compareAndSetState 为什么必须循环 + CAS？

因为 countDown 是多线程并发调用的，而 state 递减必须原子、无丢失。直接写 setState(getState() - 1) 会出竞态：
两个线程同时读到 state = 2，都算出 nextc = 1，先后写入，结果 state 只减了 1 而非 2。

源码里是这个结构：

for (;;) {
  int c = getState();
  if (c == 0) return false;
  int nextc = c - 1;
  if (compareAndSetState(c, nextc)) return nextc == 0;
}

• 循环确保重试直到 CAS 成功
• return nextc == 0 是关键：仅当本次 CAS 把 state 从 1 变成 0 时才返回 true，触发 AQS 唤醒全部等待者
• 如果 state 是 5，前四次 countDown 都返回 false，不唤醒；第五次才返回 true，一次性全放行

await 不会响应 countDown 的“中间过程”，只响应最终归零

这是最容易误解的一点。很多开发者以为「每调一次 countDown，await 就少等一个线程」，其实完全不是：

• await 调用后，线程立刻进入 AQS 同步队列，挂起，不再轮询 state
• 期间无论 countDown 被调多少次、state 从 8→7→5→2，await 线程都毫无感知
• 只有最后一次把 state 从 1→0 的那个 CAS 成功，才会触发 AQS 唤醒队列中所有节点
• 所以“多任务对齐”其实是「所有 await 线程集体卡在同一个门后，直到最后一块砖砌完，整扇门才弹开」

真正难处理的不是逻辑本身，而是误以为可以靠 state 中间值做条件判断 —— 比如想在 state == 3 时提前通知某模块，这是做不到的；CountDownLatch 只暴露两个确定事件：await 阻塞、state 归零唤醒。任何中间状态都需要额外机制（比如 Phaser 或手动维护 volatile 计数器 + LockSupport.unpark）。

今天关于《AQS共享模式源码解析CountDownLatch逻辑》的内容介绍就到此结束，如果有什么疑问或者建议，可以在golang学习网公众号下多多回复交流；文中若有不正之处，也希望回复留言以告知！