C++20才引入std::counting_semaphore，因C++11–17设计者认为其易误用且多数场景可用mutex/condition_variable/atomic替代；需编译器支持（GCC11+/Clang12+/MSVC19.30+）并启用-c++20。
标准 C++ 没有 semaphore 类型，C++20 才正式引入 std::counting_semaphore 和 std::binary_semaphore；在此之前只能靠 std::mutex + std::condition_variable 手动模拟，或依赖平台 API（如 POSIX sem_wait）。
为什么 std::counting_semaphore 在 C++20 里才可用
C++11 到 C++17 的线程库刻意回避了信号量——设计者认为多数同步需求能用更安全的 std::mutex、std::condition_variable 或 std::atomic 满足；信号量容易误用（比如忘记 release()、多次 acquire() 导致死锁），且难以静态分析资源生命周期。
实操建议：
- 确认编译器支持：GCC 11+、Clang 12+、MSVC 19.30+，并开启
-std=c++20 - 头文件只需
#include <semaphore></semaphore>，无需链接额外库 - 注意
std::binary_semaphore是std::counting_semaphore的别名，语义更清晰但底层相同
std::counting_semaphore 的典型误用场景
常见错误是把它当“锁”用：比如在临界区入口 sem.acquire()，出口却漏掉 sem.release()，或者在异常路径中没做 RAII 封装，导致计数永久卡死。
立即学习“C++免费学习笔记（深入）”；
正确做法：
- 用 RAII 包装器（如自定义
sem_guard）确保release()在作用域结束时调用 - 避免在循环中无条件
acquire()而不检查返回值——它不抛异常，但可能阻塞，需配合try_acquire_for()做超时控制 - 初始化值不能为负：
std::counting_semaphore sem{-1};是编译错误
示例（带超时的获取）：
if (sem.try_acquire_for(100ms)) {
// 成功进入
do_work();
sem.release(); // 必须显式释放
} else {
// 超时，跳过或重试
}
Windows 下用 CreateSemaphore 替代时的坑
如果你必须兼容 C++17 或旧环境，POSIX 或 Windows API 是常见选择，但跨平台成本高、错误码难统一。
Windows 特有陷阱：
-
CreateSemaphore的第三个参数（初始计数）若设为 0，首次WaitForSingleObject会立刻阻塞——这和std::counting_semaphore行为一致，但容易被忽略 - 句柄必须手动
CloseHandle()，否则泄漏；而std::counting_semaphore析构即清理 -
ReleaseSemaphore的第二个参数（释放数量）若大于当前最大计数（由CreateSemaphore第二个参数决定），调用失败且GetLastError()返回ERROR_TOO_MANY_POSTS
性能与替代方案对比
std::counting_semaphore 底层通常基于 futex（Linux）或 SRW lock（Windows），比纯 std::mutex + std::condition_variable 组合略轻量，但比 std::atomic 重得多。
选型建议：
- 资源池管理（如数据库连接数、线程池任务槽位）→ 用
std::counting_semaphore最自然 - 单纯保护一段内存 → 优先用
std::mutex或std::atomic - 需要等待某个条件成立（如缓冲区非空）→
std::condition_variable更语义明确，不易出错
最常被忽略的一点：信号量不记录“谁持有”，也无法查询当前计数值（current_count() 是非原子的快照，仅用于调试）。真要依赖精确计数逻辑，大概率说明设计该重构了。
