CountDownLatch的await()不抢锁而等计数归零，因其基于AQS共享模式，tryAcquireShared()仅检查state是否为0；countDown()用CAS确保减一原子性；不可重用因state归零后无重置机制；中断await()不影响state。
CountDownLatch 的 await() 为什么阻塞后不“抢锁”而是等计数归零
因为 await() 调用的是 AQS 的 acquireSharedInterruptibly()，而底层 tryAcquireShared() 的逻辑极其简单：只看 state 是否为 0。不为 0 就返回 -1，AQS 自动把线程塞进 CLH 队列挂起；为 0 就返回 1，直接放行。它根本不是在“争抢某个资源”，而是在“查状态快照”——这正是同步屏障（barrier）的本质：不竞争，只对齐。
常见错误是误以为 await() 类似 ReentrantLock.lock()，需要唤醒后重新竞争。实际没有竞争过程：一旦 countDown() 把 state 减到 0，AQS 会调用 doReleaseShared() 唤醒所有在队列里等待的节点，且这些线程被唤醒后不再检查条件，直接继续执行 —— 因为条件（state == 0）已在唤醒前由最后一个 countDown() 保证成立。
countDown() 的 CAS 自旋为何必须用 compareAndSetState
countDown() 底层走 releaseShared() → tryReleaseShared()，后者用死循环 + compareAndSetState() 实现减一。这不是为了“重试失败”，而是确保：即使多个线程同时调用 countDown()，也只有一个能成功把 state 从 N 减为 N−1，避免漏减或重复减。
容易踩的坑：
- 手写类似逻辑时用
getState() - 1再setState()，会导致竞态条件 —— 两个线程读到相同state，都算出新值，先后写入，实际只减了一次 - 没加 volatile 语义（AQS 的
state是 volatile int），可能因 CPU 缓存不一致导致某线程永远看不到state == 0 - 忽略返回值：只有当
compareAndSetState(old, new)成功时才表示本次减一真正生效，这也是判断是否该触发唤醒的唯一依据
为什么 CountDownLatch 不可重用，而 CyclicBarrier 可以
关键在状态机设计：CountDownLatch 的 state 归零后，tryAcquireShared() 永远返回 1，后续所有 await() 都直接通过；但它的 Sync 类没有提供重置 state 的 public 方法，也不响应任何 reset 请求 —— 这是故意的不可逆设计。
对比 CyclicBarrier：它内部有 Generation 对象标记“代”，每次所有线程通过屏障后，nextGeneration() 会新建一代、重置计数、并调用 Condition.signalAll() 唤醒等待者。而 CountDownLatch 根本不维护“代”概念，也没有 Condition 实例，它的唤醒靠的是 AQS 共享模式下的 unparkSuccessor() 直接操作队列节点。
所以如果你需要多次对齐（比如每秒一批任务），别硬复用 CountDownLatch，要么重建实例，要么换 CyclicBarrier 或 Phaser。
多任务对齐场景下，主线程 await() 被中断时 state 状态怎么变
await() 响应中断，抛出 InterruptedException，但此时 state 完全不受影响 —— 既不会回滚，也不会被设为 0。中断只是让当前线程退出等待队列，不改变屏障本身的进度。
这意味着：
- 其他未中断的线程仍按原逻辑等待，直到
state归零 - 被中断的线程若想重试，必须自己捕获异常后重新调用
await()，但要注意：如果此时state已为 0，await()会立即返回，无需再等 - 没有“中断即失效”机制，所以业务代码里不能假设“中断 = 屏障失败”，得结合实际
state值或完成标志做二次判断
最易忽略的一点：很多生产代码在 catch(InterruptedException) 后直接 return，却忘了恢复中断状态（Thread.currentThread().interrupt()），导致上层调用方收不到中断信号，引发超时或 hang 住。
