17370845950

设为物理核心数而非逻辑线程数更优，因过多P会加剧调度开销、缓存失效和TLB压力；混杂I/O时则不宜盲目降低。

为什么 runtime.GOMAXPROCS 设为 CPU 核心数不一定最优

默认情况下，Go 运行时会将 GOMAXPROCS 设为系统逻辑 CPU 数（如 8 核 16 线程设为 16），但这不等于你的 CPU 密集型任务就该用满全部 P。当 goroutine 都在做纯计算（无 I/O、无 channel 阻塞），过多的 P 会导致调度器频繁切换、缓存失效加剧、TLB 压力上升。

• 实测中，对单一大循环分块并行的场景，GOMAXPROCS 设为物理核心数（而非逻辑线程数）常有 5–15% 性能提升
• 可通过 runtime.NumCPU() 获取物理核心数，再手动调用 runtime.GOMAXPROCS(n)
• 注意：若程序混杂大量 I/O 或 channel 操作，盲目降低 GOMAXPROCS 反而会阻塞非计算型 goroutine

用 sync.Pool 缓存高频分配的小对象，但别缓存大结构体

CPU 密集型任务常伴随高频中间计算结果（如 []float64 切片、小 struct 实例）。每次 make 或 new 都触发堆分配，增加 GC 压力和内存访问延迟。

• sync.Pool 对固定尺寸、生命周期短的小对象（如 [64]float64 数组、struct{ x, y int }）效果显著
• 避免缓存超过几 KB 的对象——Pool 内部无大小限制，大对象会长期驻留，反而污染 L3 缓存，且可能被 GC 误判为活跃
• 务必实现 New 函数，且返回值必须是零值初始化（不能带副作用）

var float64Pool = sync.Pool{
    New: func() interface{} {
        return make([]float64, 0, 256) // 预分配容量，避免 append 扩容
    },
}

避免在 hot path 中调用 fmt.Sprintf、strconv.Itoa 等反射/分配型函数

CPU 密集型代码里，哪怕一行日志格式化都可能吃掉 1–2% 的周期。这些函数内部会分配字符串、调用反射或 grow slice，破坏 CPU 流水线连续性。

• 用 fmt.Sprint 替代 fmt.Sprintf（如果目标是 string 且参数简单），或直接拼接："id:" + strconv.FormatInt(id, 10)
• 对整数转字符串，优先用 strconv.AppendInt(dst, n, 10)，它复用传入的 []byte，零分配
• 调试输出尽量关掉；生产环境用结构化日志库（如 zerolog）并禁用字段反射

内联失败？检查 //go:noinline 和函数复杂度阈值

Go 编译器对小函数自动内联，消除调用开销。但一旦函数体过大、含闭包、或递归，就会放弃内联——这在数学计算循环中很致命，比如一个被调用百万次的 clamp(x, min, max) 若未内联，每次 call/ret 就多出 10+ 周期。

• 用 go build -gcflags="-m=2" 查看内联决策，搜索 cannot inline 关键字
• 避免在 hot 函数中使用 defer、recover、interface{} 参数或 map/slice 操作（它们抬高内联成本）
• 必要时加 //go:inline（Go 1.19+），但需确认函数确实满足编译器要求；慎用 //go:noinline——除非你在测 baseline

实际优化时，最常被忽略的是「伪共享」：多个 goroutine 同时写不同字段，但字段落在同一 CPU cache line（64 字节）上，导致 core 间反复同步缓存行。这种情况不会报错，但性能随并发数上升不升反降。遇到这种现象，优先考虑 padding 对齐或重排 struct 字段顺序。