go程序默认能跑满cpu，所谓“没跑满”通常是因i/o、锁、gc或串行逻辑阻塞goroutine；runtime.gomaxprocs默认为逻辑核数，仅在cgroup限核未感知或早期初始化时需干预，错误设置会引发调度开销或资源浪费。
Go 程序默认就能跑满 CPU，但你看到的“没跑满”，几乎一定是代码没真正并行起来——不是调度器不行，而是你的 goroutine 被 I/O、锁、GC 或串行逻辑卡住了。
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 堆在一起，反而让 P 长期 idle 或 syscall 状态，CPU 利用率却上不去。常见卡点：
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 同步 I/O：比如没设超时的
http.Get、无缓冲 channel 的发送阻塞，会让绑定的 P 空转等待 - 锁竞争：
sync.Mutex争抢激烈时，pprof 里runtime.futex占比高，说明线程在等唤醒 - 伪忙等：循环里写
time.Sleep(1 * time.Nanosecond)或select {}，看似“空转”，实则阻塞 M，其他 M 没活干 - 高频小对象分配：比如循环里
make([]int, 10)，GC 压力大，STW 时间变长，P 被强制暂停
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 http://localhost:6060/debug/pprof/profile?seconds=30后输入top -cum：看真实耗时函数栈；若runtime.mallocgc占比高，该查自己哪段代码在狂 new - 发现
net.(*pollDesc).wait高，说明是网络 I/O 瓶颈，加核没用，该调连接池或换异步模型
真正难的是区分“CPU 没跑满”和“CPU 没被有效利用”——前者是调度问题，后者是代码结构问题。多数时候，删掉几个锁、复用两块内存、把循环拆对粒度，比调任何参数都管用。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
