应优先用 sync.Pool 复用短生命周期对象、sync.Map 优化读多写少场景、分片锁降低竞争、chan/atomic 替代简单同步，避免 GC 压力与锁瓶颈。
用 sync.Pool 复用对象，避免高频分配+GC压力
高并发下频繁 new 结构体或切片（比如每次 HTTP 请求都创建 bytes.Buffer 或自定义请求上下文）会触发大量堆分配和 GC 扫描，间接加剧锁竞争——因为 GC 会 STW，而运行时的内存管理本身也依赖内部锁。
实操建议：
-
sync.Pool适合生命周期短、可复用、无状态的对象（如缓冲区、序列化器实例）；不要存含指针或需清理资源的对象（如未关闭的file） - 必须在
Get后检查返回值是否为nil，并做初始化；Put前确保对象已重置（例如buf.Reset()），否则可能污染下次使用 - 避免在
defer Put()中直接传参（闭包捕获变量易出错），推荐显式赋值后Put
var bufPool = sync.Pool{
New: func() interface{} { return new(bytes.Buffer) },
}
// 使用：
buf := bufPool.Get().(*bytes.Buffer)
buf.Reset() // 必须重置
defer func() { bufPool.Put(buf) }()
用 sync.Map 替代原生 map + sync.RWMutex
当读多写少且键集动态变化（如连接池、session 缓存）时，手写 RWMutex 保护普通 map 容易因锁粒度粗导致写操作阻塞所有读，尤其在 goroutine 数量远超 CPU 核数时更明显。
sync.Map 内部采用分段锁 + 只读映射 + 延迟删除，读几乎无锁，写仅锁定对应 shard，但代价是不支持 range、无顺序保证、不能直接获取长度（需原子计数器配合）。
立即学习“go语言免费学习笔记（深入）”；
常见误用：
- 当成通用 map 用：比如需要遍历所有 key、要求强一致性读写顺序、或 key 类型不可比较（
sync.Map要求 key 可比较） - 频繁调用
LoadOrStore却忽略返回的loadedbool，导致意外覆盖已有值 - 误以为它比原生 map +
RWMutex在所有场景都快——小数据量、写多读少时反而更慢
拆分锁粒度：用 sharded mutex 或 map[shard]*sync.Mutex
当一个全局锁（如保护用户 ID 到状态映射的 sync.Mutex）成为瓶颈，最直接的优化是哈希分片：按 key 计算 shard index，每个 shard 独立一把锁。这能将锁竞争降低约 N 倍（N 为 shard 数）。
实操要点：
- shard 数建议设为 2 的幂（如 32、64），便于用位运算取模：
hash(key) & (shards - 1) - 避免 shard 数过小（仍竞争）或过大（内存浪费、cache line false sharing 风险上升）
- 若用
[]*sync.Mutex，注意预分配并初始化每个元素；也可用sync.Pool复用*sync.Mutex实例（但通常没必要） - 不要试图用
atomic.Value存锁——它只支持无锁读，不能替代互斥语义
优先用无锁结构：从 chan 和 atomic 开始评估
很多“需要锁”的场景其实可用 channel 或原子操作替代。例如计数器、状态切换、任务分发，用 atomic.AddInt64 或 atomic.CompareAndSwapInt32 比加锁快一个数量级，且无 Goroutine 阻塞风险。
典型适用场景：
- 开关控制（
atomic.Bool）、请求计数（atomic.Int64）、时间戳更新（atomic.StoreInt64） - 生产者-消费者模型中，用带缓冲的
chan传递任务，天然线程安全，比锁+队列更简洁 - 避免滥用
atomic操作复杂结构：比如对 struct 字段分别原子操作，但整体语义不一致——这时应考虑unsafe.Pointer+atomic.StorePointer替换整个指针，或回归锁
真正难处理的是跨多个字段的复合状态变更（比如“余额扣减 + 订单状态更新 + 日志记录”），这种没法靠原子操作一步到位，得回到锁或事务型设计。
