runtime.gomaxprocs仅控制调度器p的数量，不绑定物理cpu核心；真要绑核需用taskset、cpuset或syscall.schedsetaffinity，且gomaxprocs值不应超过实际可用核心数，否则加剧调度竞争。
别指望 runtime.GOMAXPROCS 能“绑定”到某几个物理 CPU 核心上——它控制的是 Go 调度器里 P（Processor）的数量，不是操作系统层面的 CPU 亲和性（CPU affinity）。真要硬绑核，得用 syscall.SchedSetaffinity 或容器级配置，runtime 包本身不提供该能力。
为什么 GOMAXPROCS 不等于“分配给 Go 的 CPU 核心”
runtime.GOMAXPROCS 设置的是 P 的最大数量，每个 P 是一个调度逻辑单元，用来管理 goroutine 队列、内存缓存等。它不指定运行在哪颗物理核上，也不阻止 OS 把 M（OS 线程）调度到任意可用核心。即使你设 GOMAXPROCS=2，Linux 仍可能把两个 M 轮转在 8 个逻辑核之间，甚至同一核上切来切去。
常见误判现象：
- 以为设了
GOMAXPROCS=4就占满 4 核，结果top显示 CPU 利用率才 15% 在
go tool trace 里看到多个 P 处于 idle 状态，但系统负载低、goroutine 却卡在 chan send 或 netpoll用 taskset -c 0,1 ./myapp 启动后，再设 GOMAXPROCS=8，程序反而更慢——P 数远超可调度资源
想真正限制/隔离硬件 CPU，得绕过 runtime
Go 运行时不介入 CPU 亲和性控制，必须由外部手段实现：
- 启动前用
taskset：比如只允许在核心 0 和 1 上跑，taskset -c 0,1 ./myapp容器中通过
cpuset.cpus 限制：docker run --cpuset-cpus="0-1" ... 或 Kubernetes 的 resources.limits.ephemeral-storage 配合 cpuset cgroup在代码里调 syscall.SchedSetaffinity（需 import "syscall"），但注意：它作用于当前线程（即 main goroutine 所在的 M），无法保证后续新创建的 M 也绑在同一组核上；若要全局生效，得在 fork 子进程或 init 阶段做，且容易出错
⚠️ 注意：taskset 和 cpuset 是对整个进程生效，而 runtime.GOMAXPROCS 是对 Go 调度器内部 P 数量的软限制——两者维度不同，不能互相替代，但可以叠加使用。
混用 GOMAXPROCS 和 CPU 绑定时的关键约束
如果你既做了 CPU 绑定（如 taskset -c 0,1），又设了 GOMAXPROCS，那后者值不应超过绑定的核心数，否则会加剧争抢：
- 绑了 2 核，
GOMAXPROCS=8→ 8 个 P 竞争 2 个 M 的执行时间片，schedlat暴涨，go tool trace里大量P idle → runnable → idle循环 绑了 2 核，
GOMAXPROCS=2 → 理论上最匹配，但实际还要看 workload：I/O 密集型服务设 1 可能更稳绑了 4 核，但容器配额只有 cpu.cfs_quota_us=50000/cpu.cfs_period_us=100000（即 0.5 核），此时 GOMAXPROCS 设 4 完全没意义，应按配额换算后取整（→ 1）
真正起效的组合是：cpuset 或 taskset 控制硬件可见性 + GOMAXPROCS 匹配该可见范围内的有效并发槽位数。漏掉任一环，都可能让调度器在“以为有资源”和“实际被掐脖子”之间反复震荡。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
