本文解析go调度器在gomaxprocs=1场景下对cpu密集型goroutine的协作式抢占机制，揭示为何看似串行的两个忙循环goroutine实际产生交错输出（1 2 1 2），而非预期的严格顺序执行。
本文解析go调度器在gomaxprocs=1场景下对cpu密集型goroutine的协作式抢占机制，揭示为何看似串行的两个忙循环goroutine实际产生交错输出（1 2 1 2），而非预期的严格顺序执行。
Go语言的调度器采用 M:P:G 模型（Machine:Processor:Goroutine），其中 P（Processor）是调度器的核心上下文，负责管理本地可运行队列和调度逻辑。当调用 runtime.GOMAXPROCS(1) 时，系统仅启用 1个P 和 1个OS线程（M），意味着所有goroutine必须在单个线程上被复用执行——但这不等于完全串行、无切换的执行。
关键在于：Go调度器虽以协作式调度为主，但自 Go 1.14 起已引入基于信号的异步抢占（asynchronous preemption），并在后续版本中持续强化。更重要的是，即使在早期版本中，某些标准库函数调用（如 fmt.Println）内部会主动触发调度检查（gosched 或更准确地说，会进入 runtime 的非内联函数路径，导致可能的 goroutine 让出）。
在你的代码中：
func loop(a int) {
fmt.Println(a) // ← 此处可能让出P（见下文说明）
for i := 0; i <p>虽然 for 循环本身是“硬编码”的CPU密集型操作（无函数调用、无channel操作、无系统调用），<strong>但它并非调度器的“黑洞”</strong>。Go编译器会在<strong>函数调用边界、栈增长检查点、以及部分标准库函数内部插入调度检查（preemptible points）</strong>。而 fmt.Println 是一个复杂函数，涉及内存分配、锁、反射和I/O缓冲等，其执行必然跨越多个调度安全点。尤其在 Go 1.14+ 中，运行时会在长时间运行的函数中周期性地检查是否被抢占（通过 sysmon 监控线程发送 SIGURG 信号），从而强制当前G暂停并交还P给其他就绪G。</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/6a6adeed24a4a355.png" 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版本官方下载，版本号 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><p>因此，真实执行流并非“loop(1)跑完全部再轮到loop(2)”，而是：</p>
- loop(1) 打印 1 后进入忙循环 → 占用P一段时间
- 运行时检测到该G已运行超时（默认约10ms），触发异步抢占 → 将 loop(1) 暂停，保存其寄存器/栈状态
- P被释放，调度器将 main goroutine 唤醒（完成 time.Sleep）→ 启动 loop(2)
- loop(2) 打印 2，随后也进入忙循环 → 同样被抢占
- 调度器轮转，恢复 loop(1) 继续执行 → 打印第二个 1，发消息退出
- 再次轮转，恢复 loop(2) → 打印第二个 2
这就是输出为 1 2 1 2 的根本原因：Go调度器在单P下仍能通过抢占机制实现近似时间片轮转（time-slicing）的效果，避免某个G永久独占CPU。
⚠️ 注意事项：
- 不应依赖 for { } 实现“绝对不被打断”的逻辑；若需强实时或确定性执行，请使用 runtime.LockOSThread()（但会牺牲并发性与调度灵活性）；
- 真正的“不可抢占”场景极少（如内联汇编、禁用GC的特定runtime路径），日常代码中应视所有goroutine为可能在任意函数调用点被切换；
- 可通过 GODEBUG=schedtrace=1000 观察调度器每秒的详细行为（如G状态变迁、P绑定、抢占事件）；
- 更健壮的CPU密集型任务应主动插入 runtime.Gosched() 或拆分为小块并配合 select {} / time.Sleep(0) 显式让出。
总结：Go的“协作式”调度早已不是纯自愿让出；现代Go（≥1.14）在单P下也能通过信号抢占保障公平性与响应性。理解这一机制，是写出高可靠并发程序的基础。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
