不能直接用sync/atomic实现通用无锁队列，因其仅提供底层原子原语，无法单独解决ABA问题、内存重排序及多生产者多消费者下head/tail指针协同更新的线性一致性难题，易导致元素丢失、死循环或panic。
为什么不能直接用 sync/atomic 实现通用无锁队列
Go 的 sync/atomic 提供的是底层原子原语（如 AtomicLoadUint64、AtomicCompareAndSwapUint64），不是开箱即用的并发数据结构。试图仅靠这些函数手写一个正确、高性能的无锁队列，极大概率会触发 ABA 问题、内存重排序错误或边界竞争——尤其是多生产者多消费者场景下，head/tail 指针的协同更新无法靠单个原子操作保证线性一致性。
常见错误现象：panic: concurrent map read and map write（误用 map 当队列）、死循环（CAS 失败后未退避）、元素丢失（tail 更新覆盖了尚未被 head 观察到的节点）。
- Go 标准库不提供无锁队列，
container/list非并发安全，sync.Mutex包裹的切片或链表是“有锁”方案 -
atomic.CompareAndSwapPointer可用于单生产者单消费者（SPSC）场景，但需手动管理内存生命周期，且 Go 的 GC 不保证指针引用对象不被提前回收 - 真正可用的无锁队列实现（如
github.com/orcaman/concurrent-map的变体）通常依赖 unsafe + 编译器屏障 + 精确的内存序控制，超出绝大多数业务代码必要复杂度
用 chan 替代无锁队列的实际效果
Go 的 chan 在底层使用了带锁的环形缓冲区（当指定 buffer size > 0）或同步通道（buffer size == 0），但它对使用者完全隐藏了锁的存在，语义清晰、调度高效、GC 友好，且能天然配合 select 实现超时、默认分支等控制流。
性能影响：在中低吞吐场景（QPS chan 的锁开销远低于手写无锁逻辑引入的错误成本；高吞吐场景下，可先用 pprof 定位是否真由 channel 锁成为瓶颈，而非预设“无锁一定更快”。
立即学习“go语言免费学习笔记（深入）”；
- 固定容量队列：使用
make(chan T, N)，内部为环形数组，入队/出队平均 O(1)，阻塞行为符合预期 - 避免
len(ch)判断是否为空——该操作非原子，且在并发下结果立即过期；应始终用select+default实现非阻塞尝试 - 不要用
close(ch)表示“队列空”，而应发送 sentinel 值或用context.Context控制生命周期
需要真正无锁时，优先考虑 github.com/Workiva/go-datastructures
这个库提供了经测试的 queue.BoundedBlockingQueue 和 queue.UnboundedNonBlockingQueue，后者基于 Michael-Scott 无锁队列算法实现，使用 unsafe 和 atomic 组合，并通过 runtime.KeepAlive 解决 GC 引用问题。它不是玩具代码，而是被 Workiva 在高负载服务中长期验证过的组件。
兼容性注意：依赖 unsafe，无法在 GopherJS 或某些受限环境运行；API 是泛型前设计（Go 1.18 前），需类型断言或封装适配。
- 初始化：用
queue.NewUnboundedNonBlockingQueue()，返回*queue.Queue - 入队：调用
q.Enqueue(interface{})，失败仅在内存耗尽时返回 false（非常罕见） - 出队：用
q.Dequeue()返回(interface{}, bool)，bool 为 true 表示成功取到值 - 不要混用多个 goroutine 对同一
queue.Queue实例做Enqueue和Dequeue以外的操作（如遍历），该结构不支持迭代
自研无锁队列必须检查的三个内存模型点
若仍坚持手写，以下三点任一遗漏都会导致偶发崩溃或数据错乱，且难以复现：
- 所有指针字段（如 node.next）必须用
atomic.LoadPointer/atomic.StorePointer访问，不能直接读写 —— 否则可能因编译器重排或 CPU 缓存不一致看到中间态 - CAS 循环中必须调用
runtime.Gosched()或runtime.pause()（Go 1.21+）防止忙等榨干 CPU，尤其在高争用下 - 节点内存分配后，必须确保在 CAS 成功前，该节点所有字段（包括 next）已完全初始化 —— Go 的内存模型不保证写入顺序，需显式
atomic.StorePointer(&node.next, nil)而非node.next = nil
实际项目里，99% 的所谓“性能瓶颈”根本不在队列锁上，而在序列化、网络等待或数据库 round-trip。把精力花在写无锁队列之前，先跑一次 go tool pprof -http=localhost:8080 binary 看看火焰图里真正的红区在哪。
