是的，M 在进入 OS 线程休眠前必须释放 P，否则会阻塞其他就绪 G 的执行；典型路径为 schedule() → stopm() → handoffp() → notesleep()，仅 sysmon 线程例外。
Go 调度器中 M 进入休眠前必须释放 P 吗？
是的，M 在真正进入 OS 线程休眠（如调用 epoll_wait、nanosleep 或阻塞系统调用）前，必须先解绑当前持有的 P。这不是可选优化，而是调度器正确性的强制要求。
原因很简单：一个 P 只能被一个 M 持有，而 Go 允许大量 M（远超 CPU 核数）存在；若阻塞的 M 一直占着 P，其他就绪的 G 就无法运行。
典型路径是：schedule() → 发现无就绪 G → 调用 stopm() → 在 stopm() 中显式调用 handoffp() 归还 P → 才调用 notesleep() 或转入系统调用阻塞。
- 常见错误现象：
runtime: m0 has no p或死锁在findrunnable()循环里，往往是因为某处绕过了handoffp() - 注意
sysmon线程是个例外：它不绑定P，也不参与常规调度，因此不会走这套休眠流程 -
netpoll阻塞时（如epoll_wait）也遵循该逻辑，归还P后才等待事件
唤醒 M 的两种主要触发方式及对应代码路径
Go 不依赖外部信号“主动唤醒”休眠的 M，而是靠事件驱动：要么有新 G 就绪，要么有系统事件（如网络 I/O 完成）需要处理。唤醒本质是让某个休眠的 M 重新获取 P 并开始执行 schedule()。
关键入口函数是 startm()，它负责从空闲 M 列表（allm 中的 next 链或 idlems）拉起一个 M，并尝试分配 P。是否真能唤醒，取决于是否有可用 P 和是否需要新建 M。
- 网络 I/O 完成：在
netpoll()返回后，调用injectglist()将就绪G加入全局队列或某P的本地队列，再调用addtimer(&netpollTimer)或直接startm(nil, false)尝试唤醒空闲M - 新 Goroutine 创建：当
G被创建且当前无空闲P可用时，可能触发startm()新建或唤醒一个M - 注意：唤醒不等于立即执行——
M被notesleep()唤醒后，仍需竞争获取P，失败则再次休眠
为什么有时看到 M 休眠却没立刻被唤醒，即使有 G 就绪？
根本原因是 P 数量不足或分配延迟，而非唤醒机制失效。Go 默认限制最大 P 数为 GOMAXPROCS，所有就绪 G 必须依附于某个 P 才能被执行。
例如：设 GOMAXPROCS=4，已有 4 个 M 各持一个 P 并处于计算密集型循环中，此时新 G 被加入全局队列，但没有空闲 P 可分配，startm() 就不会触发（除非配置了 forceNewM = true）。
- 典型表现：
runtime/pprof显示大量G在runnable状态但 CPU 使用率低 - 排查建议：检查
GOMAXPROCS是否被意外设为 1，或是否存在长期未释放P的 Cgo 调用（如未调用runtime.UnlockOSThread()） - 性能影响：P 不足会人为制造调度瓶颈，使就绪
G在队列中等待，增加尾延迟
调试 M 休眠/唤醒行为的实用手段
Go 运行时本身不提供“M 睡了多久”这种指标，但可通过组合工具和日志定位异常休眠点。
最直接的方式是启用调度器跟踪：GODEBUG=schedtrace=1000（每秒打印一次调度器状态），观察 M 数、P 数、G 状态分布。重点关注 idle 和 dead 的 M 是否持续增长。
- 用
strace -p查看 OS 层线程是否真在休眠，以及休眠时长-e trace=epoll_wait,nanosleep,clone - 在关键路径插入
runtime.ReadMemStats()+ 时间戳，辅助判断是否卡在某次stopm()调用后未被唤醒 - 注意：
pprof的goroutineprofile 显示的是快照，无法反映M休眠历史；需结合schedtrace和系统调用跟踪交叉验证
真正难调试的，是那种“P 被隐式占用”导致唤醒链断裂的情况——比如 Cgo 函数忘记解锁线程，或 syscall.Syscall 返回后未及时调用 acquirep()。这类问题不会报错，只会让调度器悄悄降频。
