应优先用 sync.Pool 复用高频小对象、sync.RWMutex 优化读多写少场景，避免滥用 sync.Map；通过 schedtrace 定位调度瓶颈，再结合 pprof 精准优化。
用 sync.Pool 复用高频分配的对象，避免 GC 压力
频繁创建小对象（比如 []byte、bytes.Buffer、自定义结构体）会显著拖慢并发吞吐，尤其在高 QPS 场景下。Go 的 GC 虽然高效，但每秒数百万次小对象分配仍会触发频繁的辅助 GC，导致 STW 时间上升和延迟毛刺。
-
sync.Pool不是全局共享池，而是 per-P（逻辑处理器）本地缓存 + 周期性清理，天然适配 Go 的 GMP 模型 - 务必实现
New字段：它只在池空时调用，不能包含任何依赖上下文的初始化逻辑（比如带参数的构造） - 从池中取对象后，必须重置其状态（如
buf.Reset()），否则可能残留上一次使用的数据 - 不要把含 finalizer 或引用外部大对象的值放入池中，会导致内存泄漏或意外存活
var bufPool = sync.Pool{
New: func() interface{} {
return new(bytes.Buffer)
},
}
func handleRequest() {
buf := bufPool.Get().(*bytes.Buffer)
defer func() {
buf.Reset()
bufPool.Put(buf)
}()
// 使用 buf 写入响应...
}
用 sync.RWMutex 区分读多写少场景，而非全用 sync.Mutex
当并发读远大于写（如配置缓存、路由表、连接池元信息），直接上 sync.Mutex 会让所有 goroutine 在读时互相阻塞，吞吐骤降。而 sync.RWMutex 允许多个 reader 同时进入，仅在 writer 进入时排他。
- 写操作代价高：获取写锁会阻塞新 reader，并等待所有当前 reader 退出
- 注意“写饥饿”：持续短读 + 偶尔长写，可能导致 writer 长时间等不到锁；可考虑用
sync.Map替代简单键值读写场景 - 不要嵌套读锁和写锁，极易死锁；更不要在持有读锁时尝试升级为写锁（Go 不支持）
type ConfigStore struct {
mu sync.RWMutex
data map[string]string
}
func (c *ConfigStore) Get(key string) string {
c.mu.RLock()
defer c.mu.RUnlock()
return c.data[key]
}
func (c *ConfigStore) Set(key, val string) {
c.mu.Lock()
defer c.mu.Unlock()
c.data[key] = val
}
避免在 hot path 上用 sync.Map 存简单键值对
sync.Map 是为“读多写少 + 键生命周期不一”的场景设计的，内部用 read map + dirty map + mutex 分层，有额外指针跳转和原子操作开销。如果你只是做固定 key 的配置缓存，或者 key 数量稳定且不大，sync.RWMutex + 普通 map 更快、内存更省、行为更可控。
-
sync.Map的Load/Store方法不是内联的，每次调用都有函数调用开销 - 它的 range 遍历不保证一致性：可能漏掉刚写入或刚删除的项
- 如果 key 是
string且长度固定（如 UUID、状态码），用map[string]T+RWMutex通常比sync.Map快 2–5×
用 runtime.GOMAXPROCS 和 GODEBUG=schedtrace=1000 定位调度瓶颈
并发性能差不一定是代码问题，常是调度器没跑满或 goroutine 频繁阻塞。默认 GOMAXPROCS 是 CPU 核心数，但若你的服务混部、被 cgroup 限核，或存在大量系统调用阻塞（如未设 timeout 的 HTTP client），实际并行度可能远低于预期。
立即学习“go语言免费学习笔记（深入）”；
- 设置
GOMAXPROCS一般不需要手动调，除非你明确知道宿主机资源受限且监控显示 P 长期空闲 - 真正有用的是诊断：加
GODEBUG=schedtrace=1000启动程序，每秒输出调度器状态，重点看idleprocs（空闲 P 数）、runqueue（就绪队列长度）、gwaiting（等待网络/系统调用的 goroutine 数） - 若
gwaiting持续 > 1000，说明大量 goroutine 卡在 I/O；此时应检查net/http.Client.Timeout、数据库连接池大小、DNS 解析是否阻塞等
并发优化最易被忽略的一点：别过早抽象。先用 pprof + trace 定位真实热点，再决定用 sync.Pool 还是换锁策略，而不是一上来就套模板。很多“性能问题”其实是单点阻塞或配置错误，跟并发模型本身无关。