sync.Mutex不能直接保护切片读写，因其只复制切片头（指针、长度、容量），底层数组仍共享；append可能触发扩容导致数据竞争，故每次操作均需加锁并注意内存泄漏与性能优化。
为什么 sync.Mutex 不能直接保护切片的读写操作
因为切片本身是三元结构（指针、长度、容量），赋值或传参时只复制头信息，底层数组仍共享。锁住的是“变量”，不是“底层数组”。如果多个 goroutine 同时调用 append，即使有 sync.Mutex，也可能触发底层数组扩容并产生数据竞争——这是最常被忽略的竞态根源。
- 必须在每次
append前加锁，并在扩容完成、更新切片变量后才解锁 -
len(q.data)和cap(q.data)的读取也应加锁，否则可能读到中间态（比如扩容中旧指针未更新） - 避免在锁内做耗时操作（如序列化、网络调用），否则阻塞整个队列
如何封装一个带 Push/Pop 的线程安全切片队列
不要试图复用 container/list 或 channel——前者无锁但非原子，后者有调度开销且无法随机访问。直接基于 []interface{} + sync.RWMutex 更可控。
- 用
sync.RWMutex而非sync.Mutex：读多写少场景下，Peek或Len可并发执行 -
Push必须用Lock()，因为append可能修改底层数组地址 -
Pop也要Lock()，因为要修改切片长度（q.data = q.data[1:]是写操作） - 返回值用
ok bool判断是否空队列，别 panic 或返回零值掩盖逻辑错误
type SafeQueue struct {
mu sync.RWMutex
data []interface{}
}
func (q *SafeQueue) Push(v interface{}) {
q.mu.Lock()
q.data = append(q.data, v)
q.mu.Unlock()
}
func (q *SafeQueue) Pop() (v interface{}, ok bool) {
q.mu.Lock()
if len(q.data) == 0 {
q.mu.Unlock()
return nil, false
}
v, q.data = q.data[0], q.data[1:]
q.mu.Unlock()
return v, true
}
Pop 时切片缩容导致内存泄漏怎么办
Go 切片缩容（如 q.data[1:]）不会释放底层数组内存，只要原数组还有引用，GC 就不会回收。高频 Push/Pop 后，data 底层数组可能远大于实际长度，吃光内存。
- 当
len(q.data) 且 <code>cap(q.data) > 256时，主动重建切片：q.data = append([]interface{}{}, q.data...) - 不要每 pop 都重建——判断条件里加容量阈值，避免频繁分配
- 如果业务明确队列大小稳定（如固定缓存 1000 条），初始化时用
make([]interface{}, 0, 1000)，规避动态扩容问题
为什么不用 chan 替代这个队列
chan 天然线程安全，但行为模型不同：它本质是通信通道，不是存储容器。一旦写入端关闭，就不能再写；没有 Len、Peek、Clear 等操作；缓冲区满时 select 默认阻塞或丢弃。
立即学习“go语言免费学习笔记（深入）”；
- 需要查看长度、跳过消费、批量清空时，
chan无法满足 - 高吞吐下，
chan的 goroutine 调度开销比锁明显（尤其小消息高频场景） - 调试困难：
chan内部状态不可见，而切片队列可直接打印len/cap排查堆积
真正复杂的地方不在加锁，而在理解切片的内存语义和扩容时机——漏掉一次锁，或者误判了哪一步会触发底层数组重分配，就等于没线程安全。
