最简并发安全队列应使用 sync.Mutex 包裹 []interface{} 切片，所有方法（Push/Pop/Len）均需加锁，避免只锁写操作、锁内耗时或空切片误判；channel 适合特定通信场景但非通用队列；sync.Pool 可优化高频分配，重点复用底层数组；container/list + RWMutex 反而更慢且复杂。
用 sync.Mutex 包裹切片实现最简并发安全队列
Go 标准库没有内置线程安全队列，但多数场景下不需要复杂结构——直接用 []interface{} 加互斥锁就能满足需求。关键不是“多快”，而是“不丢、不错、不 panic”。
常见错误是只锁写操作却忽略读（比如 Pop 时未检查长度就取索引），或在锁内做耗时操作（如 JSON 序列化），导致其他 goroutine 长时间阻塞。
- 所有公开方法（
Push、Pop、Len）都必须加锁，哪怕只是读长度 - 避免在锁内调用用户传入的回调函数，否则可能死锁或拖慢整个队列
- 用
len(q.data) == 0判断空，别用q.data == nil——切片可非 nil 但长度为 0
type Queue struct {
mu sync.Mutex
data []interface{}
}
func (q *Queue) Push(v interface{}) {
q.mu.Lock()
q.data = append(q.data, v)
q.mu.Unlock()
}
func (q *Queue) Pop() (interface{}, bool) {
q.mu.Lock()
defer q.mu.Unlock()
if len(q.data) == 0 {
return nil, false
}
v := q.data[0]
q.data = q.data[1:]
return v, true
}
用 channel 实现无锁队列但要注意容量与阻塞语义
Channel 天然并发安全，但它是有界/无界通信管道，不是传统意义上的“队列数据结构”——它不支持随机访问、不支持遍历、无法获取当前长度（len(ch) 只返回缓冲区剩余空间，不是“待处理消息数”）。
容易踩的坑是误以为 chan interface{} 能替代队列：当生产者速度远高于消费者，且 channel 无缓冲或缓冲小，ch 会直接阻塞，而真实业务中你往往需要“丢弃”或“降级”而非卡住。
立即学习“go语言免费学习笔记（深入）”；
- 固定容量缓冲 channel（
make(chan T, 100)）适合背压明确的场景，如日志批量投递 - 零缓冲 channel 适合同步信号传递，不适合存数据
- 不要用
range ch做“消费全部”，除非你确定 channel 会被 close；否则会永远阻塞
用 sync.Pool 优化高频短生命周期队列对象分配
如果每秒创建成百上千个临时队列（比如每个 HTTP 请求构造一个任务队列），直接 new 结构体+切片会触发频繁 GC。这时可复用对象，但必须注意：sync.Pool 中的对象无访问顺序保证，且可能被随时清理。
真正起作用的是复用底层切片，而不是结构体本身。因为切片头（header）很小，重点是避免反复 make([]T, 0, N) 分配底层数组。
- 在
Get()时重置字段（如清空data切片、置零len），不能依赖构造函数 - 不要把含指针的长生命周期对象放入 Pool，可能导致内存泄漏
- Pool 不是万能缓存，它不保证一定命中，
Get()可能返回 nil
为什么不用 container/list + sync.RWMutex
有人尝试组合标准库双向链表和读写锁来提升并发度，但实际收益极低。因为 container/list 的每个节点都是堆上独立分配的小对象，大量 PushFront/PopBack 会产生密集小对象分配+GC压力，且链表遍历缓存不友好。
更严重的是，RWMutex 在写多读少场景下反而比普通 Mutex 更慢——每次写都要等所有 reader 退出，而队列通常是“写后立刻读”，reader 和 writer 高度竞争。
- 基准测试显示，相同负载下，
[]interface{}+Mutex比list+RWMutex快 2–5 倍 -
list的Front()/Remove()不是原子操作，仍需外部同步 - 除非你需要 O(1) 中间插入/删除，否则纯属过度设计
真正难的从来不是“怎么加锁”，而是判断哪些操作必须串行、哪些可以并行，以及是否真的需要队列——有时一个带超时的 select + chan 就比封装五层的“通用并发队列”更可靠。
