是热点；runtime.chansend1 和 runtime.chanrecv1 必然在 cpu profile 中高频出现，只要 channel 因满或空导致 goroutine 阻塞，就必定进入这两个函数。
pprof 看 runtime.chansend1 和 runtime.chanrecv1 是不是热点
如果 channel 阻塞成了性能瓶颈，runtime.chansend1 和 runtime.chanrecv1 一定会在 CPU profile 里高频出现——它们是发送/接收操作进入阻塞路径的入口函数。这不是“可能”，而是必然：只要 goroutine 因 channel 满或空而挂起，就一定走这里。
实操建议：
- 用
go tool pprof http://localhost:6060/debug/pprof/profile?seconds=30抓 30 秒 CPU 火焰图，重点看这两个函数是否占据顶部大片区域 - 对比内存 profile：
go tool pprof http://localhost:6060/debug/pprof/heap，若hchan结构体或其buf占用堆内存突增，说明缓冲区过大或 channel 创建过频 - 别只信 topN 列表，点开火焰图里
chansend1 → gopark → park_m这条链，确认是不是真在等 recvq/sendq 唤醒
用 len(ch) 和 cap(ch) 监控实时积压程度
缓冲 channel 的真实压力藏在运行时长度里。len(ch) 返回当前队列中元素个数，cap(ch) 是缓冲容量；两者的比值（float64(len(ch)) / float64(cap(ch))）才是判断是否“快堵死”的关键指标。
常见错误现象：
- 监控显示
len(ch)长期 > 90%cap(ch)，但吞吐没降——这说明消费者处理变慢，背压已形成，只是还没爆 -
len(ch)突然归零又暴涨，往往对应消费者 panic 或 goroutine 泄漏，导致 recvq 队列被清空后重建 - 对无缓冲 channel 调用
len(ch)总是 0，但它仍可能阻塞——此时必须看 goroutine 数量和阻塞态分布
基准测试中隔离竞争条件：用 -benchmem 和 -count=5 多轮验证
单次 benchmark 很容易掩盖竞争问题。缓冲大小的影响在高并发下才真正暴露，比如多个生产者往同一个 channel 写，或多个消费者争抢读。
实操建议：
- 写 benchmark 时显式启动 N 个 goroutine 模拟竞争，例如：
for i := 0; i - 加上
-benchmem观察每次操作的 allocs/op，若缓冲从 16 改到 1024 后 allocs/op 不变但 ns/op 反升，大概率是 cache line false sharing 或内存带宽打满 - 用
-count=5跑 5 轮取平均，避免单次 GC 干扰结果；特别注意第 1 轮耗时是否显著高于后续轮次——那说明初始化开销（如 buf 内存分配）被计入了
阻塞不是问题，不可预测的阻塞时间才是
channel 阻塞本身是设计使然，但如果你发现 p99 延迟毛刺集中在某几个毫秒档位（比如稳定在 1.2ms、2.4ms、4.8ms），大概率是 goroutine 被挂起后等待调度器唤醒的时间不一致导致的。这背后常混着两个易忽略点：
- Linux CFS 调度周期（默认 6ms）会影响 goroutine 唤醒延迟，尤其当 M/P 绑定不合理或系统负载高时
- channel 的
sendq/recvq是链表结构，唤醒顺序是 FIFO，但若队列过长（>100 个 sudog），遍历开销会线性增长 - GC STW 期间所有被 park 的 goroutine 都无法被唤醒，哪怕只停 100μs，也可能让一批本该 200μs 完成的操作拖到 120ms
真正要盯住的，从来不是“有没有阻塞”，而是“阻塞时间是否可控、是否随负载线性增长”。一旦发现延迟分布出现双峰或多峰，或者 p99/p999 差距拉大到 10 倍以上，就得顺着 sudog 队列和调度器 trace 往下挖了。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
