系统调用会阻塞M但P不闲置，运行时自动转移P给其他M；netpoller通过事件驱动避免M阻塞；cgo调用不直接阻塞调度器但可能引发P解绑；需用GODEBUG和指标监控M堆积。
系统调用会让 M 阻塞，但 P 不会闲置
Go 程序执行 read、write、accept 等阻塞式系统调用时，当前绑定的 M（OS 线程）会被内核挂起，无法继续执行其他 G。但关键在于：这个 M 持有的 P 并不会被废弃，而是由运行时立即尝试“转移”给其他空闲或新建的 M。
这意味着：
- 只要还有可运行的 G 在该 P 的本地队列或全局队列中，调度器会唤醒或创建新 M 来接管它
- 若所有 P 都满载且无空闲 M，运行时才会新建 M（受
runtime.SetMaxThreads限制，默认上限约 10000） - 频繁阻塞调用会导致 M 数量阶段性上涨，但空闲时 sysmon 会回收多余 M
你不需要手动控制线程数，但要注意：大量长时阻塞调用（如同步文件读写、未设 timeout 的 DNS 查询）会让 M 持续堆积，增加上下文切换和内存开销。
netpoller 如何绕过 M 阻塞问题
Go 标准库中绝大多数 I/O（net.Conn、os.File 在非 O_DIRECT 模式下）都走 netpoller 路径，底层基于 epoll（Linux）、kqueue（macOS）等事件驱动机制。
立即学习“go语言免费学习笔记（深入）”；
这时的系统调用行为完全不同：
-
epoll_wait这类调用是非阻塞等待，M 不会真正挂起，而是在等待期间回归调度循环 - G 直接挂起在
sudog上，与 channel 类似，不占用 M 生命周期 - 当 fd 就绪，sysmon 或某个 M 触发回调，将对应 G 置为
Grunnable并入队
所以 http.Server 即使处理上万连接，通常也只用几十个 M —— 因为大部分时间 M 在轮询事件，而非卡在 read() 上。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
cgo 调用是否等同于系统调用？
不是。cgo 调用本身不触发 Go 调度器阻塞，但它可能间接引发阻塞行为，具体取决于 C 函数内部是否调用系统调用或长时间计算。
运行时对此有专门补偿机制：
- 初始阶段，该 G 仍绑定当前 M，并计入
GOMAXPROCS并发配额 - 若 C 函数执行超约 20 微秒（由 sysmon 周期检测），运行时会解绑 M 与 P，把 P 分配给其他就绪 G
- 原 M 继续执行 C 代码，但不再参与 Go 调度平衡；新 G 可在新 M 上启动
典型陷阱：C.sleep(5) 或 C.fread 同步读大文件，虽不锁死调度器，但会频繁触发 P 解绑/重绑定，带来额外调度抖动。应优先用 Go 原生 time.Sleep 或异步 I/O 替代。
如何验证当前调度状态是否受系统调用影响
直接看运行时指标比猜更可靠。启用 GODEBUG=schedtrace=1000 可每秒打印调度摘要：
SCHED 0ms: gomaxprocs=8 idleprocs=0 #threads=12 mprocs=8
重点关注：
-
#threads持续高于gomaxprocs，说明存在较多阻塞 M（如系统调用未返回） -
idleprocs=0但mprocs ，可能是部分 P 被卡住未释放 - 配合
runtime.ReadMemStats和debug.ReadGCStats排查是否因频繁 M 创建导致 GC 压力上升
真实场景中，最易被忽略的是：一个看似普通的 os.Open 在 NFS 或低性能存储上可能变成数秒级阻塞，它不走 netpoller，也不触发 cgo 补偿，就是实打实卡住一个 M —— 这类调用务必加 context 和 timeout 控制。
