本文解析 Go 在 GOMAXPROCS=1 下仍能实现 goroutine 并发执行的原因，阐明 Go 调度器的协作式特性、调度点的作用，以及为何看似“阻塞”的 CPU 密集型循环实际可能让出执行权，并给出避免调度饥饿的专业实践。
本文解析 go 在 `gomaxprocs=1` 下仍能实现 goroutine 并发执行的原因，阐明 go 调度器的协作式特性、调度点的作用，以及为何看似“阻塞”的 cpu 密集型循环实际可能让出执行权，并给出避免调度饥饿的专业实践。
Go 的并发模型常被误解为“依赖多核才能并行”，但其本质是基于 M:N 调度器的协作式并发（cooperative concurrency），而非操作系统级抢占式多任务。即使设置 runtime.GOMAXPROCS(1)，程序依然能交替执行多个 goroutine——这并非因为 CPU 时间片被内核强制切分，而是因为 Go 运行时在特定安全点（scheduling points）主动让渡控制权，使调度器得以切换 goroutine。
关键在于：GOMAXPROCS=1 仅限制同时执行用户 Go 代码的 OS 线程数量为 1，而非禁用所有线程。Go 运行时始终使用多个系统线程（如网络轮询器 netpoll、垃圾回收器、信号处理等），而调度器正是利用这些隐式并发能力，在单个 P（Processor）上实现逻辑并发。
在你的示例中，test() 函数看似是 CPU 密集型循环，但由于内部调用了 fmt.Println（底层涉及内存分配、锁操作、系统调用等），它天然包含多个调度点：
func test() {
a := 100
for i := 1; i < 1000; i++ {
a = i*100/i + a
fmt.Println("value: ", a) // ← 此处触发调度：内存分配 + I/O + 锁竞争 → runtime·morestack → 调度器介入
}
}每次 fmt.Println 执行时，运行时可能触发栈扩容、堆分配（触发 GC 检查）、或系统调用（如写入 stdout 的 write 系统调用），这些操作均构成隐式调度点，使当前 goroutine 暂停，调度器得以唤醒 test2 并继续执行。
⚠️ 但一旦移除 fmt.Println（如更新后的测试），test() 变成纯计算型空循环：
func test() {
a := 100
for i := 1; i < 1000; i++ {
a = i*100/i + a // 无函数调用、无内存分配、无系统调用
}
}此时循环体高度内联且无任何调度点，goroutine 将持续独占 P，导致：
- 其他 goroutine（如 test2）长期无法获得执行机会；
- 垃圾回收器无法进入 STW（Stop-The-World）阶段，因 GC 需要所有 P 暂停用户代码；
- 调度器“饿死”，表现为 test2 输出停滞。
✅ 正确解法：对长时 CPU 密集型任务，显式让出控制权：
import "runtime"
func cpuBoundTask() {
for i := 0; i < 1e9; i++ {
// 核心计算...
if i%1000 == 0 { // 每千次迭代主动让渡
runtime.Gosched() // 协作式让出 P，允许其他 goroutine 运行
}
}
}runtime.Gosched() 不会挂起 goroutine，而是将其放回全局运行队列，由调度器择机重新调度——这是 Go 中应对 CPU 饥饿的标准模式。
? 总结要点：
- Go 并发 ≠ 并行；GOMAXPROCS=1 下仍可并发，依赖调度点而非时间片；
- fmt.Println 等标准库函数是天然调度点，因其隐含内存/IO/锁操作；
- 纯计算循环必须手动插入 runtime.Gosched() 或拆分为带 I/O/分配的子任务；
- 避免依赖未文档化的调度行为（如特定 Go 版本中某循环“恰好”被调度），始终以显式协作（Gosched、time.Sleep(0)、通道操作等）为准。
注：自 Go 1.14 起，运行时引入异步抢占（asynchronous preemption），通过系统信号中断长时间运行的 goroutine，缓解部分调度饥饿问题，但不改变协作式设计哲学——Gosched 仍是推荐的、可预测的控制手段。
