atomic.AddInt64是硬件级原子指令，零开销纯用户态操作；信号量wait()触发goroutine阻塞与调度器介入，属运行时层级，二者抽象层级不同，适用场景不可互换。
atomic.AddInt64 和信号量 wait() 的底层执行路径完全不同
atomic.AddInt64 是一条封装好的 CPU 原子指令（如 x86 上的 LOCK XADD），整个读-改-写过程在硬件层面不可中断；而信号量的 wait() 本质是调用 runtime.semasleep，会触发 goroutine 状态切换、入队、调度器介入，甚至可能陷入系统调用。两者根本不在同一抽象层级。
这意味着：对单个整数计数器做增减，用 atomic.AddInt64 是零开销的纯用户态操作；而用信号量实现同等逻辑，哪怕只控制一个资源，也要付出调度代价——不是“慢一点”，而是“多一层运行时干预”。
- atomic 操作不改变 goroutine 状态，不会让出 P，也不触发调度器检查
- 信号量
wait()在计数器为 0 时必然 park 当前 goroutine，唤醒需 runtime.wakep 配合 - atomic 不涉及内存分配或队列管理；信号量背后有
SemaRoot+ AVL 树 + 全局 sema 处理器
什么时候该用 atomic.StoreUint32 而不是信号量控制状态位
状态切换类场景（如服务启停、连接就绪、配置加载完成）必须用 atomic.StoreUint32 + atomic.LoadUint32，而不是信号量。信号量没有“状态快照”语义，它只管“能否通行”，无法表达“当前是什么状态”。
比如你想让多个 goroutine 观察某个模块是否已初始化完毕：
立即学习“go语言免费学习笔记（深入）”；
- 用
atomic.StoreUint32(&ready, 1)写入，atomic.LoadUint32(&ready)读取 —— 所有 goroutine 立刻看到一致值，且无竞争 - 若改用信号量：你得先
signal()一次表示 ready，但其他 goroutinewait()后就消耗掉了这个“信号”，无法重复观测；想复用就得反复signal()，逻辑错乱 - 更严重的是，信号量无法保证写入顺序可见性，而 atomic 操作自带 full memory barrier
atomic.CompareAndSwapInt64 实现无锁栈时，为什么不能替换成信号量
atomic.CompareAndSwapInt64 是构建无锁数据结构（如栈、队列）的基石，它提供“检查-更新”原子性，允许你基于当前值决定下一步行为；信号量没有条件判断能力，只有“拿/还”两种动作。
典型反例：实现一个无锁 LIFO 计数器，push 时要确保新节点的 next 指向旧 top，再把 top 替换为新节点。这需要 CAS 循环重试：
for {
old := atomic.LoadPointer(&top)
newNode.next = old
if atomic.CompareAndSwapPointer(&top, old, unsafe.Pointer(newNode)) {
break
}
}
- 信号量做不到“读当前值 → 构造新状态 → 原子提交”这个三步闭环
- 你无法用信号量表达“仅当 top 等于 A 时才设为 B”这样的逻辑
- CAS 失败后可立即重试；信号量
wait()失败则阻塞，彻底破坏无锁设计意图
信号量适合限流，但 atomic.AddInt64 不能直接替代
信号量天然适配“N 个并发许可”的模型，比如限制最多 5 个 goroutine 同时访问数据库。这时用 semaphore.Acquire(ctx, 1) 是语义清晰、边界明确的选择。
有人试图用 atomic.AddInt64(&counter, 1) 模拟许可计数，再手动判断是否超限，这是危险的：
- 没有自动阻塞机制：你得自己轮询或 sleep，浪费 CPU 或引入延迟
- 缺乏唤醒逻辑：许可释放后，无法精准通知某个等待者，只能靠所有等待者竞争重试
- 缺少上下文取消支持：
semaphore.Acquire可响应ctx.Done()；atomic 操作本身无 context 感知能力 - 超限时的“回退”操作（即
atomic.AddInt64(&counter, -1)）和并发竞争之间存在窗口，极易漏减或多减
真正需要性能极致的简单计数场景，atomic 是首选；但凡涉及“等待-唤醒-许可管理”，信号量（或 channel）才是正解。混淆这两者的边界，往往是在用原子操作模拟锁，反而放大了复杂度和风险。
