gomaxprocs设为1后程序更慢，因所有goroutine只能在一个p上串行执行，无法利用多核并行能力；容器中常读到宿主机核数是因早期cgroups未暴露限额，fallback至系统在线核数。
为什么 GOMAXPROCS 设成 1 之后程序反而更慢？
因为 Go 运行时默认把 GOMAXPROCS 设为机器 CPU 逻辑核数，调度器会尽量让多个 G（goroutine）并行运行在多个 P（processor）上。设成 1 后，所有 goroutine 只能排队在一个 P 上执行，即使有空闲 CPU 核也用不上——这不是“单线程安全”，是主动放弃并行能力。
- 常见错误现象：
time.Sleep或网络调用没明显阻塞，但整体吞吐掉一半以上 - 适用场景：调试竞态、强制串行化初始化逻辑、嵌入式设备资源受限时手动压低并发度
- 注意：
runtime.GOMAXPROCS(1)不影响go关键字启动 goroutine 的行为，只限制可同时执行的 OS 线程数 - 性能影响：CPU 密集型任务基本线性退化；I/O 密集型可能影响小些，但调度延迟会上升
GOMAXPROCS 在容器里为什么总是读到宿主机核数？
Go 1.5+ 默认通过 /proc/sys/kernel/ns_last_pid 或 /sys/fs/cgroup/cpu/cpu.cfs_quota_us 推断可用 CPU 数，但早期容器（尤其未配 cpus 或 cpu-quota）不暴露这些值，运行时 fallback 到 sysconf(_SC_NPROCESSORS_ONLN)——也就是宿主机的逻辑核数。
- 典型表现：Kubernetes Pod 限制了
resources.limits.cpu: "2"，但runtime.GOMAXPROCS()返回 64 - 解决办法：启动前显式设置环境变量
GOMAXPROCS=2，或代码里尽早调用runtime.GOMAXPROCS(2) - 注意：必须在
main函数开头、任何 goroutine 启动前设置，否则部分 runtime 初始化已按旧值完成 - 兼容性：Docker 20.10+、containerd 1.5+ 对 cgroups v2 支持更好，能更准识别限额，但仍建议显式覆盖
什么时候不该碰 GOMAXPROCS？
绝大多数服务不需要改。Go 调度器在大多数负载下比人工调优更稳——它会动态调整 goroutine 在 P 上的分布，还处理了系统调用阻塞、网络轮询、定时器等复杂协同。
- 别动的信号：
pprof显示scheduler相关指标（如goroutines,gc pause）正常，top -H看线程数稳定在预期范围 - 容易踩的坑：在 HTTP handler 里反复调用
runtime.GOMAXPROCS(n)，导致调度器状态混乱，甚至 panic - 参数差异：
GOMAXPROCS是整数，不能设小数（比如"1.5"会解析失败，回退到默认值） - 一个硬限制：最大值不能超过 256（Go 1.19+），超限会静默截断，不报错也不警告
怎么验证当前生效的 GOMAXPROCS 值？
别信文档或配置文件，直接看运行时返回值最可靠。注意区分「设置值」和「实际生效值」——后者可能被 runtime 内部修正过。
立即学习“go语言免费学习笔记（深入）”；
- 最简方式：
fmt.Println(runtime.GOMAXPROCS(0))，传 0 表示只读不设，返回当前值 - 调试技巧：在
init()和main()开头都打一次日志，确认没被其他库意外覆盖 - 错误信息示例：
runtime: failed to create new OS thread (have 10, limit 10)往往意味着GOMAXPROCS设太小，P 不够用，新 goroutine 卡住 - 生产建议：用
expvar暴露该值，和runtime.NumGoroutine()一起看，能快速判断是否因并发瓶颈卡住
GOMAXPROCS 调再准也没用。 
