go多核性能瓶颈常源于调度失配、缓存失效与gc干扰；应设gomaxprocs为物理核心数、用固定worker池替代泛滥goroutine、避免高频分配与隐性同步，并以pprof和perf验证优化效果。
Go 程序在多核 CPU 下性能不理想，往往不是因为语言不行，而是调度没配对、任务没分好、协程泛滥反拖慢——runtime.GOMAXPROCS 设对了只是起点，真正卡脖子的常是伪并行、缓存失效或 GC 干扰。
为什么设了 GOMAXPROCS 还压不满多核？
默认值（runtime.NumCPU()）通常是逻辑核心数（比如 8 核 16 线程 → 设为 16），但纯 CPU 密集任务跑满 16 个 P，反而加剧调度抖动和 L3 缓存污染。实测中，设为物理核心数（如 8）常提升 5–15% 吞吐。
- 用
runtime.NumCPU()获取的是逻辑核数；要物理核数需读/proc/cpuinfo或用第三方库（如gopsutil） - 混 I/O 的服务（如 HTTP + 计算）可保留逻辑核数；纯数值计算建议降为物理核数
- 别在运行中反复调用
runtime.GOMAXPROCS(n)，会重置调度器状态，引发短暂抖动 - 验证是否生效：启动时加
GODEBUG=schedtrace=1000，观察每秒 P 是否稳定活跃
协程一多就变慢？这不是并发，是“并发幻觉”
把 10 万个简单加法扔进 10 万个 go func()，结果比单 goroutine 还慢——因为调度开销、上下文切换、缓存行颠簸全来了。CPU 密集任务不需要“多”，需要“稳且准”。
- 用固定 worker 池替代无限 goroutine：worker 数 =
GOMAXPROCS值（通常 4–12），通过带缓冲chan Task分发 - 每个 worker 用
for job := range jobs持续取任务，避免 goroutine 频繁创建销毁 - 切分任务按数据块（如数组下标区间），而非按条目；8 核就分 8 块，每块由一个 goroutine 独占计算
- 别用
sync.WaitGroup等上千个 goroutine，改用errgroup.Group或 channel 聚合结果
明明没锁，CPU 却上不去？检查这三处隐性同步点
看似无锁，实际可能被原子操作、map 写入或 GC 拖住。top 显示 CPU 利用率低，但 pprof 显示大量时间花在 runtime.mallocgc 或 runtime.semawakeup 上，就是信号。
立即学习“go语言免费学习笔记（深入）”；
-
map并发写入会 panic；即使只读多写少，也优先用sync.Map或分片 map + 局部聚合 - 计数器类场景用
atomic.AddInt64，别用mutex包一层再 ++ - 高频分配小对象（如
[]byte、临时结构体）用sync.Pool，但注意：Pool 不适合大对象（>2KB），否则污染缓存且难回收 - 热循环里禁用
fmt.Sprintf、strconv.Itoa；整数转字符串用strconv.AppendInt(dst, n, 10)，零分配
怎么确认优化真起效？别信直觉，看三组数据
改完代码不验证，等于没改。真实瓶颈常藏在 GC 停顿、TLB miss 或内存带宽上，光看 CPU 使用率会误判。
- 用
go tool pprof -http=:6060 http://localhost:6060/debug/pprof/profile?seconds=30抓火焰图，重点看顶层函数是否为你自己的计算逻辑 - 加
import _ "net/http/pprof"和http.ListenAndServe("localhost:6060", nil)，再跑go tool trace查 GC 频次与 STW 时间 - 用
perf stat -e cycles,instructions,cache-misses,L1-dcache-loads对比优化前后硬件事件，确认是否减少缓存失效
最常被忽略的一点：CPU 密集型任务的“快”，不取决于开了多少 goroutine，而取决于有没有让每个物理核心持续吃满、数据是否留在本地缓存、中间结果是否逃逸到堆上。调优不是调参数，是调数据流和控制流的走向。
