C++20 的 std::counting_semaphore：不是“锁的替代品”，而是“资源配额管理员”

上周帮同事排查一个服务偶发卡顿的问题，最后发现根源不在线程竞争，而在一组共享资源（比如数据库连接池、GPU显存块、HTTP客户端实例）被无节制地争抢——有人拿走不还，有人等着干瞪眼。这时候，std::counting_semaphore 才真正从教科书里跳出来，成了手边最趁手的工具。

C++20 引入的 std::counting_semaphore，常被误读为“升级版 mutex”或“带计数的 condition_variable”。其实它压根不关心“谁在临界区”，只专注一件事：控制对某类有限资源的并发访问总量。它的核心语义是“配额管理”，而非“互斥保护”。

举个具体例子：你有 4 个 GPU 推理单元，同时最多允许 4 个请求并发执行。用 mutex？锁住整个推理函数？那等于把所有请求串行化——哪怕硬件明明能跑 4 路。用 std::counting_semaphore<4> 就干净利落：每个请求进来先 acquire()，成功就拿到一个“通行令牌”；处理完 release()，归还配额。信号量不阻塞代码逻辑，只约束资源占用数。

它的接口极简，只有三个成员函数：

• acquire()：阻塞直到获得一个单位配额（内部计数器减 1）
• try_acquire()：非阻塞尝试，成功返回 true
• release(N = 1)：释放 N 个单位配额（计数器加 N）

注意：release() 永远不会阻塞，也无需匹配 acquire() 的调用栈深度——这和 mutex 的 RAII 约束完全不同。你可以 acquire() 在 A 函数，release() 在 B 函数；甚至可以在异步回调里释放。这种松耦合，恰恰适合资源生命周期不确定的场景（比如 IO 完成后才释放缓冲区）。

但别急着替换所有锁。信号量不提供内存同步保证。acquire() 和 release() 本身是原子操作，但它们不构成 happens-before 关系。也就是说：如果你用信号量控制线程进入，却没用 std::atomic 或 std::mutex 保护共享数据读写，照样会遇到数据竞争。典型反例：

std::counting_semaphore<10> sem{5};
int shared_data = 0;

// 线程 A
sem.acquire();
shared_data++; // ❌ 危险！没有同步，++ 不是原子操作
sem.release();

// 线程 B 同样操作 → 结果可能不是 +2

正确做法是：信号量管“能不能进”，mutex 或 atomic 管“怎么改数据”。两者职责分明，常常搭档使用。

还有一个易踩坑点：初始值决定最大并发数，但不等于“可用数”。比如 std::counting_semaphore<100>{0}，初始计数为 0，所有 acquire() 都会阻塞——这不是 bug，而是你主动设的“全局暂停开关”。很多服务启停时用这个做优雅等待：先 sem.release(100) 允许全部运行；下线时 sem = std::counting_semaphore<100>{0}，新请求全卡住，老请求自然退出。

实际项目中，我们把它用在三类地方最顺手：

• 限流网关层：限制每秒进来的请求数（配合 try_acquire() 做快速失败）
• 资源池代理：比如封装一个 MemoryPool，acquire() 成功才分配一块显存，release() 时归还并触发 sem.release()
• 批处理协调：10 个子任务并发跑，主线程等齐 10 次 release() 后再汇总——这时用 std::binary_semaphore（即 counting_semaphore<1>）更轻量

顺带提一句：C++20 还提供了 std::binary_semaphore，它是 counting_semaphore<1> 的别名。如果你只需要“开/关”两种状态，用它语义更清晰，且部分实现可能有额外优化。

最后划重点：信号量不是银弹。它解决不了死锁（acquire() 顺序不当仍会卡死），也不自带超时（C++20 标准没提供 try_acquire_for，得自己套 std::condition_variable 或用第三方库）。但它把“资源配额”这件事，从手工计数+条件变量的繁琐组合里解放了出来——少写几行易错代码，多一分确定性。

下次看到“并发数受限”这个需求，别第一反应去翻 mutex 文档。先问自己：我管的是“同一时刻最多几个线程干活”，还是“同一时刻最多几个线程动同一块内存”？前者，std::counting_semaphore 正是为你而生。