因为memory_order_relaxed不提供同步语义，会导致wait和post间内存重排，破坏因果关系；wait需acquire或acq_rel，post需release，自旋等待在高并发下空耗CPU，长时间等待应退化为条件变量。
std::atomic 实现信号量时为什么不能只用 memory_order_relaxed
因为 memory_order_relaxed 不提供同步语义，会导致 wait 和 post 操作之间出现内存重排，破坏“资源获取后才执行临界区”的因果关系。比如线程 A 调用 post() 唤醒线程 B 后，B 可能读到更新后的计数器值，却仍看到旧的共享数据——这不是原子变量没生效，而是内存序没约束读写顺序。
常见错误现象：wait() 返回后立刻访问 buffer，但读到未初始化或过期数据；多线程下偶发断言失败或崩溃，且难以复现。
- wait() 必须用
memory_order_acquire或memory_order_acq_rel，确保后续读写不被重排到它之前 - post() 应配对使用
memory_order_release，保证之前所有修改对唤醒线程可见 - compare_exchange_weak 内部隐含 acquire/release 语义，但显式指定更安全、意图更清晰
自旋等待（busy-wait）在高并发场景下的实际代价
纯原子实现的信号量在资源紧张时会陷入 tight loop：每个线程反复调用 load() 和 compare_exchange_weak()，空耗 CPU，尤其在核数多、竞争激烈时，吞吐反而下降，还可能饿死低优先级线程。
典型使用场景：短临界区 + 资源充足（如限流阈值远高于峰值请求）；不适合长阻塞或低频高负载场景。
立即学习“C++免费学习笔记（深入）”；
- 若平均等待时间 > 100ns，应考虑退回到条件变量方案
- 可通过添加
std::this_thread::yield()或指数退避（如std::this_thread::sleep_for(1ns * (1 ）缓解 CPU 占用 - Linux 上可调用
__builtin_ia32_pause()（x86）降低自旋功耗，但非跨平台
std::counting_semaphore 与手写原子信号量的关键差异
C++20 的 std::counting_semaphore 在多数实现中（如 libstdc++、libc++）底层仍是原子变量 + futex 系统调用组合，并非纯用户态自旋。它会在首次阻塞时进入内核等待，避免无谓 CPU 消耗。
这意味着：你手写的纯原子信号量无法替代标准库版本在真实服务中的鲁棒性，除非你明确控制等待行为且接受 CPU 毛刺。
-
std::counting_semaphore::acquire()可能触发系统调用，但只在真正需要阻塞时；手写版则每次 wait 都走原子路径 - 标准库支持
try_acquire()，返回 bool，适合超时/非阻塞逻辑；手写版需额外封装才能安全支持 - 初始化值超过模板参数上限（如
std::counting_semaphore）会编译失败；手写版用std::atomic<int></int>无此限制，但也失去编译期校验
手写原子信号量必须检查的三个初始化边界
信号量计数器初始为负值、零、或极大正数，都会引发不同层面的问题，而编译器不会报错。
- 初始值 wait() 可能永远自旋，或因 compare_exchange_weak 误判导致非法状态
- 初始值 == 0：合法，但所有线程首次调用
wait()都会阻塞——需确认这是设计意图而非配置错误 - 初始值过大（如 INT_MAX）：在频繁
post()后可能溢出，fetch_add(1)不检查溢出，结果未定义
真正容易被忽略的是：手写信号量没有析构保护。若对象在仍有线程阻塞时被销毁，cv_.notify_all()（如有）或原子变量本身都可能访问已释放内存——标准库的 std::counting_semaphore 无此问题，因其不依赖堆分配的同步原语。
