goroutine 不会“卡死”线程是因为 Go 采用 GMP 模型调度：G 绑定 P，P 被 M 抢占式使用；G 阻塞时 M 脱离 P，其他 M 接管继续执行，从而避免线程阻塞。
goroutine 为什么不会“卡死”一个线程？
因为 Go 不是把 goroutine 直接连到 OS 线程上硬跑，而是通过 GMP 模型间接调度：每个 G（goroutine）必须绑定到一个 P（逻辑处理器），而每个 P 又只能被一个 M（OS 线程）抢占式使用。当某个 G 阻塞在系统调用（如文件读、网络收发）时，M 会脱离 P，让别的 M 接管这个 P 继续跑其他 G——所以哪怕你启了一万个 goroutine，只要没全在忙等 CPU，就不会卡住整个程序。
容易踩的坑：
- 误以为
time.Sleep或runtime.Gosched()是“必须加”的保命操作——其实 Go 1.14+ 已支持异步抢占，在循环中无调用点（比如纯计算大循环）才可能饿死其他 goroutine； - 手动设置
runtime.GOMAXPROCS(1)后还期望并发执行 I/O，结果发现所有 goroutine 串行排队——P数锁死为 1，就只剩一个本地队列可调度； - 在 CGO 调用中长时间阻塞且未用
runtime.LockOSThread()，可能导致M被回收，后续唤醒时找不到原P，引发调度延迟。
全局队列 vs 本地队列：什么时候任务会“慢半拍”？
新创建的 goroutine 默认进 全局队列，但调度器优先从每个 P 自己的 本地队列 取任务（快、无锁）。只有当本地队列空了，才会去全局队列“搬活”，或启动 work-stealing 去偷别的 P 的本地队列——这中间有最多 61 次调度间隔的延迟（Go 运行时硬编码的公平性阈值）。
这意味着：
立即学习“go语言免费学习笔记（深入）”；
- 高频创建 goroutine（如 HTTP handler 中每请求起一个）时，若不控制节奏，大量
G挤在全局队列，新P启动后可能先空转几轮才分到活； - 用
go func() { ... }()在 for 循环里快速起协程，变量捕获错误（如共用循环变量i）导致行为错乱，不是调度问题，但常被误判为“调度不均”； - 想强制走本地队列？没法直接控制——但可通过复用已有 goroutine（如 worker pool 模式）减少新建，降低对全局队列的依赖。
netpoller 怎么让 goroutine “睡得香醒得准”？
Go 的网络 I/O 不是靠轮询或系统线程池，而是靠 netpoller（基于 epoll/kqueue/IOCP 封装）统一监听 fd 就绪事件。当一个 goroutine 调用 conn.Read 阻塞时，它会被挂起并登记进 netpoller，对应 M 则立即去跑别的 G；等数据真正到达，netpoller 唤醒该 G 并放回对应 P 的本地队列——全程不占用线程，也不需要用户写回调。
关键点：
- 仅适用于标准库封装的 I/O（
net.Conn,os.File等），自己用syscall.Read就绕过netpoller，变成真阻塞； -
netpoller是单例，高并发下不会成为瓶颈，但若大量连接长期空闲（如长连接保活），会持续占用epoll句柄和内存； - HTTP/2 或 gRPC 流式响应中，如果服务端写得太慢，客户端 goroutine 可能因
write阻塞在 socket send buffer 满而挂起——这仍走netpoller，但表现像“卡住”，需检查背压控制。
如何验证 goroutine 正在被调度？
别猜，用运行时工具看真实状态。最轻量的是 runtime.NumGoroutine()，但它只给总数；更有效的是：
- 加
_ "net/http/pprof"后访问/debug/pprof/goroutine?debug=2，能看到每个 goroutine 的栈帧和阻塞点； - 用
go tool trace录制运行轨迹：go run -trace=trace.out main.go，然后go tool trace trace.out查看 goroutine 被谁抢占、在哪阻塞； - 注意
G状态码：runnable（等 CPU）、running（正在 M 上跑）、syscall（陷入系统调用）、wait（如 channel receive 阻塞）——不同状态对应不同调度路径。
最常被忽略的细节：goroutine 的“启动快”不等于“立刻执行”。从 go f() 到 f 真正开始运行，中间隔着入队、被调度、上下文切换三步，毫秒级延迟在高负载下可能放大成几十毫秒——如果你在微秒级敏感场景（如实时信号处理）里用 goroutine，就得重新评估模型。
