goroutine 并非传统意义上的“协作式调度”（cooperative scheduling），而是以协作点为基础、辅以系统级抢占的混合调度模型；长时间纯计算循环（如 for {} 或密集数学运算）若无函数调用或阻塞操作，确实可能造成调度饥饿，但现代 go 运行时（1.14+）已通过栈增长检查、sysmon 监控和异步抢占机制显著缓解该问题。
goroutine 并非传统意义上的“协作式调度”（cooperative scheduling），而是以协作点为基础、辅以系统级抢占的混合调度模型；长时间纯计算循环（如 for {} 或密集数学运算）若无函数调用或阻塞操作，确实可能造成调度饥饿，但现代 go 运行时（1.14+）已通过栈增长检查、sysmon 监控和异步抢占机制显著缓解该问题。
在理解 Goroutine 调度行为前，需先破除一个常见误解：Go 的调度不是纯粹的协作式（cooperative），也不是完全的抢占式（preemptive）——它是一种协作点触发 + 异步抢占辅助的混合模型。
为什么“纯计算循环”曾导致饥饿？
早期 Go 版本（<1.14）中，调度器仅在明确的“协作点”（yield points）主动让出控制权，例如：
- time.Sleep()
- channel 收发操作（阻塞时）
- 网络/文件 I/O（由 runtime 封装为非阻塞 + netpoller 回调）
- runtime.Gosched() 显式让渡
- 函数调用（尤其是可能触发栈扩容的调用，如 fmt.Println）
因此，如下代码存在严重调度风险：
func cpuBound(x int) {
sum := 0
for i := 0; i < x; i++ {
sum += i * i // 无函数调用、无阻塞、无 I/O
}
fmt.Println("done:", sum) // ← 关键：此处调用 fmt 触发调度机会
}若 x 极大（如 1e9），且 fmt.Println 尚未执行，该 goroutine 可能长期独占绑定的 M（OS 线程），导致同 P 下其他就绪 goroutine 饥饿——即使 GOMAXPROCS > 1，也因 GC 停顿或 sysmon 未能及时介入而加剧问题。
现代 Go 运行时如何解决“无限循环”问题？
自 Go 1.14 起，运行时引入异步抢占（asynchronous preemption），核心机制包括：
基于信号的抢占
sysmon 线程定期（默认 10ms）检查各 P 上正在运行的 G 是否超时（schedtick 长期未更新）。若检测到某 G 运行超过阈值，向其所在 M 发送 SIGURG 信号，强制中断当前执行并插入调度点。安全点（safe-point）插入
编译器在循环体头部自动插入抢占检查（如 runtime.preemptM 调用），尤其在 for 循环、range 迭代等结构中。只要循环体包含至少一个函数调用（哪怕是空函数），即可成为安全点。栈增长作为天然协作点
fmt.Println 等函数内部会检查栈空间，触发 runtime.morestack —— 此过程必然进入调度器，为其他 G 让出时间片。
✅ 验证示例（Go 1.20+）：
package main
import (
"fmt"
"runtime"
"time"
)
func busyLoop(id int, limit int64) {
var sum int64
for i := int64(0); i < limit; i++ {
sum += i
// 即使此处无显式调用，现代 runtime 也会在循环迭代间插入抢占检查
}
fmt.Printf("G%d done, sum=%d\n", id, sum)
}
func main() {
runtime.GOMAXPROCS(1) // 强制单线程复用
go busyLoop(1, 1e8)
go busyLoop(2, 1e8)
go busyLoop(3, 1e8)
// 等待所有 goroutine 启动
time.Sleep(10 * time.Millisecond)
fmt.Println("All goroutines launched")
time.Sleep(3 * time.Second) // 观察是否并发输出
}在 Go 1.20+ 中，该程序大概率会交错输出（如 G1 done...、G2 done... 交替出现），证明抢占生效；而在 Go 1.12 及更早版本中，通常表现为串行执行（G1 完全跑完才轮到 G2）。
开发者须知：最佳实践与注意事项
✅ 推荐做法：避免裸 for {}；对长耗时计算，主动插入 runtime.Gosched() 或拆分为小块 + time.Sleep(0)（后者隐式触发调度）。
⚠️ 不依赖调度时机：Go 不保证 goroutine 执行顺序或时间片分配，任何依赖“公平轮转”的逻辑都应使用 channel 或 sync 原语显式同步。
-
? 调试技巧：启用调度追踪定位饥饿：
GODEBUG=schedtrace=1000,scheddetail=1 go run main.go
观察 SCHED 日志中 idle, runnable, running G 的数量变化，判断是否存在长时间 running G。
-
? 关键结论：
Goroutine 的“协作式”本质在于调度决策由 runtime 主导，而非用户代码显式 yield；所谓“协作点”实为 runtime 插入的安全检查锚点。现代 Go 已通过异步抢占大幅降低纯计算饥饿风险，但编写可预测、可维护的并发代码，仍应优先采用 channel 通信与结构化同步，而非依赖调度器的“善意”。
简言之：你不必再为 for i := 0; i < 1e9; i++ 担心彻底锁死——但写这样的代码，本身已是设计缺陷的信号。
