AQS共享模式：CountDownLatch与Semaphore对比解析

CountDownLatch和Semaphore虽用途迥异——前者用于等待事件完成，后者用于控制并发访问——却都精巧复用AQS的共享模式底层机制：二者统一通过tryAcquireShared判断放行条件、共用releaseShared触发唤醒传播，仅在state语义上截然相反（倒计时递减 vs 许可数增减），并依赖Node.SHARED标记激活共享唤醒链；理解这一“同构异义”的设计，不仅能穿透表层API看清同步本质，更能避开手写同步器时因忽略模式标记或误读state语义而导致的隐蔽死锁与唤醒失效陷阱。

CountDownLatch 和 Semaphore 都用 tryAcquireShared 判断能否放行

它们不是“各自发明一套逻辑”，而是统一走 AQS 共享模式的入口：acquireShared → 调用子类重写的 tryAcquireShared。这个方法返回值直接决定线程是立刻放行、入队等待，还是需要触发后续唤醒。

关键区别在语义：

• CountDownLatch 的 tryAcquireShared 只看 state == 0：等于 0 返回 1（正数），表示“可以放行，且之后无需再传播”；否则返回 -1（负数），必须排队
• Semaphore 的 tryAcquireShared 看的是剩余许可数：比如还有 2 个许可，就返回 2（正数），不仅当前线程能过，还暗示“后面可能还能过好几个”，从而触发 propagate

所以别被名字骗了——CountDownLatch.await() 不是在“等一个事件”，而是在“尝试以共享方式获取 state==0 这个状态”。

释放操作都靠 tryReleaseShared + doReleaseShared 传播唤醒

两者 countDown() 和 release() 最终都调用 releaseShared(1)，流程一致：

• 先执行子类的 tryReleaseShared：对 CountDownLatch 是把 state 减 1；对 Semaphore 是把 state 加 1（注意：它的 state 表示“可用许可数”，和 CountDownLatch 的“剩余倒计时”方向相反）
• 只要 tryReleaseShared 返回 true，就进 doReleaseShared —— 这里才是共享模式的精髓：不是只唤醒头节点后继，而是循环唤醒，直到传播中断（比如 state 归零或队列空）

这就是为什么 Semaphore.release() 一次能唤醒多个等待线程，而 CountDownLatch.countDown() 在倒计时未归零时，唤醒行为“看似没效果”——其实它真唤醒了，只是被 tryAcquireShared 拦在了第二道门。

state 含义相反但结构完全复用

AQS 的 state 就是个 int，怎么解释全看子类。这点容易踩坑：

• CountDownLatch：初始 state = N，每次 countDown() 做 state--，await() 成功条件是 state == 0
• Semaphore（非公平）：初始 state = permits，每次 acquire() 做 state--，release() 做 state++，acquire() 成功条件是 state > 0

表面看都是“减到 0 就完事”，但实际：一个靠耗尽计数达成终点，一个靠预留资源支撑并发。强行统一理解会混淆语义，但底层复用 AQS 的 CAS 更新、队列管理、唤醒传播，确实省掉大量重复代码。

别忽略 Node.SHARED 这个标记节点类型的关键字

两个类在入队时都用 addWaiter(Node.SHARED)，而不是 Node.EXCLUSIVE。这是 AQS 区分模式的开关：

• 节点标记为 SHARED，意味着唤醒它时，要检查是否还能继续传播（即调用 tryAcquireShared 看是否仍可获取）
• 如果误用 EXCLUSIVE，哪怕逻辑写对，doReleaseShared 也不会触发后续传播，所有排队线程将永远卡住
• 这个标记藏在 addWaiter 内部，不暴露给用户，但它是共享模式生效的基础设施层前提

真正难调试的并发问题，往往不是逻辑错，而是某处隐式依赖了 SHARED 语义却没满足——比如自己手写同步器时忘了传这个 mode。

理论要掌握，实操不能落！以上关于《AQS共享模式：CountDownLatch与Semaphore对比解析》的详细介绍，大家都掌握了吧！如果想要继续提升自己的能力，那么就来关注golang学习网公众号吧！