Go语言不支持替换或重写runtime调度器，因其核心函数如findrunnable()、schedule()等在编译期硬编码于src/runtime/proc.go中，无插拔接口；所谓“自定义调度”仅限于在框架内通过Gosched()、time.Sleep(0)、GOMAXPROCS等有限方式干预行为。
Go 语言没有提供“基于 runtime 的自定义调度器”接口——你不能替换或重写 findrunnable()、scheduler() 或 GMP 模型本身。所谓“自定义调度”，实际只能是在 runtime 调度框架内做行为干预，而非重建调度逻辑。
为什么不能替换 Go 的 runtime 调度器
Go 的调度器实现在 src/runtime/proc.go 中，是编译期硬编码的 C+汇编混合逻辑，所有关键路径（如 schedule()、findrunnable()、execute()）都由编译器内联或直接调用，不暴露可插拔钩子。runtime 也不提供类似 Java JVM 的 java.lang.Thread.UncaughtExceptionHandler 或 Rust 的 executor trait 这类抽象层。
- 所有 goroutine 创建（
go f()）、唤醒（goready()）、阻塞（gopark()）都直连 runtime 内部状态，绕过用户代码 -
runtime.LockOSThread()等函数只是绑定 M 和 OS 线程，并非调度策略控制 - 哪怕你用
unsafe修改P.runq或sched.runq，也会立刻被下一次findrunnable()覆盖或触发 panic（如队列长度校验失败）
真正可用的“调度干预”手段
你能影响调度行为的，只有三类有限入口：让出控制权、操纵阻塞点、调整资源可见性。
- 在纯计算循环中插入
runtime.Gosched()：把当前 G 放回本地队列尾部，避免饿死其他 G；但注意它不释放锁、不触发 GC、不休眠，仅建议用于明确 >1ms 的密集计算且无法拆分时（比如每处理 10000 次调一次） - 用
time.Sleep(0)或带default的select替代空for {}：这是更安全的让出方式，会触发 park/unpark，允许 netpoll 和 timer 协同唤醒 - 控制 P 数量：
GOMAXPROCS(n)直接限制并发执行的 P 个数，影响 work-stealing 频率和全局队列争抢概率；但别依赖runtime.NumCPU()设置它——容器中它返回宿主机核数，应读/sys/fs/cgroup/cpu/cpu.cfs_quota_us手动计算
常见误用：把 channel/select 当调度器
有人试图用带缓冲 channel 控制并发粒度，或用 select + 多个 case 模拟优先级队列，但这不是调度器——它只是 runtime 提供的同步原语，底层仍由 findrunnable() 统一捞取。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- channel 发送/接收操作本身会触发
gopark()/goready()，但排队逻辑在 runtime 内部，用户无法定制优先级或超时策略 -
select的 case 选择是伪随机的（Go 1.21+ 加入了公平轮询），不保证 FIFO 或权重，也无法感知 G 的 CPU 使用历史 - 用
chan struct{}做“信号量”没问题，但想靠它实现抢占式优先级调度？不可能——runtime 不检查 channel 状态来决定谁先 runnext
学习底层机制的正确路径
想理解调度，就老老实实读 src/runtime/proc.go 里的 schedule() 和 findrunnable()，配合 pprof/goroutine?debug=2 观察真实调度痕迹。别指望写个 “CustomScheduler” 接口就能接管 G 执行——Go 的设计哲学是“隐藏复杂性，暴露可控干预点”，所有调度细节都在 runtime 内部闭环，你唯一要做的，是写出不破坏这个闭环的代码。
最容易被忽略的点是：netpoll 和 timer 是独立于 P 本地队列的唤醒源，它们能直接把 G 推入任意 P 的 runq（甚至跨 P），而你写的任何“调度逻辑”都无法感知或干预这一过程。
