gomaxprocs=1时goroutine仍可交替运行，因主动让出（如sleep、gosched、channel、系统调用）触发p交还控制权，实现单p上的并发调度，非并行；计算密集型循环无让出则无法切换。
P 的数量直接决定 Go 程序能并发执行多少 goroutine，但它不是 CPU 核心数的简单镜像，而是一个可调的逻辑调度单元上限。
为什么 GOMAXPROCS 设置为 1 时，两个 goroutine 还是可能交替运行？
即使 GOMAXPROCS(1)，只要 goroutine 主动让出（比如调用 time.Sleep、runtime.Gosched()、channel 操作或系统调用），当前 P 就会把控制权交还给调度器，从而切换到另一个就绪的 G。这不是并行（parallelism），而是并发（concurrency）——单个 P 上的时间片轮转。
- 计算密集型循环（如
for i := 0; i ）在 Go 1.14+ 会被 sysmon 线程定期发送 <code>SIGURG信号抢占，触发安全点检查，强制让出 P - 若函数内无函数调用、无栈增长、无阻塞点，抢占可能延迟数百毫秒，导致“饿死”其他 goroutine
-
runtime.LockOSThread()会绑定 M 到当前 OS 线程，但不改变 P 数量；若该 M 已绑定 P，则不影响调度逻辑
什么时候 P 会被真正“抢占”或释放？
P 不会被“抢占”，它本身不执行代码；P 是被 M 绑定/解绑的对象。所谓“P 被抢占”，实质是 M 解除了与当前 P 的绑定，并尝试绑定空闲 P 或进入休眠。
- M 在系统调用返回时，若原 P 已被其他 M 占用，会尝试获取空闲 P；失败则将 G 放入全局队列，M 进入休眠
- 当 GC STW 阶段启动，所有正在运行的 M 会被暂停，其绑定的 P 也被冻结，直到 STW 结束
- 若 M 执行阻塞式系统调用（如
read文件描述符未就绪），runtime 会将其与 P 解绑，让出 P 给其他 M 使用 -
runtime.GOMAXPROCS(n)调用会触发 P 数组重分配：若 n 减小，多余 P 进入空闲链表；若 n 增大，从空闲链表或新建 P 补足
调整 GOMAXPROCS 对性能的真实影响
盲目设高未必更好。P 过多会导致 work-stealing 频繁、本地队列利用率下降、cache line false sharing 加剧；P 过少则无法压满物理核，尤其在 I/O 密集 + 计算混合场景下容易成为瓶颈。
- 默认值（Go 1.5+）是机器可用逻辑 CPU 数，适用于大多数服务端程序
- CPU 密集型任务：P 接近物理核心数（而非超线程数）通常更稳；可用
runtime.NumCPU()获取参考值 - I/O 密集型任务：适当提高 P（如 ×1.5）有助于掩盖系统调用延迟，但超过 256 无效（
GOMAXPROCS硬上限） - 注意：修改
GOMAXPROCS只影响后续新创建的 M，已绑定的 M 不会立即重调度
真正容易被忽略的是：P 的本地队列长度只有 256，溢出任务会进全局队列——而全局队列访问需锁 gflock。这意味着，高频创建 goroutine 且不及时消费时，go f() 的开销会从 O(1) 退化为带锁的 O(log N)。别只盯着 P 数，先看你的 goroutine 是否“短命快消”。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
