17370845950

应优先用 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），实际并行度可能远低于预期。

• 设置 GOMAXPROCS 一般不需要手动调，除非你明确知道宿主机资源受限且监控显示 P 长期空闲
• 真正有用的是诊断：加 GODEBUG=schedtrace=1000 启动程序，每秒输出调度器状态，重点看 idleprocs（空闲 P 数）、runqueue（就绪队列长度）、gwaiting（等待网络/系统调用的 goroutine 数）
• 若 gwaiting 持续 > 1000，说明大量 goroutine 卡在 I/O；此时应检查 net/http.Client.Timeout、数据库连接池大小、DNS 解析是否阻塞等

并发优化最易被忽略的一点：别过早抽象。先用 pprof + trace 定位真实热点，再决定用 sync.Pool 还是换锁策略，而不是一上来就套模板。很多“性能问题”其实是单点阻塞或配置错误，跟并发模型本身无关。