countdownlatch本质是基于aqs共享模式的“状态驱动批量唤醒”机制：state归零为唯一触发点，不可重置、不感知线程身份；tryacquireshared返回1或-1严格遵循aqs语义，仅state==0时返回1以触发全量唤醒；countdown通过循环cas确保递减原子性，仅最后一次从1→0的cas返回true并唤醒所有等待线程。
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）。
