GOMAXPROCS=1 不等于单线程，因系统调用时 M 脱离 P 并阻塞，调度器可唤醒新 M 继续执行其他 G；调度核心 runtime.findrunnable() 按本地队列→全局队列→偷取顺序获取 G；P 的 _Psyscall 状态下本地队列仍可被窃取，保障阻塞不影响调度；goroutine 抢占为协作式，依赖函数调用或栈检查触发让出。
Go 的 GPM 调度器不是“黑盒”，它是一套有明确状态流转、可观察、可干预的运行时机制；理解它不靠背概念，而靠看 runtime 中几个关键函数的行为和条件分支。
为什么 GOMAXPROCS 设置为 1 时并发代码仍可能并行执行
很多人误以为设 GOMAXPROCS=1 就等于“单线程”，但实际并非如此。当 Goroutine 进入系统调用（如 read、accept、netpoll）时，绑定的 M 会脱离 P 并阻塞，此时调度器会唤醒或新建一个 M 绑定到该 P 上继续执行其他 G —— 这个过程不依赖 CPU 核心数，只依赖是否有空闲 M 可用。
这意味着：
-
GOMAXPROCS=1限制的是“同时运行的非阻塞G数量”，不是“总并发能力” - 网络 I/O 密集型程序在
GOMAXPROCS=1下仍可能看到多核 CPU 利用率上升，本质是多个M在不同系统调用中并行阻塞/唤醒 - 真正串行化执行需配合
runtime.LockOSThread()或手动控制临界区
runtime.findrunnable() 是调度循环的核心入口
所有 M 的调度逻辑最终都会落入 runtime.findrunnable() —— 它不是“找一个 G 执行完就结束”，而是按固定优先级尝试获取可运行的 G：
立即学习“go语言免费学习笔记（深入）”；
- 先查当前
P的本地队列（runq），无锁、最快 - 再检查全局队列（
global runq），需加锁，每 61 次调度才轮询一次 - 若仍为空，则启动
stealWork()：随机选一个其他P，从其本地队列尾部偷一半G - 最后检查是否有被抢占的
G或 GC 相关任务需要插入
这个顺序决定了：本地队列满时新 G 不会立刻被偷走，而是先进全局队列；而空闲 P 偷取失败后可能直接进入自旋或休眠，而非立即创建新 M。
P 的四种状态直接影响调度行为
P 不是静态容器，它在 _Pidle、_Prunning、_Psyscall、_Pgcstop 之间切换，每种状态触发不同逻辑：
-
_Pidle：P 空闲等待分配，此时M可能正在休眠或刚被创建，等待绑定 -
_Prunning：正常执行状态，findrunnable()持续工作 -
_Psyscall：对应M正在执行系统调用，此时该P不参与任何队列操作，但其本地队列仍可被其他M偷取 -
_Pgcstop：GC 暂停期间强制所有P进入此状态，防止新G被调度，保证 STW 安全
特别注意：_Psyscall 状态下 P 不会释放，但它的本地队列仍可被窃取 —— 这是 Go 实现“M 阻塞不影响其他 G 调度”的关键设计，也是容易被忽略的性能支点。
goroutine 抢占不是定时中断，而是协作式信号触发
Go 1.14+ 后，抢占由独立的监控线程通过 retake() 实现，但它不直接中断正在运行的 G，而是设置 G.preempt 标志位，等待该 G 下一次函数调用或循环边界处主动让出 —— 这就是“协作式抢占”。
这意味着：
- 纯计算型死循环（无函数调用、无栈增长检查）可能长期不被抢占，导致其他
G饥饿 -
runtime.Gosched()是显式让出点，但编译器会在循环体中自动插入栈检查（stackguard），形成隐式让出机会 - 抢占延迟取决于代码结构，不是固定 10ms；实测中常见 10–20ms 波动，极端情况可达数百毫秒
真正影响调度公平性的，从来不是理论上的“10ms”，而是你写的代码里有没有足够多的函数调用边界或栈增长点。
