纯计算循环会导致goroutine饿死，因无安全点使抢占失效；新goroutine需经本地/全局队列调度，延迟可达61次间隔；CGO阻塞时M可能被回收，唤醒延迟显著增加。
Go 的 goroutine 不会卡死线程，但会卡住你写的逻辑——根本原因不在协程本身，而在 GMP 调度模型中 P 被长期独占，以及你没给调度器留出“安全点”。
为什么纯计算循环会让其他 goroutine 彻底饿死
Go 1.14+ 虽然引入异步抢占，但它的触发依赖“函数调用”这个安全点。如果一个 for 循环里全是内联算术（比如 i++、a = b * c），又没调用任何函数，那 runtime 就没法插入抢占检查——哪怕 GOMAXPROCS 设为 8，那个 M 和它绑定的 P 也会被这一个 goroutine 锁死。
- 现象：启动两个 goroutine，一个死循环计数，另一个
time.Sleep(100 * time.Millisecond)后打印日志，后者永远不执行 - 本质：不是调度器“不干活”，而是它压根没机会中断当前 G
- 实操建议：
– 在长循环中显式插入runtime.Gosched()（每千次迭代一次足够）
– 或拆成小块，用select {}或time.Sleep(0)制造让出点
– 避免把耗时计算逻辑写在 goroutine 入口处，改用 worker pool 分片处理
新起的 goroutine 为啥迟迟不执行
刚调用 go f() 时，这个 G 并不直接上 CPU，而是先进队列：优先塞进当前 P 的本地队列（最多 256 个），满了就进全局队列。而全局队列要加锁，且只有当某个 P 的本地队列空了，才会去“搬活”——中间可能隔最多 61 次调度间隔（Go 运行时硬编码值）。
- 常见场景：HTTP handler 里每请求起一个 goroutine，QPS 高时大量 G 挤在全局队列，新来的 P（比如扩容后）得等几轮才分到任务
- 关键参数：
GOMAXPROCS决定 P 数量，默认等于 CPU 核数；设为 1 就只剩一个本地队列可调度，I/O 型并发直接退化为串行 - 实操建议：
– 控制 goroutine 创建节奏，别在循环里无节制go func(){}()
– 避免变量捕获错误（如共用for i := range xs中的i），这不是调度问题，但表现像“调度不均”
– 想减少全局队列依赖？复用 goroutine，比如用sync.Pool缓存或走 worker pool 模式
CGO 调用阻塞时为啥 goroutine 唤醒变慢
CGO 函数默认不被 Go 调度器感知。如果一个 goroutine 进入 CGO 并长时间阻塞（比如调用 C 的 sleep()），而你又没加 runtime.LockOSThread()，那运行它的 M 可能被 sysmon 线程判定为“空闲”并回收——等 C 函数返回时，M 找不到原 P，得重新绑定、抢锁、入队，延迟明显。
立即学习“go语言免费学习笔记（深入）”；
- 典型错误：C 函数里做同步等待，又忘了在 Go 层用
runtime.LockOSThread()绑定线程 - 后果：唤醒后要重新排队，甚至可能被丢进全局队列，比普通系统调用延迟高一个数量级
- 实操建议：
– 真需长时间阻塞 CGO，务必配对使用runtime.LockOSThread()和runtime.UnlockOSThread()
– 更推荐方案：把阻塞操作包进runtime.entersyscall()/runtime.exitsyscall()手动通知调度器（高级用法，慎用）
– 优先考虑用 Go 原生 I/O 替代 CGO，比如用net.Conn而非 C socket
调度不是魔法，它是 G、M、P 三者协作的动态平衡；你写的每一行代码，都在悄悄影响这个平衡的支点位置——最危险的，往往是那些看起来“什么都没做”的纯计算循环。
