本文深入解析 Go 在 GOMAXPROCS=1 下仍能实现 goroutine 并发执行的原因，阐明 Go 运行时的协作式调度本质——即使仅限单 OS 线程，I/O、函数调用、垃圾回收点等隐式调度点仍可触发协程切换，而纯忙等待循环则会饿死调度器。
本文深入解析 go 在 `gomaxprocs=1` 下仍能实现 goroutine 并发执行的原因，阐明 go 运行时的协作式调度本质——即使仅限单 os 线程，i/o、函数调用、垃圾回收点等隐式调度点仍可触发协程切换，而纯忙等待循环则会饿死调度器。
Go 的并发模型常被误解为“依赖多核才能并行”，但事实恰恰相反：Go 的并发（concurrency）不等于并行（parallelism）。GOMAXPROCS=1 仅限制同时执行用户 Go 代码的 OS 线程数量为 1，而非禁用调度器或冻结其他 goroutine。Go 运行时始终是多线程的（例如，网络轮询、定时器、垃圾收集均在独立系统线程中运行），而用户 goroutine 的调度由 Go 调度器（M:P:G 模型）在单个 P（Processor）上协作式（cooperative）完成。
关键在于：goroutine 切换并非基于时间片抢占，而是依赖“调度点”（scheduling points）。以下操作会主动让出 P，触发调度器检查其他就绪 goroutine：
- 函数调用（尤其是非内联、可能阻塞的函数，如 fmt.Println、time.Now()）
- 系统调用（如文件读写、网络操作）
- channel 操作（发送/接收阻塞时）
- 显式调用 runtime.Gosched()
- 垃圾回收相关的 STW（Stop-The-World）阶段（需 P 参与）
在你的原始示例中：
func test() {
a := 100
for i := 1; i < 1000; i++ {
a = i*100/i + a
fmt.Println("value: ", a) // ← 关键调度点！触发 goroutine 切换
}
}fmt.Println 是一个重量级函数调用，涉及内存分配、锁、系统调用等，它天然构成调度点，使 test() 暂停执行，调度器得以将 P 交给 test2()，从而实现看似“公平”的交替输出。
但当你移除 fmt.Println 后：
func test() {
a := 100
for i := 1; i < 1000; i++ {
a = i*100/i + a
// ← 无任何调度点！编译器可能内联且无阻塞操作
}
}该循环成为纯 CPU 密集型忙等待（busy loop），持续占用唯一 P，导致：
- 其他 goroutine（如 test2）无法获得执行机会；
- 垃圾收集器无法启动 STW 阶段（因无空闲 P 可用），进而可能引发内存耗尽或调度停滞；
- 运行时无法进行必要的后台任务协调。
✅ 正确做法：对长耗时 CPU 计算显式让出控制权
import "runtime"
func cpuIntensiveLoop() {
for i := 0; i < 1e9; i++ {
// 模拟计算...
result := complexComputation(i)
// 每 N 次迭代主动让出，避免饿死调度器
if i%1000 == 0 {
runtime.Gosched() // 显式触发调度
}
}
}⚠️ 重要注意事项：
- 不要依赖 fmt.Print* 或其他 I/O 函数作为“调度保险”——它们性能开销大，且行为不可靠（如被优化、缓冲影响）；
- GOMAXPROCS=1 适用于调试竞态或模拟单核环境，但生产中应让 Go 自动管理（默认为逻辑 CPU 数）；
- 真正的阻塞操作（如 time.Sleep, net.Conn.Read）会自动释放 P，交由其他 M 处理其他 G，这是 Go 并发高效的核心机制；
- 自 Go 1.14 起，运行时已引入异步抢占（preemption），对长时间运行的函数（如超 10ms 的循环）可强制插入调度点，但仍不能替代主动协作——忙循环仍是反模式。
总结：Go 的并发能力根植于其轻量级 goroutine 与智能调度器的协同，而非硬件核心数。理解调度点的存在与主动让出（Gosched）的艺术，是编写健壮、高响应 Go 程序的关键前提。
