真正卡住无锁队列吞吐的不是算法逻辑，而是高竞争下 atomic.Cas 重试开销和 runtime.futex 内核阻塞；需用 pprof 分析 CAS 失败次数与 futex 调用，识别 ABA、伪共享及底层锁陷阱。
看 pprof 里的 runtime.futex 和 atomic.Cas 调用频次
真正卡住无锁队列吞吐的，从来不是算法逻辑，而是原子指令在高竞争下的重试开销和内核态等待。用 go tool pprof 抓 CPU profile 后，重点不是看你的 Enqueue 函数耗时，而是看它底下压着多少 runtime.futex（说明有 goroutine 被调度器挂起阻塞）和 atomic.CompareAndSwapPointer 的调用次数——后者每失败一次，就代表一次自旋浪费。
常见错误现象：
- 明明没锁，
pprof却显示大量时间花在runtime.futex上 → 实际是 channel 底层或 runtime 对无缓冲通信的隐式阻塞 -
atomic.Cas调用次数远高于入队请求数（比如 10w 次入队触发了 80w 次 CAS）→ tail 指针被多个生产者反复“踩踏”，典型 ABA 或缓存行伪共享（false sharing）征兆
用 go test -bench 测不同 goroutine 数量下的吞吐拐点
无锁队列的性能不是线性增长的。你必须跑多组 benchmark，固定总操作数，只变 -benchmem + 不同的 GOMAXPROCS 和并发 goroutine 数（比如 2/4/8/16/32）。关键看吞吐（op/sec）何时开始下降或平台化。
使用场景：
立即学习“go语言免费学习笔记（深入）”；
- Michael-Scott 队列在 4–8 个生产者时往往达到峰值，再加 goroutine 反而吞吐下跌 → 说明 tail 更新竞争已压垮缓存一致性协议（MESI）
-
make(chan int, 64)在 2–16 生产者区间几乎线性扩展，但到 32+ 时len(ch)波动剧烈 → 缓冲区快速填满，消费者跟不上，背压生效
参数差异：
- 别只测
BenchmarkEnqueue，要写BenchmarkProducerConsumer，模拟真实 worker pool 场景 - 加
-gcflags="-l"禁用内联，避免编译器优化掩盖竞争热点
检查是否掉进 gqueue 的“伪无锁”陷阱
gqueue.New() 返回的队列，名字叫无锁，底层却用 sync.RWMutex 保护链表节点插入 —— 这不是无锁，是“用户层无锁、内核层有锁”。查它的源码就能确认：glist.List.PushBack 内部调用了 runtime.newobject 并持有 mu。
容易踩的坑：
- 用
gqueue.New()做每秒 50w 入队 → 实际触发高频 malloc + GC 扫描，pprof显示大量runtime.mallocgc时间 - 用
gqueue.New(1000)却没意识到其C字段是 unbuffered channel → 生产者一发就阻塞，根本测不出并发能力 - 想当然认为
q.Len()是 O(1) → 实际是遍历链表计数，高并发下读Len()本身就会加剧竞争
验证缓存行对齐和内存屏障是否生效
手写 Michael-Scott 队列时，如果 head 和 tail 指针落在同一 CPU 缓存行（64 字节），一个 CPU 修改 tail 会导致另一个 CPU 的 head 缓存失效（false sharing），性能断崖式下跌。这不是代码 bug，是硬件行为。
怎么做：
- 给
head和tail中间插[12]uint64填充，强制分到不同缓存行 - 所有 CAS 操作后加
atomic.StoreUint64(&q.tailPadding, 0)（带memory ordering的写）来刷新 store buffer - 用
perf stat -e cache-misses,instructions在 Linux 下跑，看 cache-misses/instructions 比例是否 > 1%
真正难调的点不在指针怎么连，而在每个原子操作之后，你有没有让 CPU 知道“这个写必须对其他核可见”——漏掉 atomic.LoadAcquire 或 atomic.StoreRelease，测出来性能忽高忽低，根本不可复现。
