不能在用户代码中复现go调度循环，因为schedule()是未导出的runtime内部函数，依赖m栈、goroutine状态机、原子队列操作等底层机制，用户goroutine无权限执行；唯一可靠观察方式是启用trace。
Go 的调度循环不是靠开发者手动控制的，它由 runtime 在后台持续驱动；想靠“写个 for 循环调用 gopark”来模拟 GMP 调度，只会卡死或 panic。
为什么不能在用户代码里复现调度循环
Go 调度器的主循环（如 schedule() 函数）运行在系统线程 M 的底层上下文中，绑定到 runtime.m0 或工作 M 的栈上，且依赖精确的 goroutine 状态机（_Grunnable → _Grunning → _Gwaiting 等）、全局队列与 P 本地队列的原子操作、以及被屏蔽的信号和抢占点。用户 goroutine 没有权限执行这些操作。
-
schedule()是未导出的 runtime 内部函数，无法从 Go 代码中直接调用 - 手动调用
gopark会把当前 goroutine 挂起，但不会触发其他 G 的唤醒或 P 的负载迁移 - 任何试图绕过
runtime.goexit或伪造 M/P 状态的行为，都会导致fatal error: schedule: holding locks或bad pointer in frame
真正能观察调度循环的入口：trace 和 debug/trace
想验证调度行为，唯一可靠的方式是开启运行时 trace，而不是“实现一个调度器”。go tool trace 输出的事件流（如 GoCreate、GoStart、GoBlock、Syscall）就是调度循环实际动作的投影。
- 启用 trace：
GODEBUG=schedtrace=1000 ./your-program（每秒打印调度器统计） - 生成完整 trace 文件：
go run -gcflags="-l" -ldflags="-s -w" -trace=trace.out main.go，再用go tool trace trace.out查看可视化时序 - 关键字段注意：
procs表示当前活跃 P 数，goroutines是实时 G 总数，runqueue显示某 P 本地队列长度 —— 这些才是调度循环“正在做什么”的直接证据
学习 GMP 应该盯住三个可验证行为，而非模型图
画 GMP 三色图容易，但真正构建底层思维，得从现象反推机制。重点关注以下可复现、可打断、可测量的行为：
- 当一个 goroutine 执行
time.Sleep(1)，它立刻离开运行队列，进入 timer heap，而不是被 M 主动 yield —— 说明阻塞不靠轮询，靠异步通知 - 启动 10000 个空 goroutine：
for i := 0; i ，观察 <code>GOMAXPROCS=1下的schedtrace输出：M 不会暴涨，P 数固定，G 大量堆积在全局队列 —— 说明 P 是调度资源单位，不是执行单位 - 在
select中加入case 后，即使无其他 channel 活动，goroutine 也会准时唤醒 —— 证明 timer 驱动是调度循环的独立分支，和 network poller 并行运作
调度循环本身没有“入口函数”供你插入断点，它的存在感只体现在状态变化之间：G 从 runnable 到 running 的瞬间、M 从 spinning 到 park 的临界、P 从 idle 到 stolen 的原子交换。这些间隙极短，且受 GC、sysmon、netpoll 影响，稍不留神就滑过去了 —— 这正是它难被直观把握的地方。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
