面试官问“Semaphore 凭什么靠 AQS CAS 实现限流”的时候其实不是想听你背 API。他真正想确认的是你能不能把一个并发工具拆到线程调度层看懂它和 AQS、CAS 之间的关系。很多人张口就说“Semaphore 是信号量用来限流”但一追问 state、自旋、队列、公平锁就接不住。这篇文章我把 Semaphore 从用法到源码再到实际限流场景一次讲透。无论你是准备面试还是正在用 Semaphore 保护你的接口都能从这里拿到能直接用的东西。1. Semaphore 到底是什么1.1 信号量模型一张许可证计数器Semaphore 翻译成中文是“信号量”它维护一组“许可证permits”。你可以在初始化时指定最多允许多少个许可证比如new Semaphore(5)表示最多允许 5 个线程同时通过。每个线程进入临界区前要先acquire()领一张许可证离开前必须release()把许可证还回去。如果当前许可证数量已经是 0后来的线程就只能阻塞等待直到有人释放。这个模型和锁有一个本质区别普通锁比如 synchronized 或 ReentrantLock是“同一时刻只能一个线程进”信号量是“同一时刻最多 N 个线程进”。你可以把 Semaphore 想象成一个商场门口的入场计数器进去一个人数字减 1出来一个人数字加 1计数器归零后门就暂时关闭外面的人需要排队。这套模型天然适合做限流但它限的不是“每秒请求数QPS”而是“并发访问数并发线程数”。这两个概念在面试里经常被混为一谈后面我单独说。1.2 它解决什么问题Semaphore 主要解决“多个资源、有限数量”的分配问题。最典型的场景是数据库连接池连接数是有限的如果一百个线程同时去拿连接不能全部放进来否则连接池直接崩。用一个Semaphore(10)就能控制同时最多 10 个线程拿到连接其余线程在入口排队。再比如调用一个第三方 API对方只允许 20 个并发请求。你在客户端封装一个Semaphore(20)所有请求先 acquire 再发 HTTP返回后 release就能优雅地保护调用方不超限。这类场景遍布日常开发限流、连接池、批量任务并发控制、甚至游戏服务器里的房间容量管理。面试时提到 Semaphore最好直接说它是基于计数的共享锁适用于“有限资源池”的并发访问控制而不是做 QPS 限流。这样一句话能瞬间拉开你和背书选手的差距。2. 从 API 用法看设计意图2.1 acquire 和 release 必须配对先看一个最基础的使用示例Semaphore semaphore new Semaphore(5); for (int i 0; i 20; i) { int taskId i; new Thread(() - { try { semaphore.acquire(); System.out.println(任务 taskId 开始执行); Thread.sleep(1000); } catch (InterruptedException e) { Thread.currentThread().interrupt(); } finally { semaphore.release(); } }).start(); }这里有 5 个许可证20 个线程竞争所以同一时刻最多只有 5 个线程进入临界区。很多人写代码只记得 acquire忘记在 finally 里 release。一旦某个线程在临界区抛异常许可证不会自动归还后面的线程会越积越多最终全部卡死。这就是信号量泄漏线上事故高发点。acquire 方法还有一个可中断版本acquireInterruptibly()以及不阻塞的tryAcquire()。实际业务里我更推荐用 tryAcquire 加超时时间比如if (semaphore.tryAcquire(2, TimeUnit.SECONDS)) { try { // 业务逻辑 } finally { semaphore.release(); } } else { // 快速失败避免线程无限等待 System.out.println(系统繁忙请稍后再试); }这样既能利用信号量限流又不会让线程在队列里一直傻等。2.2 公平模式与非公平模式的取舍Semaphore 构造器支持第二个参数new Semaphore(permits, fair)。默认是 false也就是非公平。非公平模式意味着新来的线程可以直接尝试 CAS 抢许可证不需要看队列里是否有人在等。公平模式则要求线程必须先检查同步队列里有没有前驱节点如果有就乖乖排队。非公平模式的优点是吞吐量通常更高因为可以减少线程挂起和唤醒的开销。但它有个明显问题极端情况下可能造成“饥饿”排队的线程迟迟拿不到许可证。公平模式能保证先来后到但代价是每次 acquire 都要额外判断一次队首状态性能略低。日常开发里如果只是做流量保护用非公平就够了。如果你在做一个对公平性有要求的资源分配系统比如任务调度就需要开公平模式。但要注意公平模式并不是绝对公平它保证的是“入队顺序”而不是“请求时间顺序”。这个细节面试官很喜欢挖。3. AQS CAS 的底层协作机制3.1 CAS并发修改 state 的原子保证CAS 全称是 Compare And Swap翻译过来是“比较并交换”。它是一个 CPU 原子指令操作逻辑是比较某个内存位置的当前值是否等于预期值如果等于就把它更新成新值如果不等于什么都不做。整个比较和更新过程是原子的不会被线程调度打断。Semaphore 的许可证数量就存在 AQS 的 state 变量里。多个线程同时 acquire 时必须对 state 做“减 1”操作。如果用普通代码state--在并发环境下会因为“读-改-写”三步不是原子的导致数据错乱。CAS 正好解决这个问题int available getState(); int remaining available - acquires; if (remaining 0 || compareAndSetState(available, remaining)) { return remaining; }这里的compareAndSetState(available, remaining)就是 CAS只有当前 state 仍然是 available 时才会把它改成 remaining。如果这期间有其他线程抢先改了状态CAS 就失败然后整个逻辑进入下一轮自旋重试重新读取最新的 state 再试。这就是乐观锁的思路冲突发生时不去阻塞排队而是先尝试失败就再试。3.2 AQS同步队列的排队管理机制AQSAbstractQueuedSynchronizer是 Java 并发包的灵魂Semaphore、ReentrantLock、CountDownLatch 等很多工具都建立在它之上。AQS 的核心有两个部分一个 volatile 修饰的 int 类型 state以及一个 FIFO 的双向等待队列。state 用来表示资源状态具体含义由子类决定。在 Semaphore 里state 就是剩余的许可证数量。等待队列用来存放拿不到资源的线程队列节点里保存线程引用、等待状态等信息。当一个线程 acquire 失败就会被封装成 Node 节点挂到队列尾部然后通过LockSupport.park()挂起。前一个线程释放资源时再通过unpark()唤醒队首的后继节点。你可以把 AQS 理解成一个管理“排队和唤醒”的框架。子类只需要实现如何判断资源是否够tryAcquireShared以及如何归还资源tryReleaseShared剩下的排队、阻塞、唤醒逻辑都由 AQS 模板方法搞定。这就是为什么 Semaphore 的源码非常短核心逻辑全在 AQS 里。3.3 state 这个变量到底承担了什么state 是 AQS 里唯一用来表示“剩余资源”的变量所有并发控制都围绕它展开。因为是 volatile 修饰它在多线程之间具有可见性一个线程修改了 state另一个线程能立刻读到最新值。但这还不够volatile 只能保证可见性不能保证复合操作的原子性。所以 AQS 还提供了基于 CAS 的compareAndSetState方法。我们可以把 state 和 CAS 的关系总结成这样volatile 解决“看见最新值”CAS 解决“修改时不被插队”两者配合才能真正保证线程安全。这里有个容易忽略的点Semaphore 的 state 是通过setState(permits)初始化的后面 acquire 减少 staterelease 增加 state。如果初始 permits 太大了或者 release 次数过多state 可能会溢出变成负数。AQS 的 release 方法里专门做了溢出检查超过上限会抛出 Error。所以设计上许可证数量不能随意设置这点后面实战部分会说。4. 源码级拆解 Semaphore 的限流骨架4.1 acquire 的调用链我们直接看 Semaphore 源码。它内部有一个抽象静态类 Sync继承了 AbstractQueuedSynchronizer。外部 acquire 方法其实是在调用 AQS 的模板方法public void acquire() throws InterruptedException { sync.acquireSharedInterruptibly(1); }AQS 里的acquireSharedInterruptibly是这样处理的public final void acquireSharedInterruptibly(int arg) throws InterruptedException { if (Thread.interrupted()) throw new InterruptedException(); if (tryAcquireShared(arg) 0) doAcquireSharedInterruptibly(arg); }先判断线程是否已经被中断如果中断就抛异常。然后调用子类实现的tryAcquireShared(arg)尝试获取共享资源。如果返回值小于 0说明剩余许可证不够需要进入队列等待。这里的“共享”是和 ReentrantLock 的独占模式对应的概念许可可以由多个线程同时持有Semaphore 是典型的共享锁。4.2 tryAcquireShared 内部的 CAS 循环Semaphore 分公平版和非公平版两者的 tryAcquireShared 略有不同。非公平版的实现如下final int nonfairTryAcquireShared(int acquires) { for (;;) { int available getState(); int remaining available - acquires; if (remaining 0 || compareAndSetState(available, remaining)) return remaining; } }这是一个典型的 CAS 自旋循环。先读取当前的可用许可证数量减去需要的数量如果结果小于 0 就直接返回负数表示许可证不够如果结果大于等于 0就尝试通过 CAS 把 state 从 available 改成 remaining。CAS 成功则返回正数或 0表示成功拿到许可证。CAS 失败说明有其他线程抢先修改了 state于是一个 for 循环再读一次继续重试。公平版的核心差异在循环开头多了一个队列判断protected int tryAcquireShared(int acquires) { for (;;) { if (hasQueuedPredecessors()) return -1; int available getState(); int remaining available - acquires; if (remaining 0 || compareAndSetState(available, remaining)) return remaining; } }hasQueuedPredecessors()返回 true 说明等待队列里已经有排队的线程了为了保证公平新线程必须放弃抢购直接返回 -1 然后进入队列。没有前驱线程时才允许当前线程尝试 CAS 抢许可证。4.3 release 如何把许可证归还给队列释放许可证的方法在 Sync 里实现protected final boolean tryReleaseShared(int releases) { for (;;) { int current getState(); int next current releases; if (next current) throw new Error(Maximum permit count exceeded); if (compareAndSetState(current, next)) return true; } }同样是一个 CAS 自旋更新 state 的循环。这里有一个保护性判断如果加完之后的 next 比 current 还小说明 int 溢出了直接抛 Error。正常情况下不会走到这一步但如果你在代码里疯狂 release就可能触发。当tryReleaseShared返回 true 后AQS 的releaseShared会继续执行doReleaseShared()这个方法负责唤醒等待队列里的后继线程。也正是因为这一步被阻塞在 acquire 的线程才有机会被唤醒然后重新尝试获取许可证。release 的完整链路可以理解为先原子归还 state再通过 AQS 队列机制唤醒后继节点完成一次“许可交接”。4.4 可中断、超时与 tryAcquire 的实现差异Semaphore 提供了好几类获取方法面试里常被问到区别acquire()可被中断但无超时。如果一直拿不到许可证线程会一直阻塞。acquireUninterruptibly()不可中断即使线程被 interrupt 也会继续等待。tryAcquire()非阻塞尝试一次拿到返回 true拿不到立刻返回 false。tryAcquire(timeout, unit)带超时等待超时后放弃。acquire(permits)一次获取多个许可证对应释放时也要释放多个。带超时的 tryAcquire 底层会进入 AQS 的doAcquireSharedNanos方法里面用 CLH 队列加 LockSupport.parkNanos 实现限时等待。到时间后如果还没获取到就从队列中移除并返回 false。这个机制在保护线程不无限等待时很有用。5. 实际限流场景怎么用才不翻车5.1 用 Semaphore 控制接口并发数我用 Semaphore 做过一个比较典型的保护方案后端服务要调用一个第三方评分接口对方明确说“同一时刻最多 30 个并发”。我在服务内部定义了一个单例信号量private static final Semaphore THIRD_PARTY_LIMIT new Semaphore(30); public Score queryScore(String userId) { if (!THIRD_PARTY_LIMIT.tryAcquire(1, TimeUnit.SECONDS)) { throw new BizException(当前请求量过大请稍后重试); } try { return thirdPartyClient.query(userId); } finally { THIRD_PARTY_LIMIT.release(); } }tryAcquire 带 1 秒超时是为了避免线程在信号量队列里排队太久。如果下游已经拥堵后续请求快速失败返回而不是继续堆积。finally 里 release 是必须的这条我每次写代码都会刻意检查。这种做法的本质是“并发数限流”它保护的是下游系统不被同时打爆。但如果你要控制的是“每秒请求总数”Semaphore 做不到因为它不管请求耗时长短只关心同时在跑的线程数。5.2 Semaphore 和 QPS 限流器有什么不同这是面试里最容易踩坑的延伸题。很多人张口就说“我用 Semaphore 限流”面试官追问一句“你限的是什么流”就懵了。Semaphore 限的是并发数量比如同时最多 100 个线程在执行。如果每个请求耗时 10 毫秒QPS 可以达到 10000如果每个请求耗时 2 秒QPS 只有 50。所以 Semaphore 和系统吞吐量并没有直接对应关系。真正做 QPS 限流一般用令牌桶或者漏桶算法比如 Guava 的 RateLimiter或者 Alibaba Sentinel 里的流量控制。实际业务里两者往往结合使用Semaphore 保护“并发线程数”防止线程池打满RateLimiter 或 Sentinel 控制“请求速率”防止短时间流量洪峰。你可以跟面试官说信号量适合做资源隔离令牌桶适合做速率整形它们是不同维度的限流。5.3 踩坑清单我实际使用中积累了几个印象特别深的坑列出来给大家参考第一许可证泄漏。异常路径下忘记 release线程会永久卡死。排查时看线程 dump会发现一堆线程在 acquire 处 BLOCKED 或者 WAITING而且状态一直不变。遇到这种情况优先检查 finally 块。第二随意用 release 扩容。Semaphore 的 release 方法可以让许可证减少也可以增加。你调一次 releasestate 加 1如果初始是 5被 6 个线程依次 release最终 state 会变成 6也就是说它“扩容”了。这通常不是你想要的。如果要动态调整信号量大小需要额外设计不能靠 release 硬加。第三公平模式下的性能衰减。公平模式每个 acquire 都要判断队列状态并可能入队在高并发下会出现明显的吞吐下降。如果业务要求不高默认的非公平模式就够了。第四多许可证获取的原子性。acquire(3)虽然是原子的但如果任务执行一半失败了需要确保release(3)也同样执行而不是只 release 一次。初学者很容易在这里埋 bug。6. 面试回答策略与高频追问6.1 用“一句话加三要点”讲清原理如果面试官问“Semaphore 是怎么实现限流的”我建议你按下面的节奏回答先一句话概括Semaphore 是一个共享锁工具内部维护一个许可计数器通过 AQS 的 state 保存剩余许可证数获取许可时用 CAS 原子扣减获取不到就进入 AQS 同步队列阻塞等待释放时用 CAS 归还许可并唤醒队列中的后继线程。然后再补三个要点。第一CAS 负责 state 的原子更新保证并发安全第二AQS 负责排队和唤醒让拿不到许可的线程有地方等待第三公平还是非公平取决于 tryAcquireShared 里要不要检查 hasQueuedPredecessors。这三点说完你基本就把底层原理覆盖了。最后可以补一个个人理解Semaphore 本质是“对 AQS 共享模式的具体实现”。AQS 提供了一个锁框架但资源含义由子类决定Semaphore 把资源定义为许可证数量所以它的 acquire 是“消耗资源”release 是“归还资源”。6.2 高频追问怎么答面试官很喜欢顺着 Semaphore 继续深挖 AQS常见追问我整理了一下为什么 state 要用 volatile因为多线程并发读写许可证数量时必须保证一个线程修改后其他线程能立刻看到最新值。volatile 保证了可见性再配合 CAS 保证原子性。为什么获取许可要用 CAS 而不是 synchronizedCAS 是乐观锁适合临界区非常短的操作比如扣减一个 int。如果每次都靠 synchronized 加锁线程会因为竞争锁而频繁阻塞唤醒性能反而下降。CAS 失败时自旋重试在低竞争场景下开销更小。Semaphore 和 CountDownLatch 有什么区别CountDownLatch 是“倒计时门闩”主要用来等待多个线程都到达某个状态后再放行Semaphore 是“资源信号量”控制多个线程同时访问有限资源。一个偏协同一个偏限流。可重入吗Semaphore 本身不是可重入锁。同一个线程可以多次 acquire但每次都必须对应 release它不是按线程持有数加锁的模型。这一点和 ReentrantLock 有本质区别。面试时如果能答到“AQS 的共享模式”这个高度一般就能过关了。如果再能说出doReleaseShared里的唤醒逻辑或者tryAcquireShared里返回值语义那绝对是加分项。我个人在实际项目里的体会是Semaphore 是很轻量的并发保护工具但一定要清楚它的边界。它能保证资源并发数不超限但不能替代 QPS 限流。真正生产环境中信号量经常和线程池、熔断器、流量控制组件组合使用。对于面试把 AQS 和 CAS 的关系理解透远比死记硬背源码有效。能用自己的话讲明白 state 的扣减与归还、队列的阻塞与唤醒你就已经把并发编程的核心思想掌握大半了。