本文解析go运行时在gomaxprocs=1下对cpu密集型goroutine的调度行为，揭示fmt.println等标准库函数隐式触发的协作式抢占机制，解释为何看似串行的忙循环仍导致输出交错（如1 2 1 2）。
本文解析go运行时在gomaxprocs=1下对cpu密集型goroutine的调度行为，揭示fmt.println等标准库函数隐式触发的协作式抢占机制，解释为何看似串行的忙循环仍导致输出交错（如1 2 1 2）。
Go的调度器采用 M-P-G 模型（Machine-Processor-Goroutine），其中 P（Processor）代表逻辑处理器，其数量由 GOMAXPROCS 控制。当设置 runtime.GOMAXPROCS(1) 时，系统仅启用 1 个 P，意味着同一时刻最多只有一个 goroutine 在执行用户代码——但这绝不等同于“完全串行执行”或“无调度介入”。
关键在于：Go 的调度并非纯粹抢占式（如操作系统线程），也非完全协作式（如需显式调用 runtime.Gosched()），而是一种协作式+协作点驱动的准抢占机制。即使在单 P 场景下，只要 goroutine 主动调用某些运行时感知的函数（如 I/O、channel 操作、time.Sleep、fmt 系列、sync 原语等），就会在函数入口或关键节点主动让出 P，触发调度器切换到其他就绪 goroutine。
在你的示例中：
func loop(a int) {
fmt.Println(a) // ← 协作点：fmt.Println 内部会检查是否需让出P
for i := 0; i <p>执行流程实际如下（精简关键调度点）：</p><div class="aritcle_card flexRow artxards">
<div class="artcardd flexRow">
<a class="aritcle_card_img" rel="nofollow" href="/xiazai/gongju/2525" title="Go语言（Golang）1.26.0"><img
src="https://img.php.cn/upload/manual/001/589/237/6a6ae8334dfb7907.jpg" alt="Go语言（Golang）1.26.0" onerror="this.onerror='';this.src='/static/lhimages/moren/morentu.png'" ></a>
<div class="aritcle_card_info flexColumn">
<a rel="nofollow" href="/xiazai/gongju/2525" title="Go语言（Golang）1.26.0" class="overflowclass">Go语言（Golang）1.26.0</a>
<p class="overflowclass">Go语言（Golang）1.26.0版本提供 Go 官方 Windows amd64 MSI 安装包下载入口，版本号 1.26.0，可用于旧项目维护、兼容性测试和指定版本开发环境配置。</p>
</div>
<a rel="nofollow" href="/xiazai/gongju/2525" title="Go语言（Golang）1.26.0" class="aritcle_card_btn flexRow flexcenter"><b></b><span>下载</span>
</a>
</div>
</div>
- go loop(1) 启动，fmt.Println(1) 执行并打印 1；
- 随后进入超长忙循环（无函数调用，不触发协作）→ 持续独占 P；
- 但注意：fmt.Println 是一个复杂函数，其内部会调用 write 系统调用（尤其在终端输出时），而 Go 运行时在 write 等系统调用前后自动插入调度检查（entersyscall / exitsyscall）；更重要的是，从 Go 1.14 起，运行时引入了异步抢占（asynchronous preemption） —— 即使 goroutine 不主动协作，运行时也会在安全点（如函数返回、循环边界）通过信号（SIGURG）强制中断长时间运行的 goroutine，将其挂起并调度其他 goroutine。
然而，在本例中更直接的协作点来自 第二次 fmt.Println(a)：当 loop(1) 结束忙循环后，再次调用 fmt.Println(1)，该调用在准备写入前会检测当前 goroutine 是否被抢占标记，或在 runtime 层触发调度检查，从而主动 yield P，使得刚被 go loop(2) 启动、且已就绪的 loop(2) 获得执行权 —— 它立即打印 2，再进入自己的忙循环……如此交替，最终输出 1 2 1 2。
✅ 关键结论：
- GOMAXPROCS=1 保证并发度为 1（同一时刻仅 1 个 goroutine 运行），但不保证执行顺序严格串行；
- 标准库函数（尤其是涉及 I/O、同步、格式化输出的）是天然的协作点（cooperative yield points）；
- Go 运行时通过协作点 + 异步抢占双重机制，避免单个 goroutine 饿死其他 goroutine，保障整体响应性；
- 纯空循环（for {} 或无调用的大循环）仍是危险的，应显式插入 runtime.Gosched() 或拆分任务，以确保公平调度。
因此，不要依赖“单 P = 绝对顺序执行”来设计逻辑；真正需要强顺序保证时，应使用 channel、mutex 或明确同步原语，而非寄望于调度器行为。
