goroutine 不会卡死整个线程是因为 GMP 模型实现动态解耦：G 绑定 P，P 可被空闲 M 抢占接管；阻塞时 M 脱离 P，其他 M 立即续跑其余 G，配合 netpoller 和异步抢占机制保障并发响应。
goroutine 为什么不会卡死整个线程？
因为 Go 不是把 goroutine 直接连到 OS 线程上硬跑，而是靠 GMP 模型动态解耦：每个 G（协程）必须绑定一个 P（逻辑处理器），而 P 可被任意空闲的 M（OS 线程）抢占式接管。
当某个 goroutine 阻塞在系统调用（比如 os.ReadFile、net.Conn.Read）时，它所在的 M 会立即脱离 P，然后其他空闲 M 就能立刻绑定这个 P，继续执行队列里别的 G——所以哪怕你启了 10 万个 goroutine，只要不是全在纯算，就不会卡住程序。
- 关键前提是：I/O 必须走 Go 标准库封装（如
net/http、os.Open），自己用syscall.Read就绕过netpoller，变成真阻塞 -
runtime.GOMAXPROCS(1)后所有G只能排队等同一个P，哪怕有多个 CPU 核也串行执行 - CGO 调用中若长时间阻塞且没配
runtime.LockOSThread()，M可能被回收，唤醒后找不到原P，导致延迟
什么时候该关心调度延迟？
调度延迟最常出现在高频创建 goroutine 的场景，比如 HTTP handler 里每请求起一个，或 for 循环里密集 go func() { ... }()。新 G 默认进全局队列，而调度器优先从 P 的本地队列取任务——只有本地队列空了，才会去全局队列“搬活”，中间最多有 61 次调度间隔的延迟（Go 运行时硬编码的公平性阈值）。
- 现象：刚启动服务时响应慢半拍，或压测初期吞吐上不去，可能就是大量
G堆在全局队列没及时分发 - 避免方式：复用
goroutine（如 worker pool），减少新建；别在循环里直接捕获变量i，写成go func(i int) { ... }(i) - 无法强制让
G进本地队列，但可控制创建节奏：比如用sync.Pool缓存临时goroutine所需对象，降低 GC 压力间接减少调度抖动
纯计算循环怎么不饿死其他 goroutine？
Go 1.14+ 引入了基于 SIGURG 的异步抢占机制，默认每 10ms 检查一次长时间运行的 goroutine 是否到了安全点（safepoint）。只要循环里有函数调用（哪怕只是 fmt.Print 或空 if）、栈增长、内存分配，就能插入抢占点。
立即学习“go语言免费学习笔记（深入）”；
- 真正危险的是无任何调用的纯计算循环：
for { sum++ }—— 它不触发任何 runtime 协作点，也难被信号中断（尤其在内联优化后） - 解决办法很简单：在循环体里加个
runtime.Gosched()，或者插个无副作用调用，比如if sum%1e6 == 0 { runtime.GC() } - 注意：
time.Sleep(0)效果类似runtime.Gosched()，但语义更模糊；别依赖它做“保命操作”，它是副产品，不是设计契约
netpoller 是怎么让 goroutine “睡得香醒得准”的？
netpoller 是 Go 实现非阻塞网络 I/O 的核心，它把所有 net.Conn 的就绪事件统一交给底层 epoll（Linux）、kqueue（macOS）或 IOCP（Windows）监听。当一个 goroutine 调用 conn.Read 阻塞时，它被挂起并注册进 netpoller，对应 M 则立刻去跑别的 G；等数据真正到达，netpoller 唤醒该 G 并放回 P 的本地队列。
- 优势：全程不占线程、不轮询、不回调，用户代码写起来像同步，底层却是异步复用
- 限制：只对标准库封装的 I/O 生效；自己用
os.File.Fd()+syscall.Read就掉出 netpoller，变成真阻塞 -
netpoller是单例，高并发下不会成为瓶颈，但若大量连接长期空闲（比如长连接保活），会增加 epoll/kqueue 的 fd 数量，不过现代系统通常撑得住
真正难搞的从来不是“怎么起 goroutine”，而是理解哪些操作会让它交出控制权、哪些不会，以及 runtime 在背后悄悄做了什么——尤其是当你看到 CPU 100% 却没明显热点时，大概率是某个纯计算 loop 卡住了 P。
