Go并发优化需减少锁竞争、降低调度开销、避免不必要同步：用原子操作替代互斥锁，缩小临界区，控制goroutine数量并复用，通过channel传递所有权而非共享内存。
Go 语言的并发模型以轻量级协程（goroutine）和通道（channel）为核心，但盲目使用 goroutine 或不当加锁反而会拖慢性能。优化关键在于：减少锁竞争、降低协程调度开销、避免不必要的同步。下面从四个实用角度切入，直击常见瓶颈。
用无锁数据结构替代互斥锁
sync.Mutex 在高并发读多写少场景下极易成为热点。优先考虑原子操作（atomic）或 sync/atomic 包提供的无锁原语；对计数器、状态标志、简单指针更新等，用 atomic.LoadInt64、atomic.CompareAndSwapUint32 等代替加锁读写。
- 计数器场景：用 atomic.AddInt64(&counter, 1) 替代 mutex.Lock() + counter++ + mutex.Unlock()
- 单次初始化：用 sync.Once，它内部基于原子操作，比手写双重检查锁更安全高效
- 只读共享数据：构建完成后用 sync.RWMutex 保护写，读操作几乎零开销；若数据完全不可变，可直接全局变量+内存屏障（如 atomic.StorePointer）发布
缩小临界区，避免在锁内做耗时操作
锁的持有时间越长，协程阻塞越多，调度器被迫唤醒等待协程的次数也越多。要把“真正需要同步的代码”压缩到最小范围。
- 不要在 lock/unlock 块里调用 HTTP 请求、数据库查询、文件 IO 或复杂计算
- 先在锁外准备好数据（如构造新结构体），再进锁仅做指针赋值或 map 写入等瞬时操作
- 对 map 并发读写，不要用 mutex 全局保护整个 map；改用 sharded map（分片哈希表），按 key 哈希到不同 shard，各 shard 独立锁，大幅降低冲突概率
控制 goroutine 数量，复用而非泛滥创建
goroutine 虽轻量（初始栈仅 2KB），但成千上万并发启动仍带来调度器压力、内存碎片和上下文切换成本。应按需节制，并善用池化与批量处理。
立即学习“go语言免费学习笔记（深入）”；
- 用 worker pool 模式：固定 N 个长期运行的 goroutine 消费 channel 任务，避免每请求启一个 goroutine
- IO 密集型任务（如大量 HTTP client 调用）：设置合理的 http.Transport.MaxIdleConns 和超时，配合 context 控制生命周期，防止堆积
- 短生命周期任务：考虑用 sync.Pool 复用临时对象（如 bytes.Buffer、JSON 解析器），减少 GC 压力间接降低调度抖动
用 channel 正确传递所有权，避免共享内存
Go 的 “不要通过共享内存来通信” 不是教条，而是设计原则：让数据在 goroutine 间流动，而非被多个 goroutine 同时读写。这天然规避锁和竞态。
- 生产者将数据发送到 channel 后，不再访问该数据；消费者接收后独占使用——这是最自然的无锁协作
- 对需要响应的请求，用带缓冲的 channel 或 select + timeout 实现非阻塞收发，避免死锁和 goroutine 泄漏
- 慎用全局 channel；高频通信建议每个 worker 配独立 channel 对，或用 fan-in/fan-out 模式聚合，减少争用点
不复杂但容易忽略：性能优化不是堆砌并发，而是理解你的数据流和竞争热点。用 pprof 分析 goroutine 数量、mutex contention、调度延迟，比凭经验猜测更可靠。
