Go 的 channel 内部非无锁，所有操作均受 hchan.lock 保护，锁粒度为整个 hchan 结构体，导致高并发写同一 channel 必然串行化；增大缓冲区不能减少锁争用，仅改变阻塞行为。
Go 的 channel 内部不是无锁的，所有 send/recv 操作都受 hchan.lock 保护，锁粒度是整个 hchan 结构体——这意味着高并发写同一 channel 必然串行化，无法靠“多核”提升吞吐。
为什么 hchan.lock 会成为性能瓶颈
channel 的 runtime 实现中，hchan 是底层结构体，它的 qcount、sendx、recvx、等待队列指针等字段全被同一把锁保护。哪怕你只读 len(ch)，它内部也会加锁再读 qcount；哪怕缓冲区还空着，两个 goroutine 同时 ch ，也得排队。
- 常见错误现象：
pprof显示大量 goroutine 卡在runtime.chansend或runtime.chanrecv，且锁等待时间占比高 - 使用场景：worker pool 中所有 worker 共用一个 input channel，或日志收集器把所有模块日志往同一个
chan 塞 - 性能影响：单 channel 吞吐基本不随 CPU 核心数增加而提升；实测在 32 核机器上，1000 goroutine 并发写同一 buffered channel，QPS 可能还不如 8 goroutine
如何验证当前 channel 是否已被锁拖慢
别猜，用工具看真实争用。重点不是“有没有锁”，而是“锁被谁占了多久”。
- 启动程序时加
-gcflags="-l" -ldflags="-s"减少干扰，再启用go tool trace：go run -trace=trace.out main.go - 打开 trace 文件，筛选
Sync/block事件，观察runtime.chansend和runtime.chanrecv的阻塞热区 - 用
go tool pprof分析 mutex profile：go tool pprof http://localhost:6060/debug/pprof/mutex，看runtime.chansend是否排进 top3 - 注意：
len(ch)调用本身也走锁路径，高频轮询len(ch)（比如 while len(ch) > 0）会放大锁开销
绕过 hchan.lock 瓶颈的可行方案
目标不是消灭锁，而是让锁不成为热点。核心思路是「分片」或「换原语」。
- 分片 channel：按 key 哈希（如 user ID、task type）路由到不同 channel，例如
chList[shardID%16] ，把单点锁摊成 N 把独立锁 - 改用
sync.Pool+ ring buffer：对日志、指标等可丢弃数据，用预分配的环形缓冲区 +atomic索引，完全避开 channel 锁 - 高频计数/状态更新直接用
atomic.Int64或atomic.Pointer，不要通过 channel 中转 - 广播类需求改用 fan-out：主 channel 接收后，由单个 goroutine 分发到多个子 channel，避免所有消费者直接竞争同一入口
- 慎用
select+default做非阻塞写——它只是避免卡住，但失败后仍需重试逻辑，不能减少锁调用次数
缓冲大小与锁争用的关系常被误读
增大 make(chan T, N) 的 N 并不能降低锁争用频率，它只影响「是否立即阻塞」，不改变「每次操作都要抢锁」的事实。
- 有缓冲和无缓冲 channel 共享同一套锁机制，区别仅在 runtime 判断逻辑：
qcount vsrecvq.empty() - 大缓冲（如 10000）可能掩盖争用——因为 goroutine 更少被挂起，但锁持有时间变长（拷贝批量数据），反而更容易阻塞其他操作
- 真正缓解争用的是减少「单位时间内的 channel 操作次数」：比如把 100 次
ch 改为一次ch 批量发送 - 关闭 channel 本身也需获取
hchan.lock，并在 close 后唤醒所有等待 goroutine——如果此时有大量 recvq/sedq，close 操作会变慢
最易被忽略的一点：你写的 ch := make(chan int, 100) 看似只是声明，但它在堆上分配了 buf 数组、初始化了 sendx/recvx 等字段，并绑定了一把运行时 mutex——这个锁从 channel 创建起就存在，直到 GC 回收。复用 channel 不等于复用锁，但至少避免了反复创建锁的开销。
