GOMAXPROCS=1仍能并发执行多个goroutine，因其调度器采用协作式机制，在函数调用、I/O、内存分配等调度点主动让出P，使其他goroutine得以轮流执行，而非依赖CPU时间片抢占。
为什么 GOMAXPROCS=1 仍能“并发”执行多个 goroutine
Go 调度器不是靠 CPU 时间片抢占来实现并发，而是靠协作式调度点（scheduling points）主动让出控制权。设置 runtime.GOMAXPROCS(1) 只限制同时运行 Go 代码的 OS 线程数为 1，不等于禁用所有并发能力。
关键在于：只要 goroutine 中存在调度点（如系统调用、内存分配、channel 操作、fmt.Println、time.Sleep 等），运行时就会在这些位置暂停当前 goroutine，切换到另一个就绪的 G。哪怕只有一个 P，也能交替执行几十甚至上百个 goroutine。
- 纯计算循环（如
for i := 0; i ）没有调度点 → 会饿死其他 goroutine -
fmt.Println触发堆分配 + 锁 + write 系统调用 → 天然含多个调度点 -
time.Sleep底层是 netpoll 或 timer 唤醒 → 明确让出 P - channel 发送/接收（尤其无缓冲或满/空时）→ 阻塞并触发调度
如何验证单 P 下的 goroutine 切换行为
直接观察输出顺序比看文档更可靠。写一个带明显时间差和打印标记的对比测试：
package main
<p>import (
"fmt"
"runtime"
"time"
)</p><p>func task(id int, dur time.Duration) {
fmt.Printf("task %d start\n", id)
time.Sleep(dur)
fmt.Printf("task %d done\n", id)
}</p><p>func main() {
runtime.GOMAXPROCS(1)
go task(1, 100<em>time.Millisecond)
go task(2, 50</em>time.Millisecond)
go task(3, 20<em>time.Millisecond)
time.Sleep(200 </em> time.Millisecond)
}你会看到输出不是严格串行（如 1→2→3），而是穿插的，比如：
立即学习“go语言免费学习笔记（深入）”；
task 1 starttask 2 starttask 3 starttask 3 donetask 2 donetask 1 done
这说明三个 goroutine 在单个 P 上被调度器来回切换执行 —— 不是并行，但确实是并发（concurrent）。
容易被忽略的调度饥饿陷阱
新手常误以为 “开了 goroutine 就一定并发”，但在 GOMAXPROCS=1 场景下，一旦某个 goroutine 进入长循环且不含任何调度点，它就会霸占 P，其他 goroutine 永远得不到执行机会。
- 错误示例：
for {}、for i := 0; i （无函数调用、无内存操作） - 修复方式：手动插入调度点，例如在循环体中加
runtime.Gosched()，或混入任意小开销调用（如if i%1000 == 0 { _ = i }不够，但fmt.Print("")或time.Now()可以） - 更稳妥做法：避免纯计算型长循环；若必须，用
select {}或 channel 等待代替忙等
这种饥饿问题在线上环境极难复现和定位，因为它依赖于具体代码路径是否触发调度点 —— 所以单核验证时，务必检查每个 goroutine 是否有“呼吸口”。
什么时候该用 GOMAXPROCS=1 做测试
它不是为了“模拟低配机器”，而是为了排除并行干扰，专注验证调度逻辑和竞态行为。
- 调试 channel 死锁：单 P 下更容易暴露收发顺序依赖
- 验证
sync.WaitGroup或select的行为一致性 - 排查 goroutine 泄漏：GOMAXPROCS=1 时泄漏 goroutine 更容易被 pprof 抓到（因为不会分散到多线程）
- 单元测试中强制串行化并发逻辑，提高可重复性
注意：GOMAXPROCS=1 不影响 netpoll、GC、signal handler 等后台 M 的存在 —— 它只管用户代码执行的 P 数量。所以 I/O 类操作依然能“并发”返回，这是很多人混淆的根源。
