CountDownLatch的await()阻塞在AQS共享队列中，因tryAcquireShared返回-1导致线程入队并park；countDown()通过CAS循环确保state递减原子性；其不可重置源于state归零后拒绝修改，而CyclicBarrier基于可重置的count和Condition实现。
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() 或显式判断返回值。
