golang怎么跑满cpu

你看到的“没跑满”CPU，几乎肯定不是Go调度器的问题，而是你的goroutine被I/O、锁、GC或者串行逻辑卡住了。程序默认就能把CPU跑满，这才是它的本职工作。

runtime.GOMAXPROCS 是不是设低了？

先说一句：绝大部分场景下，你根本不用碰它。自从Go 1.5以后，默认值就等于runtime.NumCPU()，也就是逻辑核数。举个例子，一台8核16线程的机器，你调用runtime.GOMAXPROCS(0)返回16，这完全正常。

但如果你非要手动设置，有几个风险值得留意：

• 只有两种特殊情况才需要干预：一种是容器里被cfs_quota_us限制了核数，但Go程序没感知到（常见于旧版Go配合cgroup v2时）；另一种是启动早期要做大量初始化，想避免抢占业务P。
• 硬编码runtime.GOMAXPROCS(8)是一种危险操作——在4核机器上会造成调度资源浪费，而在16核机器上又根本用不满。所以，这个值最好让它自动适配。
• 还有一点：千万别在程序运行中反复调用这个函数，它会重置调度器状态，引起短暂的系统抖动。

goroutine 堆得多 ≠ CPU 就会满载

我们再来聊一个常见的误区：goroutine多，不代表CPU利用率就高。恰恰相反，大量goroutine挤在一起，反而会让P（处理器）长期处于Idle或Syscall状态，CPU利用率却上不去。

常见的卡点有哪些？

• 同步I/O：比如你没有设置超时的http.Get，或者无缓冲channel的发送端阻塞了，这会让绑定的P空转等待。
• 锁竞争：当sync.Mutex争抢激烈时，你会在pprof里看到runtime.futex的占比居高不下，这说明大量线程都在等着被唤醒。
• 伪忙等：有人在循环里写time.Sleep(1 * time.Nanosecond)或者干脆写个select {}，看似在“空转”，实际上阻塞了M（线程），导致其他M也闲置。
• 高频小对象分配：比如在循环里频繁调用make([]int, 10)，这会给GC带来巨大压力，STW（ Stop-The-World）时间一长，P就会被强制暂停。

CPU 密集任务：分块也得讲方法

那CPU密集型的任务，到底应该怎么分配才合理？一个常见错误是，把一个大数组切成1000份，然后扔给1000个goroutine。这会引发严重的调度开销和缓存失效，得不偿失。

正确的策略是按物理核数分块：

• 对于纯计算任务，比如矩阵运算、加密哈希，worker数量应该设为物理核数（而非逻辑核数），这样做是为了避免L3缓存污染。
• 确保每份数据都独立处理，最终结果写入一个预分配好的切片对应区间，全程都不需要加锁。
• 用sync.WaitGroup来等待任务结束，别用errgroup.Group或者channel去收集结果，那样会引入额外的同步成本。
• 对于高频使用的临时对象，比如buffer，记得用sync.Pool来复用，避免每次分配都触发GC。

怎么确认瓶颈真在 CPU？

别光盯着top里的CPU使用率低，就急着去调GOMAXPROCS。先拿出工具来精准定位：

• 用go tool trace看“Proc Status”图：如果你发现大量P都处于Idle或Syscall状态，那说明瓶颈在I/O或锁，而不是CPU不够。
• 用go tool pprof抓一下profile，比如go tool pprof http://localhost:6060/debug/pprof/profile?seconds=30，然后输入top -cum：重点关注真实耗时的函数栈。如果发现runtime.mallocgc占比很高，就该去查查自己哪段代码在拼命new对象了。
• 如果发现net.(*pollDesc).wait的消耗很高，说明是网络I/O瓶颈。这时候加CPU核数没用，应该去调整连接池大小，或者考虑换用异步模型。

其实，最难的不是解决“CPU没跑满”，而是区分“CPU没跑满”和“CPU没被有效利用”。前者是调度问题，后者是代码结构问题。大多数时候，删掉几个锁、复用两块内存、把循环拆成合适的粒度，这些调整比改任何一个参数都来得立竿见影。