goroutine 不会卡死线程，关键在于 M 可主动脱离 P 去休眠或绑定其他空闲 P，使被留下的 P 能被其他 M 接管继续调度；而 LockOSThread、纯 CPU 循环、GOMAXPROCS(1) 和队列层级均会影响调度及时性。
goroutine 为什么不会卡死线程？关键在 M 能“松手”
Go 不会让一个阻塞的 goroutine 拖垮整个 OS 线程，根本原因不是“协程轻”，而是 GMP 模型中 M（OS 线程）和 P（逻辑处理器）可以解绑。当某个 G 因系统调用（比如 read、accept）或 channel 阻塞时，运行它的 M 会主动脱离当前 P，然后去休眠或尝试绑定别的空闲 P；而那个被留下的 P 可立即被其他空闲 M 接管，继续跑别的 G。
实操建议：
- 别把
runtime.LockOSThread()当成万能锁 —— 它强制M和P绑死，一旦该G在 CGO 中长时间阻塞（如调用 C 的sleep(5)），M就无法脱身，后续唤醒时还可能找不到原P，导致调度延迟甚至假死 - 纯 CPU 密集型循环（如
for { i++ }）仍可能卡住单个P：即使 Go 1.21 已加强异步抢占，若函数被内联且无栈增长/函数调用，抢占点仍可能缺失；稳妥做法是显式插入runtime.Gosched()或拆成带if i%1000 == 0的小块 -
GOMAXPROCS(1)后所有G必然串行——这不是 bug，是设计使然：只有一个P，就只有一条本地队列可调度，I/O 就绪的G也会被塞进全局队列，等这个唯一P空出来才轮到它
新起的 goroutine 为啥不马上执行？队列层级决定“冷热”
调用 go f() 并不等于立刻分配线程执行，而是先入队：优先塞进当前 P 的本地队列（最多 256 个），满了就进全局队列。而调度器永远优先从本地队列取任务，只有本地队列空了，才会去全局队列“搬活”，或触发 work-stealing 去偷别的 P 的队列——这中间存在最多 61 次调度间隔的延迟（Go 运行时硬编码的公平性阈值）。
常见现象：
- HTTP handler 里高频起
go func() { ... }()，大量G挤在全局队列，新启动的P（比如扩容后）可能空转几轮才分到任务 - for 循环中直接捕获变量
i：for i := 0; i 输出全是3——这不是调度问题，是闭包变量共享，但常被误判为“调度不均” - 想让新
G尽快执行？没法直控队列，但可用 worker pool 复用已有G，减少新建开销和全局队列依赖
怎么确认 goroutine 真被调度了？别靠 sleep 猜，要观测
time.Sleep(1 * time.Millisecond) 不是调度保证，只是给主 goroutine 让出时间窗口的权宜之计。真正判断调度行为，得靠 Go 自带的观测工具，而非输出顺序或经验猜测。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
实操建议：
- 用
GODEBUG=schedtrace=1000启动程序，每秒打印一次调度器状态，看P是否空闲、G是否堆积在全局队列 - 更精细分析用
go tool trace：运行go run -trace=trace.out main.go，再go tool trace trace.out查看 goroutine 生命周期、阻塞点、M/P 绑定变化 - 别信“main 执行完子 goroutine 就一定跑了”——主 goroutine 退出，整个进程就终止，未调度的
G直接丢弃；必须用sync.WaitGroup或channel显式同步
抢占失效的典型场景：纯计算 + 内联 + 单 P
Go 1.21 虽大幅改进抢占（通过编译器插桩 asyncPreempt），但仍有边界情况会逃逸：一个被内联的、无函数调用、无栈操作、无 GC 安全点的死循环，在 GOMAXPROCS=1 下仍可能独占 CPU，导致其他 G 饿死。
验证方式很简单：
- 写个
for { i++ }循环，不加任何调用，runtime.GOMAXPROCS(1)，再起另一个goroutine打印时间戳——后者几乎永远不会执行 - 加上
println("tick")或runtime.Gosched()，立刻恢复公平调度 - 生产环境遇到疑似“卡死”，先检查是否用了
//go:noinline或过度内联，再看GOMAXPROCS设置是否无意锁死了并行能力
调度器没那么智能，它依赖安全点；你写的代码越“干净”，它就越难介入——这点容易被忽略，尤其在做实时计算或嵌入式场景时。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
