是。goroutine 被阻塞时实际调用 gopark 挂起，状态设为 _Gwaiting，并加入 hchan 的 sendq/recvq 队列，由调度器统一管理唤醒；它不进入 OS 休眠，仅从运行队列移除，唤醒后需重新排队等待 M 执行。
channel 阻塞时，goroutine 真的“休眠”在 channel 上吗？
不是。Go 的 channel 本身不维护所谓“休眠队列”，goroutine 被阻塞时，实际是被挂起并交由运行时调度器（GMP 模型）统一管理。当向一个无缓冲 chan int 发送数据而无人接收时，当前 goroutine 会调用 gopark，把自己的状态设为 _Gwaiting，然后把自身指针加入该 hchan 结构体的 sendq（一个 waitq 类型的双向链表），再主动让出 M。此时它并未进入 OS 线程休眠，只是从运行队列中移除，等待后续唤醒。
常见误解是认为 channel 自己“睡着了 goroutine”，其实 sendq 和 recvq 只是等待者登记簿；真正挂起/唤醒动作由调度器完成。关键点在于：gopark 必须搭配 goready 成对出现，否则 goroutine 永远卡住——这也是死锁检测能发现部分问题的原因。
为什么 goroutine 被唤醒后不一定立刻执行？
因为 GMP 调度器不保证唤醒即运行。goroutine 从 sendq 或 recvq 被 goready 唤醒后，会被推入 **P 的本地运行队列**（或全局队列），等待 M 抢占到 CPU 后轮询执行。若此时所有 P 的本地队列都满、且全局队列也积压严重，该 goroutine 可能排队数百微秒甚至更久。
影响因素包括：
-
GOMAXPROCS设置过小，P 数量不足，加剧队列竞争 - 大量 goroutine 同时被唤醒（如 close(chan) 触发全部 recvq 唤醒），引发“惊群”式入队压力
- 存在长时间运行的 goroutine（如死循环未调用 runtime.Gosched），阻塞 P 的调度器轮询
可通过 runtime.ReadMemStats 查看 WaitGoroutines 和 NumGoroutine 差值，辅助判断是否存在“唤醒延迟”现象。
channel 操作触发上下文切换的真实开销在哪？
真正的上下文切换开销不在 channel 数据拷贝，而在调度器介入环节：一次阻塞发送至少涉及三次关键操作——gopark（保存寄存器、更新 G 状态）、park_m（尝试解绑 M 与 P）、schedule（寻找下一个可运行 G）。这些是纯 Go 运行时行为，不触发 OS 级线程切换，但仍有可观成本（约几十纳秒到百纳秒级）。
容易被忽略的坑：
- 在 hot path 中频繁对空 chan 进行非阻塞
select判断（如select { case ch ），虽不阻塞，但每次仍需原子检查 <code>hchan状态、更新sendq锁，实测比普通指针比较慢 5–10 倍 - 使用带缓冲 channel 时误以为“不会阻塞就等于零成本”，其实缓冲区满/空时仍要走相同的锁 + 队列操作路径
- 调试时用
pprof看到runtime.gopark占比高，往往不是 channel 本身问题，而是 goroutine 在等 I/O 或锁，channel 只是“替罪羊”
如何验证某个 goroutine 是否真被 channel 阻塞？
最直接方式是用 runtime.Stack 或 debug.ReadGCStats 配合 pprof 的 goroutine profile，但更轻量的是观察 runtime.GoroutineProfile 中的状态字段：_Gwaiting 表示 parked，再结合 stack trace 中是否含 chansend / chanrecv 符号即可确认。
实操建议：
- 启动时加
GODEBUG=schedtrace=1000，每秒输出调度器摘要，关注procs、runqueue和goroutines变化趋势 - 用
go tool trace录制运行 trace，过滤事件类型为GoBlockRecv或GoBlockSend，可精确定位阻塞位置和持续时间 - 避免在生产环境依赖
runtime.NumGoroutine()做监控阈值告警——它包含所有状态的 goroutine，无法区分是否真卡在 channel
channel 和 GMP 的耦合比表面看起来更深：你写的每一行 ch ，背后都是运行时在做 G 状态迁移、P 队列调度、M 抢占决策。真正难调试的，永远是那些“没报错、没 panic、但就是慢”的上下文隐式流转。
