★ FEATURED ARTICLE 先说个我早年间调过的真实问题。某个服务在连续跑了两天后突然卡住日志里只剩下零星几条请求记录线程 dump 一看所有工作线程都停在同一个地方——某个资源池的获取入口。可资源池空闲容量明明还有不少线程却全部堵死用户请求大量超时。排查到最后问题并不是出在资源池本身而是负责控制并发访问数量的信号量在异常分支里没有被释放。信号量Semaphore这个概念教科书定义非常简单一个计数器两个操作。可实际代码里它却是多线程项目中最容易被“用坏”的组件之一。线程一旦全部阻塞在信号量上整个系统就像马路中间的交通灯坏了所有车都堵在路口。这篇文章我会把信号量从原理到实操完整梳理一遍包括它的运行机制、在语言 API 里的正确写法、经典使用场景以及真实项目中容易踩的坑。适合刚开始写并发代码的人也适合那些用过信号量但始终没想透“为什么是这样”的读者。1. 信号量是拿来做什么的一次线程集体卡死的排查1.1 那次事故的完整表象先还原一下那天的场景。服务有几十个工作线程每个线程处理请求时会先从某个第三方后台取一份授权数据取到的瞬间再执行后续业务。后台对并发取数有限制最多同时 5 个请求所以代码里很自然地用了一个初始值为 5 的信号量来限流。上线几天一直正常。直到某天深夜流量稍高服务突然大面积超时。线程 dump 里几乎所有工作线程的栈都停在同一行at java.util.concurrent.Semaphore.acquire信号量的许可数量已经是 0等待队列里挂了几十条线程。可当时后台并没有过载实际处理请求量也很低信号量不该一直被占满。继续追代码发现业务方为了“提高吞吐”在一个异步回调里又加了一次并发分支。某个异常路径会提前直接退出而退出之前没有执行 release()。一次少放一个许可次数多了许可就全被“吃”光了。这个问题的核心就是信号量的基本语义没有被严格遵守信号量的每一次占用都必须有对应的释放来兜底。1.2 信号量的本质一个带数量的闸门信号量解决的是一个挺贴近生活的问题某些资源一共有 N 个可用名额系统同时只允许 N 个访问者进去使用第 N1 个访问者必须排队等前面有人出来才能进入。你可以把它类比成商场停车场的剩余车位显示屏。显示屏上的数字就是“还能进多少辆车”。每进一辆车数字减一每离开一辆车数字加一。数字归零时停车场入口的栏杆落下后来的车只能在门口排队。等有车出来栏杆抬起放一辆车进去。这里的“数字”就是信号量的计数器“排队车辆”就是等待线程队列“落杆/抬杆”就是信号量的两个基本动作。你不需要关心停车场内部怎么分配车位只需要知道“当前能不能进”这就是信号量给并发程序提供的确定性。从使用角度看信号量最核心的价值是它把“资源有多少份”“谁在用”“谁在等”这三件事统一成了一个可查询、可操作的整数状态。线程不管来自哪个模块只要遵守“先获取、后释放”的约定整体并发数量就一定是可控的。2. 信号量的运转模型计数器、等待队列与 P/V 操作2.1 信号量内部到底存了什么一个标准的信号量内部可以简化为两个组成部分struct semaphore { int count; // 可用许可数量 queuethread wait_queue; // 等待获取许可的线程队列 };count是信号量的“心脏”它表示当前还有多少资源名额可用。wait_queue是“停车场门口排队车辆”当count已经减到负数时新的线程就会被挂到队列里不再占用 CPU 空转。信号量的两个核心操作历史上叫 P 操作和 V 操作。P 来自荷兰语尝试ProberenV 来自增加Verhogen。现代编程语言里对应的 API 一般叫 acquire获取和 release释放或者 wait等待和 signal唤醒。不管名字怎么变语义是完全一致的P 就是“尝试占用一份资源”V 就是“归还一份资源”。2.2 P/V 操作的标准流程下面用伪代码完整描述一次操作的过程P(sem): // acquire / wait 进入内部临界区加锁 sem.count sem.count - 1 如果 sem.count 0: 把当前线程放入 sem.wait_queue 阻塞当前线程让出 CPU 退出内部临界区解锁 V(sem): // release / signal 进入内部临界区加锁 sem.count sem.count 1 如果 sem.count 0: 从 sem.wait_queue 取出一个线程 唤醒该线程 退出内部临界区解锁注意这里判断条件用的是count 0和count 0而不是count 0。原因在于当count变成负数之后负数的绝对值恰好代表正在等待的线程数量。举个例子。信号量初始化为 1线程 A 先执行 Pcount变成 0A 进入临界区。线程 B 后执行 Pcount变成 -1B 进入等待队列。此时 -1 就说明有一个线程在排队。如果初始化为 3且三个许可都被占完再有线程 Pcount变成 -1、-2、-3等待队列长度一目了然。单纯看流程P/V 操作本身并不复杂。复杂的是“进入内部临界区”这一步——为什么 P 操作里面还要再加锁2.3 为什么 P/V 必须原子执行信号量设计的核心难点在于count - 1这个操作不能被打断。假设有两个线程同时执行 P信号量count初始为 1。如果没有原子保护可能两个线程同时读到count 1都认为“还有名额”都执行了减一最后两个线程都进入了临界区。这就完全违背了信号量的初衷。这种“先检查、后修改”的竞态和银行账户转账是一样的道理两个用户同时查询余额都发现余额足够同时扣款账就对不上了。解决办法只有一个就是让“检查并修改”成为一个不可分割的原子操作。现代操作系统实现原子性通常有三种方案单核 CPU 上短暂关闭中断确保 P/V 内部代码执行期间不会被线程调度打断多核 CPU 上使用原子指令比如 CASCompare-And-Swap或 xadd一条指令完成“读-改-写”信号量内部再嵌一把自旋锁先抢到内部锁的人才能操作count和wait_queue。这些实现细节平时写业务代码不会直接接触但它决定了你使用信号量时的一个基本认知信号量本身是线程安全的你需要关注的不是它的内部而是自己是否遵守了“获取-释放”的调用约定。3. 二值信号量、计数信号量与互斥锁容易被混淆的三兄弟3.1 二值信号量不等于互斥锁信号量的count初始化为 1 时叫二值信号量。它看起来和互斥锁很像同一时刻只允许一个线程通过。但两者有一个本质区别——所有权ownership。互斥锁有“持有者”概念哪个线程锁定的就应当由哪个线程解锁。如果线程 A 锁定线程 B 去解锁多数系统会直接报错或者行为未定义。信号量则完全没有这个限制任何线程都可以对同一个信号量执行 V 操作把许可加回去。这个特性在特定场景下非常有用比如一个线程负责发信号、另一个线程负责等信号本质上是一种“跨线程通知”。但在保护临界区的场景下它也是巨大隐患。看一个很隐蔽的错误用法Semaphore mutex new Semaphore(1); // 线程 A mutex.acquire(); // 进入临界区执行一些操作 mutex.release();看起来没什么问题。但如果线程 A 在临界区里调用了一个公共方法而那个公共方法内部也对同一个信号量执行了 acquire线程 A 就会自己阻塞在自己已经占用的许可上直接死锁。互斥锁如果支持可重入就不会出现这种问题二值信号量没有所有权做不到“同一个线程重复进入”。所以保护普通共享变量、临界区代码时不要用二值信号量替代锁这是很多并发项目事故的根源。3.2 计数信号量与“允许 N 个并发”当信号量的count初始化为大于 1 的整数它就成了计数信号量。计数信号量是“限流”这个需求的经典解法资源一共有 N 份同时最多 N 个访问者。数据库连接池就是典型例子。一个池子最多 10 个连接每个线程拿连接时执行 acquire还连接时执行 release从信号量的视角看Pool 的行为和停车场完全一致。计数信号量不具备互斥锁的互斥语义它允许多个线程同时进入临界区。你用它保护和修改共享变量时多个线程同时进入变量照样会被写坏。很多人第一次接触信号量时犯的错误就是“信号量初始值为 1 能当锁初始值为 5 是不是更高级的锁”不是。它只是一个“允许 5 个并发”的闸门不负责数据互斥。3.3 一张表看清三者的边界维度互斥锁二值信号量计数信号量计数器初始值11NN 1核心用途保护共享数据、临界区线程间发信号 / 简单互斥限流、资源池、多份资源调度是否要求持有者释放是有所有权否任何线程都能释放否任何线程都能释放典型失误非持有者误释放把信号量当锁用导致重入死锁acquire 后忘记 release重入支持通常支持可重入变体不支持不支持选型建议很直接保护变量用锁限制并发数用计数信号量跨线程协作、发通知用二值信号量或条件变量。分清这三类能少写很多“事后看都觉得蠢”的代码。4. 在代码里落地三个主流语言里的信号量 API 与示例4.1 Java 的 Semaphoreacquire/release 与公平性Java 的java.util.concurrent.Semaphore是最常用的实现。构造函数可以传入许可数量和是否公平Semaphore sem new Semaphore(5, true);第二个参数true表示公平模式等待时间最长的线程优先获得许可false就是非公平模式谁抢到算谁的。默认推荐用公平模式多线程场景下能避免“饿死”问题。典型用法是配合try-finally保证 release 一定执行Semaphore sem new Semaphore(5); public void handleRequest() { try { sem.acquire(); // 获取许可许可不足时阻塞 // 处理业务最多同时 5 个线程进入 } catch (InterruptedException e) { Thread.currentThread().interrupt(); } finally { sem.release(); // 释放许可必须放在 finally } }不想无限期等待时可以用tryAcquireif (sem.tryAcquire(3, TimeUnit.SECONDS)) { try { // 拿到了许可 } finally { sem.release(); } } else { // 超时没拿到做降级处理 }Java 信号量的acquire会响应中断。如果你不希望业务代码被中断打断可以使用acquireUninterruptibly()但也要想清楚线程卡住时如何兜底。4.2 Python 的 threading.Semaphoretry/finally 是命根子Python 标准库提供了threading.Semaphore和带初始值的BoundedSemaphore。用法几乎和 Java 一样但有个细节Python 的锁对象支持with语句信号量对象不支持直接进with所以你要么自己封装要么老老实实用try/finally。import threading sem threading.Semaphore(5) def handle_request(): sem.acquire() try: # 最多 5 个线程同时进入 pass finally: sem.release()Python 的BoundedSemaphore比普通Semaphore更值得推荐因为它会检查 release 次数是否超过了 acquire 次数。如果你误写了一次多余 release程序会直接抛出ValueError而不是让计数悄悄漂移排查问题时能省很多力气。4.3 Go 语言channel 天然就是信号量Go 里并没有内置的Semaphore类型但 channel 本身就是信号量的一种实现。容量为 N 的 channel放进一个 token 就相当于 acquire取走一个 token 就相当于 releasesem : make(chan struct{}, 5) for i : 0; i 20; i { go func() { sem - struct{}{} // 占用一个许可满了就阻塞 defer func() { -sem }() // 释放一个许可 // 处理业务 }() }需要更严格语义时可以用官方扩展库的加权信号量import golang.org/x/sync/semaphore sema : semaphore.NewWeighted(5) ctx : context.Background() sema.Acquire(ctx, 1) defer sema.Release(1)NewWeighted支持每次获取多个许可适合“一个任务需要同时占用 2 个资源”的计费场景。Go 的 channel 实现虽然简单但在高并发下也足够可靠。5. 经典场景实操生产者-消费者、限流和连接池5.1 生产者-消费者两个信号量控制缓冲区信号量最经典的出圈用法就是操作系统课程里的“生产者-消费者问题”。一个环形缓冲区大小为 N生产者往里写消费者往外读。核心约束是生产者在缓冲区满时不能再写入消费者在缓冲区空时不能再读取。用两个信号量解决得非常干净。empty初始为 N表示空位数量full初始为 0表示已占用数量。Semaphore empty new Semaphore(N); Semaphore full new Semaphore(0); Lock lock new ReentrantLock(); // 只是保护缓冲区的写入/读取操作 void produce(Item item) { empty.acquire(); // 占领一个空位满了就阻塞 lock.lock(); try { buffer.add(item); } finally { lock.unlock(); } full.release(); // 已占用数量 1 } Item consume() { full.acquire(); // 占用一个已填位置空了就阻塞 lock.lock(); try { return buffer.remove(); } finally { lock.unlock(); } // 注意这里换成 empty.release() 在 finally 里执行 }注意empty 和 full 是两个不同的信号量生产者 P(empty) V(full)消费者 P(full) V(empty)。这样既不会出现缓冲区满时还继续写也不会出现缓冲区空时读空数据。信号量在这里的职责是“容量控制”真正做数据互斥的是那把锁。5.2 并发限流控制服务的最大同时处理数线上经常有这样的需求某个下游接口最多允许 5 个并发超过了就会触发对方限流或超时。线程池也能限制并发数但信号量更轻量适合在调用入口直接包一层。Semaphore downstreamLimit new Semaphore(5); public Result callDownstream(Request req) { if (!downstreamLimit.tryAcquire(2, TimeUnit.SECONDS)) { return Result.fallback(); // 快速降级而不是无限排队 } try { return doHttpCall(req); } finally { downstreamLimit.release(); } }这里用tryAcquire而不是acquire是故意的。信号量限流如果一直傻等高并发时所有线程都挂在信号量上系统吞吐会直接归零。带超时的tryAcquire能在排队时间过长时快速走降级逻辑保住系统的整体可用性。5.3 连接池信号量加对象队列的组合连接池的经典实现本质上就是“信号量 空闲连接队列”。连接总数固定为 N信号量许可数也是 N获取连接时先从队列里面拿空闲对象没有空闲对象就阻塞在信号量上归还连接时把对象放回队列同时释放信号量许可。把连接池抽象成停车场特别贴切车位总数就是连接总数剩余车位显示就是信号量计数停车场入口就是acquire出口就是release。所以你会发现很多连接池内部确实维护了一个Semaphore或者类似的计数器连接太多时新来的请求只能排队。6. 信号量用不对照样出事真实项目里的坑与排查6.1 最常见的坑acquire 了却没人 release文章开头那次事故根子就是漏释放。Java 里最常见的原因是程序员把release()写在业务正常路径里但异常分支或提前 return 的路口直接跳过了它。错误写法sem.acquire(); doSomething(); sem.release(); // 如果 doSomething 抛异常release 不执行正确写法只有一个姿势sem.acquire(); try { doSomething(); } finally { sem.release(); }Python 同理finally里的release是命根子。Go 则尽量用defer释放因为从语法层面杜绝了“忘了释放”的可能性。6.2 二值信号量误当锁用一个隐蔽的逻辑漏洞另一个隐蔽问题来自信号量没有所有权。假设你用了二值信号量保护一个共享队列Semaphore mutex new Semaphore(1); void enqueue(Item item) { mutex.acquire(); queue.add(item); mutex.release(); }正常情况下这模拟了锁的行为。但如果另一处代码出于某种原因对这个信号量也执行了一次release()比如模块间传递信号时不小心多放了一次信号量计数值会变成 2。此时两个线程同时acquire成功双双进入临界区共享变量被并发修改。现场没有任何报错数据却悄悄损坏。这类问题定位时非常痛苦因为它不是每次都发生而是“偶尔发生一次”。排查信号量相关问题方向一定是“计数溢出”和“计数丢失”两头都要查。6.3 排查链路与工具思路如果你遇到线程全部阻塞、疑似信号量问题我建议按这个顺序排查看线程 dump。确认阻塞点是否都在acquire/wait等信号量入口。如果所有线程都在同一个信号量等待基本锁定排查对象。查当前信号量的许可计数。Java 里可以把 Semaphore 对象通过 JMX 或日志输出availablePermits()和getQueueLength()。如果计数长期为 0但业务明明不该满载多半是释放丢失。重点扫异常分支和循环分支。代码里所有acquire之后的try/finally是否完备提前return的路径有没有跳过释放。给信号量加一层可观测封装。在实际项目里给 Semaphore 包一个工具类打印每次 acquire/release 的线程名、当前计数和调用栈。高并发下靠这套日志做时序还原基本能快速定位到元凶。写“计数守恒”测试。模拟高频调用和异常注入异步检查 acquire 次数是否等于 release 次数。这类测试虽然需要点额外代码但对长期维护的项目非常值。排查信号量问题的思路核心只有一条把它当成一个必须守恒的资源而不是一个状态。每一次 acquire 都必须有对应的 release多一次、少一次都是故障源头。我在实际项目中养成了一个习惯所有涉及信号量的代码都封装成独立的小类构造时传入许可数对外只暴露“执行”方法。业务方只需要调用方法释放逻辑永远收敛在框架内部绝不交给业务代码手动拼 try/finally。这样虽然初期多写几行代码但后续排查线程卡死问题时能省掉一整轮通宵。信号量表面上是并发工具本质上是工程纪律。理解了它的计数模型掌握了 acquire/release 的守恒原则你就能在多线程的世界里安心通过每一个闸门。
阅读完成 · 觉得有帮助？
