GOMAXPROCS 直接关系到：
Go 程序到底能不能“真正并行”。
一句话先说结论
GOMAXPROCS 决定：
同一时间最多有多少个 goroutine 可以并行运行（占用 CPU）。
更准确说：
它决定 P（Processor）的数量。
一、回忆一下 GMP 模型
我们之前讲过：
G = goroutine（任务）
M = 线程（干活的）
P = 调度资源（必须持有才能执行 G）
关键规则：
M 必须拿到 P 才能执行 G
而：
P 的数量 = GOMAXPROCS
二、默认值是多少？
从 Go 1.5 开始：
默认情况下：
GOMAXPROCS = 当前机器可用的 CPU 核心数
更准确地说：
Go 会设置为“当前进程可用的逻辑 CPU 数量”。
默认会把所有可用 CPU 都用上。
什么是“逻辑 CPU”？
不是物理核心数，而是：
-
包含超线程（Hyper-Threading）
-
包含容器 / cgroup 限制后的 CPU 数
例如：
-
4 核 8 线程的机器
→ 默认可能是 8 -
Docker 限制 2 核
→ 默认是 2
例如：
- 4 核 CPU → 默认 GOMAXPROCS = 4
- 8 核 CPU → 默认 GOMAXPROCS = 8
你可以打印看看：
fmt.Println(runtime.GOMAXPROCS(0))
传 0 表示“只读取，不修改”。
从 Go 1.5 开始：
-
默认值改为
runtime.NumCPU() -
不再默认 1
在 Go 1.5 之前：
默认是 1
那时多核不会自动利用。
三、它真正控制的是什么？
很多人误解为：
控制 goroutine 数量 ❌
不是。
它控制的是：
最多同时运行的 goroutine 数量
举个例子：
你开 1000 个 goroutine。
如果：
GOMAXPROCS = 1
那：
- 任何时刻只有 1 个 goroutine 在真正跑
- 其他 999 个在排队
如果：
GOMAXPROCS = 4
那：
- 最多 4 个 goroutine 同时跑在 4 个 CPU 上
四、一个直观类比
想象：
- goroutine 是工人
- CPU 是机器
- P 是机器许可证
你可以雇 1000 个工人（goroutine）
但如果：
只有 4 台机器（P=4）
同时只能 4 个工人干活。
五、代码示例
package mainimport ("fmt""runtime"
)func main() {fmt.Println("Before:", runtime.GOMAXPROCS(0))runtime.GOMAXPROCS(2)fmt.Println("After:", runtime.GOMAXPROCS(0))
}
六、它和并发 vs 并行的关系
并发（concurrency）
- 可以同时管理很多任务
- 但未必同时运行
并行（parallelism）
- 真正同时运行在多个 CPU 上
GOMAXPROCS 决定：
并行度
七、如果设为 1 会发生什么？
runtime.GOMAXPROCS(1)
效果：
- 所有 goroutine 在一个 P 上调度
- 仍然可以并发
- 但不可能多核并行
常用于：
- 调试调度问题
- 复现竞态条件
八、为什么不直接用 CPU 核心数？
其实默认就是。
但有些情况你可能想：
- 限制 CPU 使用
- 容器环境限制 CPU quota
- 做性能测试
例如：
GOMAXPROCS=2 ./app
也可以通过环境变量设置。
九、重要理解：P 数量 = GOMAXPROCS
回忆：
一个 P 只能被一个 M 持有
一个 P 同时只能运行一个 G
所以：
最多并行数 = P 数量 = GOMAXPROCS
十、常见误区
❌ 误区 1：GOMAXPROCS 控制 goroutine 总数
→ 错，它只控制同时运行数量
❌ 误区 2：开大一定更快
→ 不一定
如果：
- CPU 只有 4 核
- 你设为 100
会：
- 频繁上下文切换
- cache 失效
- 性能反而下降
十一、容器里的坑
在 Docker 里：
如果容器限制 CPU 为 2 核，
但宿主机是 16 核，
老版本 Go 可能仍然认为有 16 核。
新版本 Go 会自动识别 cgroup 限制。
十二、终极总结
可以记住这句话：
GOMAXPROCS 决定 Go 程序能同时使用多少个 CPU 核心。
或者更精确：
它决定 P 的数量，而 P 决定最大并行度。