AQS共享模式解析：CountDownLatch同步原理

本文深入剖析了CountDownLatch基于AQS共享模式的核心同步机制：await()通过tryAcquireShared非阻塞查状态，state不为0时线程即入CLH队列并park等待；countDown()则依赖volatile+无限CAS循环确保计数递减的绝对原子性；其不可重置的本质在于state归零后AQS拒绝任何修改，与CyclicBarrier基于可重置count和Condition的设计形成根本区别；同时澄清了超时await的语义——仅放弃本次等待、不改变状态、不退出队列逻辑，真正可靠的协作需结合中断或返回值判断，为高并发任务对齐场景提供了底层原理支撑与选型指引。

CountDownLatch 的 await() 为什么阻塞在 AQS 共享队列里

因为 await() 调用的是 acquireSharedInterruptibly(1)，而 AQS 在共享模式下会先执行 tryAcquireShared(int) ——这个方法只做一件事：return (getState() == 0) ? 1 : -1。只要 state != 0，就返回 -1，触发线程入队并 park。

关键点在于：它不抢锁，也不修改 state，纯粹是“查状态 + 等通知”。所有调用 await() 的线程都会被封装成 Node 加入 CLH 双向同步队列，头结点是虚拟节点，后续节点按 FIFO 排队。

• 不是 wait/notify 那种依赖对象监视器的机制，不会丢唤醒
• 阻塞由 LockSupport.park() 完成，unpark() 可提前发放许可，无时序风险
• 一旦 state 归零，doReleaseShared() 会遍历队列，挨个 unpark() 所有等待节点

countDown() 如何通过 CAS 保证 state 递减的原子性

countDown() 最终调用 tryReleaseShared(1)，核心逻辑是一个无限 for 循环 + compareAndSetState(c, nextc)：

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

这里没有锁，全靠 volatile + CAS。每次读取当前 state，计算新值，再尝试原子更新。失败就重试，直到成功。

• 多个线程并发调用 countDown() 不会导致计数丢失，这是 CountDownLatch 可靠性的底层保障
• 只有最后一次将 state 减到 0 的线程，才会返回 true，从而触发 doReleaseShared() 唤醒全部等待者
• 注意：state 是 int 类型，理论最大值 2^31−1，但实际业务中极少接近溢出，不过若误用（如反复 new 而非复用）可能掩盖计数异常

为什么 CountDownLatch 无法重置，而 CyclicBarrier 可以

根本差异就在 AQS 的复用设计上：CountDownLatch 的 state 是一次性消耗品，归零后 tryAcquireShared() 永远返回 1，await() 不再阻塞；但它的 tryReleaseShared() 在 state == 0 时直接返回 false，拒绝任何后续 countDown() 修改 —— 也就是“锁死了”。

• CyclicBarrier 不基于 AQS 的 state 做倒计时，而是用独立的 int count + ReentrantLock + Condition 实现，reset() 就是重置 count 和 trip 条件队列
• 想让 CountDownLatch “复用”，只能 new 新实例，但要注意旧实例的 await 线程是否已全部唤醒，否则可能引发 NPE 或逻辑错乱
• 生产环境若需循环等待，优先选 CyclicBarrier 或 Phaser，别 hack CountDownLatch

任务对齐场景下，await() 超时判断的实际意义

await(long, TimeUnit) 底层调用 tryAcquireSharedNanos(1, nanosTimeout)，本质是带超时的自旋 + park。它不是简单地 sleep 后检查，而是：

• 先尝试快速获取（即检查 state == 0），成功则立即返回
• 失败则计算 deadline，进入带超时的 park，期间仍可能被其他线程 countDown() 唤醒
• 若超时未唤醒，返回 false，但此时线程已脱离 AQS 队列，后续再调用 await() 会重新入队 —— 这点常被忽略

也就是说，超时不是“放弃等待”，而是“本次放弃”，不改变内部状态，也不影响其他线程继续 countDown()。真正要中断等待逻辑，得配合 Thread.interrupt() 或显式判断返回值。

本篇关于《AQS共享模式解析：CountDownLatch同步原理》的介绍就到此结束啦，但是学无止境，想要了解学习更多关于文章的相关知识，请关注golang学习网公众号！