Go程序默认支持多核，但调度单位是goroutine而非模块；关键在于GOMAXPROCS是否等于CPU核心数，且goroutine是否真正并行执行。
Go 程序默认就能用多核，但「模块」本身不参与调度——真正被调度的是 goroutine，而模块（package）只是代码组织单元，无运行时语义。所谓“模块调度均衡”，本质是搞清：你写的代码是否让 goroutine 被有效分发到多个 P（逻辑处理器）上执行。核心判断标准只有一个：runtime.GOMAXPROCS(0) 返回值是否等于你的 CPU 核心数，且 goroutine 是否真在并行干活。
runtime.GOMAXPROCS(0) 返回值不对怎么办
这是最常被忽略的起点。很多开发者直接跳过验证，默认认为“肯定用了多核”。但容器环境、CI/CD 构建镜像、或早期 init 阶段调用过 runtime.GOMAXPROCS 且未恢复，都可能导致值异常。
- 先加一行检查：
fmt.Println("GOMAXPROCS =", runtime.GOMAXPROCS(0)) - 对比
runtime.NumCPU()，若明显小于后者（比如返回 1，而NumCPU()是 8），说明被人为压低或继承了父进程限制 - 常见干扰源：
GOMAXPROCS=1环境变量、Docker--cpus=1限制、k8s Pod 的resources.limits.cpu小于 1（如500m），此时 Go 运行时可能读取 cgroup 并自动下调GOMAXPROCS - 修复方式：在
main()开头显式设回，如runtime.GOMAXPROCS(runtime.NumCPU())；但更推荐从环境层统一控制（比如 k8s 中设env: GOMAXPROCS）
goroutine 卡在 syscall 或锁里，P 就空转
即使 GOMAXPROCS 正确，CPU 利用率也可能长期低于预期。这时不是调度器没干活，而是 P 被阻塞住了——它等着某个 goroutine 从系统调用或锁竞争中回来，自己却不能去跑别的任务。
- 典型现象：
go tool trace中看到大量 P 处于Syscall或GC assist状态，但pprof显示runtime.futex或net.(*pollDesc).wait占比高 -
sync.Mutex争抢激烈时，goroutine 会进入gopark，P 挂起等待唤醒，不参与计算 - 频繁小对象分配（如循环里
make([]byte, 128)）触发 GC，STW 阶段所有 P 暂停，CPU 利用率断崖下跌 - 解决方向：用
sync.RWMutex替代读多写少场景的sync.Mutex；对高频分配对象使用sync.Pool；I/O 密集型任务改用带超时的非阻塞调用或连接池复用
并发任务没切片，全挤在一个 P 上跑
一个常见误区：起了 100 个 goroutine，就以为能自动摊到 8 个 P 上。但如果这 100 个 goroutine 全在做串行计算（比如单个大循环里不断累加），它们仍会被调度到同一个 P 的本地队列，根本不会触发跨 P 并行。
立即学习“go语言免费学习笔记（深入）”；
- 必须显式拆分工作单元，例如按数据分块：
chunkSize := len(data) / runtime.NumCPU()，再为每块启一个 goroutine - 避免共享状态：如果所有 goroutine 都在更新同一个
int变量，实际仍是串行，还要加锁，反而更慢 - channel 收发不是万能的：用无缓冲 channel 做同步，容易造成 goroutine 阻塞排队，P 等待对方就绪；改用带缓冲 channel 或批量处理减少同步频次
- 示例反模式：
for i := 0; i —— <code>sum竞争 + 闭包捕获问题，完全无法并行
混部环境下硬编码 GOMAXPROCS 是灾难
在 Kubernetes 或 Docker 中，容器看到的 CPU 核心数（runtime.NumCPU()）往往远大于它实际能用的配额。比如宿主机 64 核，但 Pod limits.cpu=2，此时 NumCPU() 仍返回 64，硬编码 runtime.GOMAXPROCS(64) 会导致调度器创建远超可用资源的 P，频繁上下文切换，性能暴跌。
- 正确做法：优先读取 cgroup 限制，例如解析
/sys/fs/cgroup/cpu/cpu.cfs_quota_us和cpu.cfs_period_us计算实际可用核数 - 更简单方案：信任环境变量，启动时检查
os.Getenv("GOMAXPROCS")，有值则用，否则 fallback 到runtime.NumCPU() - 绝对不要在代码里写死
runtime.GOMAXPROCS(8)—— 它在 4 核机器上浪费资源，在 16 核机器上锁死伸缩性 - 验证手段：部署后立刻查
go tool pprof http://localhost:6060/debug/pprof/goroutine?debug=2，看 goroutine 分布是否均匀
真正决定多核利用率的，从来不是模块怎么写，而是 goroutine 怎么切、怎么通信、怎么避坑。调度器很聪明，但不会替你把串行逻辑改成并行——它只负责把已经 ready 的 goroutine 尽快扔到空闲的 P 上。卡点永远在业务代码层：锁、GC、I/O、还是那句老话——go tool trace 看一眼 Proc Status 图，比猜三天更有用。
