Go 采用协作式调度机制，goroutine 必须在特定点主动让出 CPU；若长时间纯计算无调用、无阻塞，则可能独占线程导致其他 goroutine 饥饿，即使 GOMAXPROCS > 1 也无法完全避免。
go 采用协作式调度机制，goroutine 必须在特定点主动让出 cpu；若长时间纯计算无调用、无阻塞，则可能独占线程导致其他 goroutine 饥饿，即使 `gomaxprocs > 1` 也无法完全避免。
在 Go 中，“goroutines are cooperatively scheduled” 并不意味着它们像传统协程那样严格按顺序轮转执行，而是一种有边界的协作机制：运行时（runtime）仅在少数预定义的“安全点”（safepoints）上检查是否需调度切换，例如：
- 调用函数（尤其是可能触发栈扩容、内存分配或系统调用的函数，如 fmt.Println）
- 执行 channel 操作（send/receive）
- 进行网络或文件 I/O
- 调用 time.Sleep、runtime.Gosched() 等显式让出操作
- 垃圾回收相关暂停点
这意味着：纯 CPU 密集型循环（如 for i := 0; i ——只要该 goroutine 不进入上述任一安全点，它就将持续占用当前 M（OS 线程），其他就绪 goroutine 将无法获得执行机会，即发生 goroutine starvation（饥饿）。
以问题中的示例为例：
func sum(x int) {
sum := 0
for i := 0; i <pre class="brush:php;toolbar:false;">go sum(100)
go sum(200)
go sum(300)
go sum(400)看似四个 goroutine 并发启动，但实际执行行为高度依赖 fmt.Println 的内部实现与 Go 版本：
- 在较新 Go 版本（1.14+）中，fmt.Println 内部包含多次函数调用、内存分配及锁操作，极大概率在执行过程中触发 runtime 调度检查（如栈增长检测），从而让出 CPU，使其他 goroutine 得以穿插执行；
- 若将 fmt.Println(sum) 替换为纯计算（如 sum = sum * 1 循环内），且循环次数极大（如 i
- 即使设置 GOMAXPROCS > 1，也不能完全规避饥饿：因为 GC 阶段需要 STW（Stop-The-World）或辅助标记，可能迫使所有 P（Processor）暂停用户代码；更关键的是，若所有 goroutine 都陷入无安全点的死循环，整个程序仍会卡死——Go 调度器不提供强制抢占（preemption）保障（尽管自 Go 1.14 起已引入基于信号的轻量级协作式抢占，但仅覆盖部分场景，如长时间运行的 for {} 或函数调用链过深，并非通用硬实时抢占）。
✅ 正确应对策略：
-
避免纯计算长循环：对大循环加入显式让出点
for i := 0; i
-
利用 I/O 或 channel 自然让出：将计算任务与 I/O 解耦，或通过 channel 控制节奏
ch := make(chan struct{}, 1) go func() { defer close(ch) // 重计算逻辑 time.Sleep(0) // 触发调度（等价于 Gosched） }() 使用 context.Context + select 实现可取消/超时控制，尤其适用于长期运行任务；
监控 goroutine 数量与状态：通过 debug.ReadGCStats、pprof 或 runtime.NumGoroutine() 及时发现泄漏或饥饿迹象；
理解 GOMAXPROCS 的真实作用：它限制的是可并行执行的 OS 线程数（M）上限，而非调度公平性保障——增加 M 可缓解 I/O 密集型竞争，但无法解决单个 M 上的纯计算饥饿。
⚠️ 重要提醒：
Go 的调度行为属于运行时实现细节，未被语言规范保证。开发者不应依赖特定版本中 fmt 或其他标准库函数的“副作用”来实现并发公平性。真正的健壮并发设计，必须显式引入让出点、合理使用 channel 同步、配合 sync.WaitGroup 或 context 控制生命周期，并通过压力测试验证 goroutine 行为。
简言之：协作式 ≠ 友好式；调度器尽力而为，但责任在开发者——写出让渡机会的代码，才是 Go 并发安全的基石。
