文章目录一、开场快递员到了取件人却还没来二、channel 不只是一个队列2.1 无缓冲 channel必须当面交接2.2 有缓冲 channel快递柜可以暂存三、make(chan T, n) 到底创建了什么3.1 buf 为什么是环形缓冲区3.2 为什么还需要一把锁四、发送一个值Runtime 会走哪条路4.1 地址存在吗nil channel4.2 驿站是否已经停止收件4.3 有没有正在等待的接收者4.4 缓冲区还有位置吗4.5 柜子满了怎么办五、接收一个值又会走哪条路5.1 nil channel永远等不到包裹5.2 有等待发送者直接交接或顺手补柜5.3 缓冲区有数据按 recvx 领取5.4 什么都没有进入 recvq六、sudog 是谁排队的是 goroutine 的“号码牌”七、close关门后柜子里的包裹还能取7.1 closechan 会唤醒谁7.2 为什么通常由发送方关闭7.3 range 为什么能自动结束八、select多个窗口谁先叫号就去谁那里8.1 多个 case 同时就绪怎么办8.2 default 是“现在办不了就先走”8.3 nil channel 在 select 中反而很有用九、happens-before交接的不只是值十、完整实战用 Worker Pool 运营快递驿站十一、怎么观察 channel 阻塞11.1 Race Detector 检查共享内存11.2 runtime/trace 看 goroutine 在哪里等待11.3 goroutine profile 看堆栈十二、最常见的十个坑12.1 把缓冲区当成无限队列12.2 接收方随手 close12.3 多个生产者分别 close12.4 忘记处理 comma-ok12.5 认为 close 会立即丢掉缓冲数据12.6 向 nil channel 通信12.7 用 len(ch) 做并发正确性判断12.8 default 无限循环导致 CPU 打满12.9 只让消费者监听 context12.10 看到 fatal deadlock 就认为是 Runtime 坏了十三、channel 应该怎么选容量十四、总结柜子只是表面调度与同步才是核心参考资料一、开场快递员到了取件人却还没来晚上九点一名快递员抱着最后一个包裹冲进驿站“这个件今天必须送到。”工作人员看了看空荡荡的取件区又看了看已经塞满的快递柜摊手说“柜子满了收件人也没来你得等等。”这句话几乎就是 channel 的运行规则没有快递柜时快递员和取件人必须同时出现才能当面交接有快递柜时快递员可以先把包裹放进去但柜子满了仍然要等待取件人来得太早柜子里又没有包裹也只能等待驿站停止收件后柜子里已有的包裹仍然可以继续领取如果驿站根本不存在快递员和取件人就会在错误的地址永远等下去。把故事中的角色换成 Go 的术语就是下面这张表快递驿站Go channel快递员发送数据的 goroutine取件人接收数据的 goroutine包裹channel 中传递的值快递柜有缓冲 channel 的环形队列等待寄件的队伍sendq等待取件的队伍recvq停止收件close(ch)不存在的驿站nil channel本文以 Go 1.26.5 的语言规范和 Runtime 源码为背景。channel 的语言语义属于兼容性承诺但hchan、sudog等 Runtime 内部实现可能随版本变化。二、channel 不只是一个队列很多人第一次学习 channel会把它理解成“线程安全队列”。这个说法能帮助入门却不够完整。队列主要解决“数据放在哪里”channel 同时解决了两件事通信把一个值从发送方交给接收方同步条件不满足时挂起 goroutine条件满足后再唤醒它。Go 鼓励使用通信来组织并发协作。发送语句ch-parcel接收语句parcel:-ch表面上只有一个箭头底层却可能经历直接交接、写入缓冲区、加入等待队列、挂起和唤醒等多条路径。2.1 无缓冲 channel必须当面交接ch:make(chanstring)没有指定容量容量就是 0。发送方和接收方必须在某个时刻同时准备好通信才能完成。funcmain(){ch:make(chanstring)gofunc(){ch-包裹 Afmt.Println(快递员交接完成)}()parcel:-ch fmt.Println(取件人收到,parcel)}如果没有接收者发送方不会把值扔在地上然后离开而是会阻塞。这种“必须见面”的特性让无缓冲 channel 同时成为一个同步点接收完成之前发送不会完成。2.2 有缓冲 channel快递柜可以暂存ch:make(chanstring,3)容量为 3表示最多暂存 3 个值ch-包裹 Ach-包裹 Bch-包裹 C此时即使还没有接收者前三次发送也能完成。第四个包裹到来时如果仍没人取件发送方才会阻塞。缓冲区改变了发送方和接收方必须同时到场的要求却没有取消背压生产速度长期大于消费速度柜子早晚会满。三、make(chan T, n) 到底创建了什么编译器和 Runtime 会把make(chan T, n)落到runtime.makechan。Runtime 中的核心对象叫hchan。下面是为了讲解而保留关键字段的简化示意并非原源码逐字复制typehchanstruct{qcountuint// 缓冲区当前元素数dataqsizuint// 缓冲区容量buf unsafe.Pointer elemsizeuint16closeduint32sendxuint// 下一次写入位置recvxuint// 下一次读取位置recvq waitq// 等待接收的 sudog 队列sendq waitq// 等待发送的 sudog 队列lock mutex}3.1 buf 为什么是环形缓冲区容量为 3 的 channel不需要在每次接收后把剩余元素整体向前搬动。Runtime 使用sendx和recvx记录写入、读取位置到达尾部后绕回开头。假设依次发送 A、B、C槽位 [ A ][ B ][ C ] recvx ↑ sendx ↑ 下一次绕回 0但当前队列已满 qcount3接收 A 后再发送 D槽位 [ D ][ B ][ C ] recvx ↑ sendx ↑ qcount3物理位置绕圈复用逻辑顺序仍然是 B、C、D。3.2 为什么还需要一把锁多个 goroutine 可能同时发送、接收或关闭同一个 channel。qcount、索引、等待队列和关闭状态必须保持一致因此hchan内部用锁保护关键状态。这不等于“所有 channel 永远串行、性能一定很差”。Runtime 会先尝试快速路径真正修改共享状态时再进入临界区如果已经有配对的等待者还可能直接交接数据绕过缓冲区。四、发送一个值Runtime 会走哪条路普通发送最终会进入runtime.chansend。可以把判断顺序理解成驿站工作人员依次问四个问题。4.1 地址存在吗nil channelvarchchanintch-1ch的零值是 nil。阻塞式发送到 nil channel会通过gopark永久挂起它不会 panic也不会自动创建 channel。这像快递员拿着一个不存在的驿站地址等待永远不会有人来开门。4.2 驿站是否已经停止收件如果closed ! 0发送会 panicpanic: send on closed channel因为关闭表达的是“以后不会再产生新值”。继续发送会破坏接收方赖以判断完成的协议所以 Go 选择直接暴露错误而不是悄悄丢数据。4.3 有没有正在等待的接收者如果recvq中已经有接收者发送方会把值直接复制给它然后调用goready让对应 goroutine 重新变为可运行。即使这是有缓冲 channel只要存在等待接收者也优先直接交接不必先把包裹放进柜子再取出来。4.4 缓冲区还有位置吗如果没有等待接收者但qcount dataqsiz值会写入sendx指向的槽位将元素复制到缓冲区sendx向后移动必要时绕回 0qcount加 1发送完成当前 goroutine 继续执行。4.5 柜子满了怎么办如果既没有接收者缓冲区也没有空位Runtime 会取得当前 goroutine分配一个sudog记录 goroutine、待发送值和 channel将sudog加入sendq调用gopark挂起当前 goroutine。注意挂起的是 G不是必须把操作系统线程 M 一起堵住。M 可以继续拿到其他可运行的 G这正是上一篇 Go GMP 调度模型 中讲过的调度协作。五、接收一个值又会走哪条路接收由runtime.chanrecv处理思路和发送镜像相似。5.1 nil channel永远等不到包裹varchchanintvalue:-ch阻塞式接收会永久挂起。如果程序中没有其他可运行 goroutineRuntime 最终可能报告fatal error: all goroutines are asleep - deadlock!5.2 有等待发送者直接交接或顺手补柜如果sendq中有发送者无缓冲 channel直接从发送者复制到接收者已满的有缓冲 channel接收者先取走recvx位置的旧值再把等待发送者的新值补进同一个槽位。第二种情况很像取件人刚打开一个满柜工作人员马上把排队的下一个包裹补进去。一次临界区操作同时完成“取旧件”和“放新件”。5.3 缓冲区有数据按 recvx 领取qcount 0时接收方从recvx读取清空槽位移动索引并将qcount减 1。5.4 什么都没有进入 recvq既没有等待发送者缓冲区也为空接收 goroutine 会被封装成sudog加入recvq然后通过gopark休眠等待发送或关闭操作将它唤醒。六、sudog 是谁排队的是 goroutine 的“号码牌”很多人看到sendq、recvq会以为队列中直接放着 G。真实实现中间还有一层sudog。一个 goroutine 可能同时参与多个同步等待。例如select{casevalue:-ch1:fmt.Println(value)casech2-task:fmt.Println(sent)}同一个 G 同时关注多个 channel因此不能简单地把一个 G 节点塞进某个队列。sudog负责描述“一次具体等待关系”其中会关联等待的 goroutine对应的 channel待发送或接收值的位置是否来自select唤醒后操作是否成功。当条件不满足时当前 G → sudog → sendq/recvq → gopark另一方到来或 channel 被关闭时队列取出 sudog → 设置结果 → goready(G) → 重新参与 GMP 调度goready并不保证这个 G 立刻在当前 CPU 上运行它只是让 G 恢复 runnable之后仍由调度器选择合适的 P 和 M 执行。七、close关门后柜子里的包裹还能取channel 的关闭语义经常被误解。close(ch)不是销毁对象也不是清空缓冲区而是在协议层宣布不会再有新值发送进来。ch:make(chanint,2)ch-10ch-20close(ch)fmt.Println(-ch)// 10fmt.Println(-ch)// 20fmt.Println(-ch)// 0前两个值仍按顺序取出。缓冲区耗尽后继续接收会立即得到元素类型的零值。为了区分“真的发送过一个零值”和“channel 已关闭且排空”使用 comma-okvalue,ok:-chif!ok{fmt.Println(驿站已关门柜子也空了)}7.1 closechan 会唤醒谁关闭时Runtime 会标记closed取出所有等待者然后在释放 channel 锁之后唤醒它们recvq中的接收者被唤醒得到零值和ok falsesendq中的发送者也被唤醒但它们恢复执行后会 panic。先释放锁再批量goready可以避免在持有 channel 锁时修改其他 G 的状态而引入锁顺序问题。7.2 为什么通常由发送方关闭接收方往往不知道是否还有其他生产者准备发送。它擅自关闭就可能让正常发送者 panic。实践中可以遵循由能够确认“不会再发送新值”的一方负责关闭。多生产者场景常用WaitGroup等待所有生产者结束再由一个协调 goroutine 关闭 channel。7.3 range 为什么能自动结束forvalue:rangech{fmt.Println(value)}range会持续接收直到 channel 已关闭且缓冲区已经排空。如果发送者永远不关闭接收循环可能永远等下去。八、select多个窗口谁先叫号就去谁那里select用来同时等待多个 channel 操作select{casetask:-jobs:handle(task)caseresults-result:fmt.Println(结果已提交)case-ctx.Done():returnctx.Err()}可以把它想成站在多个窗口之间哪个窗口先能办理就去哪个窗口。8.1 多个 case 同时就绪怎么办规范规定当多个通信分支都能执行时会从可执行分支中做伪随机选择。不要假设源码书写靠前的 case 永远优先。Runtime 的selectgo会构造随机化的轮询顺序并按稳定顺序给涉及的 channel 加锁以降低偏置并避免多 channel 锁顺序死锁。8.2 default 是“现在办不了就先走”select{casech-value:fmt.Println(发送成功)default:fmt.Println(当前不能发送)}带default的select不会等待。它适合尽力而为的通知、指标采样等场景但如果放在没有休眠的无限循环中可能制造 CPU 空转。8.3 nil channel 在 select 中反而很有用单独向 nil channel 发送或接收会永久阻塞放进select时对应 case 永远不会就绪相当于动态关闭一个分支varoutchan-intifready{outrealChannel}select{caseout-value:fmt.Println(ready 时才可能执行)case-ctx.Done():}把变量重新设为 nil就能暂时禁用该 case而不需要再写一层复杂条件判断。九、happens-before交接的不只是值channel 还能建立内存可见性关系。varmessagestringdone:make(chanstruct{})gofunc(){message包裹已签收close(done)}()-done fmt.Println(message)根据 Go 内存模型关闭 channel 发生在因该关闭而返回零值的接收之前。因此主 goroutine 接收到关闭信号后能够观察到之前对message的写入。常用规则可以记住三条一次发送发生在对应接收完成之前一次关闭发生在因关闭而返回的接收之前容量为 C 的 channel第 k 次接收发生在第 kC 次发送完成之前。第三条解释了为什么有限缓冲 channel 可以充当并发信号量容量限定了最多有多少个任务进入临界区域。不过channel 的同步关系只覆盖实际建立的发送、接收和关闭事件。不要用len(ch)判断“下一次发送一定不阻塞”读取长度和真正发送之间其他 goroutine 随时可能改变状态。十、完整实战用 Worker Pool 运营快递驿站下面的示例包含三个快递员、任务 channel、结果 channel、WaitGroup、超时取消和安全关闭顺序。packagemainimport(contextfmtsynctime)typeParcelstruct{IDintAddressstring}typeResultstruct{ParcelIDintWorkerIDintStatusstring}funcworker(ctx context.Context,idint,jobs-chanParcel,resultschan-Result,wg*sync.WaitGroup,){deferwg.Done()for{select{case-ctx.Done():returncaseparcel,ok:-jobs:if!ok{return}timer:time.NewTimer(20*time.Millisecond)select{case-ctx.Done():timer.Stop()returncase-timer.C:}result:Result{ParcelID:parcel.ID,WorkerID:id,Status:已入柜parcel.Address,}select{caseresults-result:case-ctx.Done():return}}}}funcmain(){ctx,cancel:context.WithTimeout(context.Background(),2*time.Second)defercancel()jobs:make(chanParcel,3)results:make(chanResult,3)varworkers sync.WaitGroup workers.Add(3)forid:1;id3;id{goworker(ctx,id,jobs,results,workers)}gofunc(){deferclose(jobs)forid:1;id5;id{select{casejobs-Parcel{ID:id,Address:fmt.Sprintf(%d 号柜,id)}:case-ctx.Done():return}}}()gofunc(){workers.Wait()close(results)}()forresult:rangeresults{fmt.Printf(包裹 %d%s快递员 %d\n,result.ParcelID,result.Status,result.WorkerID)}}这段代码有三个关键关闭原则生产任务的 goroutine 最了解何时停止发送因此由它关闭jobs单个 worker 不关闭results因为它不知道其他 worker 是否仍在发送协调 goroutine 等全部 worker 结束后再关闭results让主 goroutine 的range正常退出。示例中的 channel 参数还声明了方向jobs-chanParcel resultschan-Result它不会改变底层 channel却能让编译器阻止 worker 错误地向jobs发送或从results接收相当于给驿站员工写清岗位权限。十一、怎么观察 channel 阻塞11.1 Race Detector 检查共享内存gotest-race./...channel 本身支持并发使用不代表 channel 外部的共享变量就自动安全。Race Detector 可以发现没有通过 channel、锁或原子操作建立同步的数据访问。11.2 runtime/trace 看 goroutine 在哪里等待程序中启动 tracefile,_:os.Create(trace.out)trace.Start(file)defertrace.Stop()运行后查看go tool trace trace.out在 trace 中可以观察 goroutine 的运行、阻塞和唤醒区分它是在等 channel send、channel receive、select、锁还是网络事件。11.3 goroutine profile 看堆栈线上 goroutine 数量持续增长时可以通过net/http/pprof查看 goroutine profile。常见堆栈会直接出现chan send chan receive select如果同一类堆栈不断增加通常意味着生产消费失衡、缺少取消路径、channel 没有关闭或者下游已经退出而上游仍在发送。十二、最常见的十个坑12.1 把缓冲区当成无限队列缓冲只能吸收短期波动。长期生产速度更快时要么发送方阻塞要么应用自行丢弃、降级或扩容。12.2 接收方随手 close接收方通常无法确定其他生产者是否结束。关闭后仍有发送会直接 panic。12.3 多个生产者分别 close重复关闭会 panic。应由单一协调者在确认所有生产者退出后关闭。12.4 忘记处理 comma-ok关闭且排空后会持续返回零值。如果零值本身合法不检查ok就可能把“已结束”误当成真实数据。12.5 认为 close 会立即丢掉缓冲数据不会。已有数据会先被取完然后接收才得到零值和ok false。12.6 向 nil channel 通信它不会 panic而是永久阻塞。特别要检查结构体中尚未初始化的 channel 字段。12.7 用 len(ch) 做并发正确性判断len只是某一瞬间的观察。它可以用于监控不应成为“接下来一定不会阻塞”的保证。12.8 default 无限循环导致 CPU 打满for{select{casevalue:-ch:use(value)default:}}没有阻塞点的循环会疯狂空转。可以移除default或明确加入定时、退避和退出条件。12.9 只让消费者监听 context生产者如果仍卡在jobs - task消费者退出后它可能永久泄漏。每个可能阻塞的发送、接收都要考虑取消路径。12.10 看到 fatal deadlock 就认为是 Runtime 坏了Runtime 报告死锁往往是在提醒所有 G 都在等待而没有任何事件能改变条件。应该检查谁负责发送、谁负责关闭、缓冲容量和退出顺序。十三、channel 应该怎么选容量不存在“性能最佳容量”的通用数字可以从协作语义出发容量 0需要严格交接和同步确认容量 1允许一次状态或通知暂存常用于所有权转移容量等于 worker 数允许每个 worker 暂存一个结果容量等于可接受突发量吸收短时间流量尖峰容量非常大需要警惕只是把拥塞和内存增长推迟到以后。如果无法解释“为什么是这个容量”不要凭感觉写一个很大的数字。监控队列长度、发送阻塞时间、任务延迟和取消数量再根据真实负载调整。十四、总结柜子只是表面调度与同步才是核心最后把快递驿站的故事串起来make(chan T, n)创建hchan有缓冲 channel 使用环形队列保存值已有接收者时发送方优先直接交接有空位时才写入缓冲区条件不满足时goroutine 通过sudog进入sendq或recvq并由gopark挂起通信条件满足后另一方通过goready唤醒 G让它重新进入 GMP 调度close表示不再发送新值不会清空已有缓冲数据select同时等待多个 channel多个分支就绪时不会固定偏爱源码靠前者nil channel 永远不会就绪在普通通信中是陷阱在select中却可以动态禁用分支channel 建立的不只是数据传递还有明确的 happens-before 同步关系安全关闭的关键不是背口诀而是明确数据所有权和生命周期goroutine 泄漏经常不是“忘了写 return”而是某个 channel 操作永远等不到对方。一句话记忆无缓冲是当面交接有缓冲是快递柜满了寄件等空了取件等关门后旧件还能领。理解 channel 以后再回头看 GMP会发现两篇文章正好拼在一起channel 决定 G 为什么等待和何时被唤醒GMP 决定醒来的 G 由谁继续执行。参考资料Go 语言规范Channel types、Receive operator、Close 与 Select statementsGo Runtimechan.goGo Runtimeselect.goThe Go Memory ModelGo diagnosticsExecution tracerGo blogPipelines and cancellation本文示例使用 Go 1.26.5 编译并通过 Race Detector 验证。语言语义以规范为准Runtime 源码细节请以目标 Go 版本为准。个人小游戏
文章目录一、开场快递员到了取件人却还没来二、channel 不只是一个队列2.1 无缓冲 channel必须当面交接2.2 有缓冲 channel快递柜可以暂存三、make(chan T, n) 到底创建了什么3.1 buf 为什么是环形缓冲区3.2 为什么还需要一把锁四、发送一个值Runtime 会走哪条路4.1 地址存在吗nil channel4.2 驿站是否已经停止收件4.3 有没有正在等待的接收者4.4 缓冲区还有位置吗4.5 柜子满了怎么办五、接收一个值又会走哪条路5.1 nil channel永远等不到包裹5.2 有等待发送者直接交接或顺手补柜5.3 缓冲区有数据按 recvx 领取5.4 什么都没有进入 recvq六、sudog 是谁排队的是 goroutine 的“号码牌”七、close关门后柜子里的包裹还能取7.1 closechan 会唤醒谁7.2 为什么通常由发送方关闭7.3 range 为什么能自动结束八、select多个窗口谁先叫号就去谁那里8.1 多个 case 同时就绪怎么办8.2 default 是“现在办不了就先走”8.3 nil channel 在 select 中反而很有用九、happens-before交接的不只是值十、完整实战用 Worker Pool 运营快递驿站十一、怎么观察 channel 阻塞11.1 Race Detector 检查共享内存11.2 runtime/trace 看 goroutine 在哪里等待11.3 goroutine profile 看堆栈十二、最常见的十个坑12.1 把缓冲区当成无限队列12.2 接收方随手 close12.3 多个生产者分别 close12.4 忘记处理 comma-ok12.5 认为 close 会立即丢掉缓冲数据12.6 向 nil channel 通信12.7 用 len(ch) 做并发正确性判断12.8 default 无限循环导致 CPU 打满12.9 只让消费者监听 context12.10 看到 fatal deadlock 就认为是 Runtime 坏了十三、channel 应该怎么选容量十四、总结柜子只是表面调度与同步才是核心参考资料一、开场快递员到了取件人却还没来晚上九点一名快递员抱着最后一个包裹冲进驿站“这个件今天必须送到。”工作人员看了看空荡荡的取件区又看了看已经塞满的快递柜摊手说“柜子满了收件人也没来你得等等。”这句话几乎就是 channel 的运行规则没有快递柜时快递员和取件人必须同时出现才能当面交接有快递柜时快递员可以先把包裹放进去但柜子满了仍然要等待取件人来得太早柜子里又没有包裹也只能等待驿站停止收件后柜子里已有的包裹仍然可以继续领取如果驿站根本不存在快递员和取件人就会在错误的地址永远等下去。把故事中的角色换成 Go 的术语就是下面这张表快递驿站Go channel快递员发送数据的 goroutine取件人接收数据的 goroutine包裹channel 中传递的值快递柜有缓冲 channel 的环形队列等待寄件的队伍sendq等待取件的队伍recvq停止收件close(ch)不存在的驿站nil channel本文以 Go 1.26.5 的语言规范和 Runtime 源码为背景。channel 的语言语义属于兼容性承诺但hchan、sudog等 Runtime 内部实现可能随版本变化。二、channel 不只是一个队列很多人第一次学习 channel会把它理解成“线程安全队列”。这个说法能帮助入门却不够完整。队列主要解决“数据放在哪里”channel 同时解决了两件事通信把一个值从发送方交给接收方同步条件不满足时挂起 goroutine条件满足后再唤醒它。Go 鼓励使用通信来组织并发协作。发送语句ch-parcel接收语句parcel:-ch表面上只有一个箭头底层却可能经历直接交接、写入缓冲区、加入等待队列、挂起和唤醒等多条路径。2.1 无缓冲 channel必须当面交接ch:make(chanstring)没有指定容量容量就是 0。发送方和接收方必须在某个时刻同时准备好通信才能完成。funcmain(){ch:make(chanstring)gofunc(){ch-包裹 Afmt.Println(快递员交接完成)}()parcel:-ch fmt.Println(取件人收到,parcel)}如果没有接收者发送方不会把值扔在地上然后离开而是会阻塞。这种“必须见面”的特性让无缓冲 channel 同时成为一个同步点接收完成之前发送不会完成。2.2 有缓冲 channel快递柜可以暂存ch:make(chanstring,3)容量为 3表示最多暂存 3 个值ch-包裹 Ach-包裹 Bch-包裹 C此时即使还没有接收者前三次发送也能完成。第四个包裹到来时如果仍没人取件发送方才会阻塞。缓冲区改变了发送方和接收方必须同时到场的要求却没有取消背压生产速度长期大于消费速度柜子早晚会满。三、make(chan T, n) 到底创建了什么编译器和 Runtime 会把make(chan T, n)落到runtime.makechan。Runtime 中的核心对象叫hchan。下面是为了讲解而保留关键字段的简化示意并非原源码逐字复制typehchanstruct{qcountuint// 缓冲区当前元素数dataqsizuint// 缓冲区容量buf unsafe.Pointer elemsizeuint16closeduint32sendxuint// 下一次写入位置recvxuint// 下一次读取位置recvq waitq// 等待接收的 sudog 队列sendq waitq// 等待发送的 sudog 队列lock mutex}3.1 buf 为什么是环形缓冲区容量为 3 的 channel不需要在每次接收后把剩余元素整体向前搬动。Runtime 使用sendx和recvx记录写入、读取位置到达尾部后绕回开头。假设依次发送 A、B、C槽位 [ A ][ B ][ C ] recvx ↑ sendx ↑ 下一次绕回 0但当前队列已满 qcount3接收 A 后再发送 D槽位 [ D ][ B ][ C ] recvx ↑ sendx ↑ qcount3物理位置绕圈复用逻辑顺序仍然是 B、C、D。3.2 为什么还需要一把锁多个 goroutine 可能同时发送、接收或关闭同一个 channel。qcount、索引、等待队列和关闭状态必须保持一致因此hchan内部用锁保护关键状态。这不等于“所有 channel 永远串行、性能一定很差”。Runtime 会先尝试快速路径真正修改共享状态时再进入临界区如果已经有配对的等待者还可能直接交接数据绕过缓冲区。四、发送一个值Runtime 会走哪条路普通发送最终会进入runtime.chansend。可以把判断顺序理解成驿站工作人员依次问四个问题。4.1 地址存在吗nil channelvarchchanintch-1ch的零值是 nil。阻塞式发送到 nil channel会通过gopark永久挂起它不会 panic也不会自动创建 channel。这像快递员拿着一个不存在的驿站地址等待永远不会有人来开门。4.2 驿站是否已经停止收件如果closed ! 0发送会 panicpanic: send on closed channel因为关闭表达的是“以后不会再产生新值”。继续发送会破坏接收方赖以判断完成的协议所以 Go 选择直接暴露错误而不是悄悄丢数据。4.3 有没有正在等待的接收者如果recvq中已经有接收者发送方会把值直接复制给它然后调用goready让对应 goroutine 重新变为可运行。即使这是有缓冲 channel只要存在等待接收者也优先直接交接不必先把包裹放进柜子再取出来。4.4 缓冲区还有位置吗如果没有等待接收者但qcount dataqsiz值会写入sendx指向的槽位将元素复制到缓冲区sendx向后移动必要时绕回 0qcount加 1发送完成当前 goroutine 继续执行。4.5 柜子满了怎么办如果既没有接收者缓冲区也没有空位Runtime 会取得当前 goroutine分配一个sudog记录 goroutine、待发送值和 channel将sudog加入sendq调用gopark挂起当前 goroutine。注意挂起的是 G不是必须把操作系统线程 M 一起堵住。M 可以继续拿到其他可运行的 G这正是上一篇 Go GMP 调度模型 中讲过的调度协作。五、接收一个值又会走哪条路接收由runtime.chanrecv处理思路和发送镜像相似。5.1 nil channel永远等不到包裹varchchanintvalue:-ch阻塞式接收会永久挂起。如果程序中没有其他可运行 goroutineRuntime 最终可能报告fatal error: all goroutines are asleep - deadlock!5.2 有等待发送者直接交接或顺手补柜如果sendq中有发送者无缓冲 channel直接从发送者复制到接收者已满的有缓冲 channel接收者先取走recvx位置的旧值再把等待发送者的新值补进同一个槽位。第二种情况很像取件人刚打开一个满柜工作人员马上把排队的下一个包裹补进去。一次临界区操作同时完成“取旧件”和“放新件”。5.3 缓冲区有数据按 recvx 领取qcount 0时接收方从recvx读取清空槽位移动索引并将qcount减 1。5.4 什么都没有进入 recvq既没有等待发送者缓冲区也为空接收 goroutine 会被封装成sudog加入recvq然后通过gopark休眠等待发送或关闭操作将它唤醒。六、sudog 是谁排队的是 goroutine 的“号码牌”很多人看到sendq、recvq会以为队列中直接放着 G。真实实现中间还有一层sudog。一个 goroutine 可能同时参与多个同步等待。例如select{casevalue:-ch1:fmt.Println(value)casech2-task:fmt.Println(sent)}同一个 G 同时关注多个 channel因此不能简单地把一个 G 节点塞进某个队列。sudog负责描述“一次具体等待关系”其中会关联等待的 goroutine对应的 channel待发送或接收值的位置是否来自select唤醒后操作是否成功。当条件不满足时当前 G → sudog → sendq/recvq → gopark另一方到来或 channel 被关闭时队列取出 sudog → 设置结果 → goready(G) → 重新参与 GMP 调度goready并不保证这个 G 立刻在当前 CPU 上运行它只是让 G 恢复 runnable之后仍由调度器选择合适的 P 和 M 执行。七、close关门后柜子里的包裹还能取channel 的关闭语义经常被误解。close(ch)不是销毁对象也不是清空缓冲区而是在协议层宣布不会再有新值发送进来。ch:make(chanint,2)ch-10ch-20close(ch)fmt.Println(-ch)// 10fmt.Println(-ch)// 20fmt.Println(-ch)// 0前两个值仍按顺序取出。缓冲区耗尽后继续接收会立即得到元素类型的零值。为了区分“真的发送过一个零值”和“channel 已关闭且排空”使用 comma-okvalue,ok:-chif!ok{fmt.Println(驿站已关门柜子也空了)}7.1 closechan 会唤醒谁关闭时Runtime 会标记closed取出所有等待者然后在释放 channel 锁之后唤醒它们recvq中的接收者被唤醒得到零值和ok falsesendq中的发送者也被唤醒但它们恢复执行后会 panic。先释放锁再批量goready可以避免在持有 channel 锁时修改其他 G 的状态而引入锁顺序问题。7.2 为什么通常由发送方关闭接收方往往不知道是否还有其他生产者准备发送。它擅自关闭就可能让正常发送者 panic。实践中可以遵循由能够确认“不会再发送新值”的一方负责关闭。多生产者场景常用WaitGroup等待所有生产者结束再由一个协调 goroutine 关闭 channel。7.3 range 为什么能自动结束forvalue:rangech{fmt.Println(value)}range会持续接收直到 channel 已关闭且缓冲区已经排空。如果发送者永远不关闭接收循环可能永远等下去。八、select多个窗口谁先叫号就去谁那里select用来同时等待多个 channel 操作select{casetask:-jobs:handle(task)caseresults-result:fmt.Println(结果已提交)case-ctx.Done():returnctx.Err()}可以把它想成站在多个窗口之间哪个窗口先能办理就去哪个窗口。8.1 多个 case 同时就绪怎么办规范规定当多个通信分支都能执行时会从可执行分支中做伪随机选择。不要假设源码书写靠前的 case 永远优先。Runtime 的selectgo会构造随机化的轮询顺序并按稳定顺序给涉及的 channel 加锁以降低偏置并避免多 channel 锁顺序死锁。8.2 default 是“现在办不了就先走”select{casech-value:fmt.Println(发送成功)default:fmt.Println(当前不能发送)}带default的select不会等待。它适合尽力而为的通知、指标采样等场景但如果放在没有休眠的无限循环中可能制造 CPU 空转。8.3 nil channel 在 select 中反而很有用单独向 nil channel 发送或接收会永久阻塞放进select时对应 case 永远不会就绪相当于动态关闭一个分支varoutchan-intifready{outrealChannel}select{caseout-value:fmt.Println(ready 时才可能执行)case-ctx.Done():}把变量重新设为 nil就能暂时禁用该 case而不需要再写一层复杂条件判断。九、happens-before交接的不只是值channel 还能建立内存可见性关系。varmessagestringdone:make(chanstruct{})gofunc(){message包裹已签收close(done)}()-done fmt.Println(message)根据 Go 内存模型关闭 channel 发生在因该关闭而返回零值的接收之前。因此主 goroutine 接收到关闭信号后能够观察到之前对message的写入。常用规则可以记住三条一次发送发生在对应接收完成之前一次关闭发生在因关闭而返回的接收之前容量为 C 的 channel第 k 次接收发生在第 kC 次发送完成之前。第三条解释了为什么有限缓冲 channel 可以充当并发信号量容量限定了最多有多少个任务进入临界区域。不过channel 的同步关系只覆盖实际建立的发送、接收和关闭事件。不要用len(ch)判断“下一次发送一定不阻塞”读取长度和真正发送之间其他 goroutine 随时可能改变状态。十、完整实战用 Worker Pool 运营快递驿站下面的示例包含三个快递员、任务 channel、结果 channel、WaitGroup、超时取消和安全关闭顺序。packagemainimport(contextfmtsynctime)typeParcelstruct{IDintAddressstring}typeResultstruct{ParcelIDintWorkerIDintStatusstring}funcworker(ctx context.Context,idint,jobs-chanParcel,resultschan-Result,wg*sync.WaitGroup,){deferwg.Done()for{select{case-ctx.Done():returncaseparcel,ok:-jobs:if!ok{return}timer:time.NewTimer(20*time.Millisecond)select{case-ctx.Done():timer.Stop()returncase-timer.C:}result:Result{ParcelID:parcel.ID,WorkerID:id,Status:已入柜parcel.Address,}select{caseresults-result:case-ctx.Done():return}}}}funcmain(){ctx,cancel:context.WithTimeout(context.Background(),2*time.Second)defercancel()jobs:make(chanParcel,3)results:make(chanResult,3)varworkers sync.WaitGroup workers.Add(3)forid:1;id3;id{goworker(ctx,id,jobs,results,workers)}gofunc(){deferclose(jobs)forid:1;id5;id{select{casejobs-Parcel{ID:id,Address:fmt.Sprintf(%d 号柜,id)}:case-ctx.Done():return}}}()gofunc(){workers.Wait()close(results)}()forresult:rangeresults{fmt.Printf(包裹 %d%s快递员 %d\n,result.ParcelID,result.Status,result.WorkerID)}}这段代码有三个关键关闭原则生产任务的 goroutine 最了解何时停止发送因此由它关闭jobs单个 worker 不关闭results因为它不知道其他 worker 是否仍在发送协调 goroutine 等全部 worker 结束后再关闭results让主 goroutine 的range正常退出。示例中的 channel 参数还声明了方向jobs-chanParcel resultschan-Result它不会改变底层 channel却能让编译器阻止 worker 错误地向jobs发送或从results接收相当于给驿站员工写清岗位权限。十一、怎么观察 channel 阻塞11.1 Race Detector 检查共享内存gotest-race./...channel 本身支持并发使用不代表 channel 外部的共享变量就自动安全。Race Detector 可以发现没有通过 channel、锁或原子操作建立同步的数据访问。11.2 runtime/trace 看 goroutine 在哪里等待程序中启动 tracefile,_:os.Create(trace.out)trace.Start(file)defertrace.Stop()运行后查看go tool trace trace.out在 trace 中可以观察 goroutine 的运行、阻塞和唤醒区分它是在等 channel send、channel receive、select、锁还是网络事件。11.3 goroutine profile 看堆栈线上 goroutine 数量持续增长时可以通过net/http/pprof查看 goroutine profile。常见堆栈会直接出现chan send chan receive select如果同一类堆栈不断增加通常意味着生产消费失衡、缺少取消路径、channel 没有关闭或者下游已经退出而上游仍在发送。十二、最常见的十个坑12.1 把缓冲区当成无限队列缓冲只能吸收短期波动。长期生产速度更快时要么发送方阻塞要么应用自行丢弃、降级或扩容。12.2 接收方随手 close接收方通常无法确定其他生产者是否结束。关闭后仍有发送会直接 panic。12.3 多个生产者分别 close重复关闭会 panic。应由单一协调者在确认所有生产者退出后关闭。12.4 忘记处理 comma-ok关闭且排空后会持续返回零值。如果零值本身合法不检查ok就可能把“已结束”误当成真实数据。12.5 认为 close 会立即丢掉缓冲数据不会。已有数据会先被取完然后接收才得到零值和ok false。12.6 向 nil channel 通信它不会 panic而是永久阻塞。特别要检查结构体中尚未初始化的 channel 字段。12.7 用 len(ch) 做并发正确性判断len只是某一瞬间的观察。它可以用于监控不应成为“接下来一定不会阻塞”的保证。12.8 default 无限循环导致 CPU 打满for{select{casevalue:-ch:use(value)default:}}没有阻塞点的循环会疯狂空转。可以移除default或明确加入定时、退避和退出条件。12.9 只让消费者监听 context生产者如果仍卡在jobs - task消费者退出后它可能永久泄漏。每个可能阻塞的发送、接收都要考虑取消路径。12.10 看到 fatal deadlock 就认为是 Runtime 坏了Runtime 报告死锁往往是在提醒所有 G 都在等待而没有任何事件能改变条件。应该检查谁负责发送、谁负责关闭、缓冲容量和退出顺序。十三、channel 应该怎么选容量不存在“性能最佳容量”的通用数字可以从协作语义出发容量 0需要严格交接和同步确认容量 1允许一次状态或通知暂存常用于所有权转移容量等于 worker 数允许每个 worker 暂存一个结果容量等于可接受突发量吸收短时间流量尖峰容量非常大需要警惕只是把拥塞和内存增长推迟到以后。如果无法解释“为什么是这个容量”不要凭感觉写一个很大的数字。监控队列长度、发送阻塞时间、任务延迟和取消数量再根据真实负载调整。十四、总结柜子只是表面调度与同步才是核心最后把快递驿站的故事串起来make(chan T, n)创建hchan有缓冲 channel 使用环形队列保存值已有接收者时发送方优先直接交接有空位时才写入缓冲区条件不满足时goroutine 通过sudog进入sendq或recvq并由gopark挂起通信条件满足后另一方通过goready唤醒 G让它重新进入 GMP 调度close表示不再发送新值不会清空已有缓冲数据select同时等待多个 channel多个分支就绪时不会固定偏爱源码靠前者nil channel 永远不会就绪在普通通信中是陷阱在select中却可以动态禁用分支channel 建立的不只是数据传递还有明确的 happens-before 同步关系安全关闭的关键不是背口诀而是明确数据所有权和生命周期goroutine 泄漏经常不是“忘了写 return”而是某个 channel 操作永远等不到对方。一句话记忆无缓冲是当面交接有缓冲是快递柜满了寄件等空了取件等关门后旧件还能领。理解 channel 以后再回头看 GMP会发现两篇文章正好拼在一起channel 决定 G 为什么等待和何时被唤醒GMP 决定醒来的 G 由谁继续执行。参考资料Go 语言规范Channel types、Receive operator、Close 与 Select statementsGo Runtimechan.goGo Runtimeselect.goThe Go Memory ModelGo diagnosticsExecution tracerGo blogPipelines and cancellation本文示例使用 Go 1.26.5 编译并通过 Race Detector 验证。语言语义以规范为准Runtime 源码细节请以目标 Go 版本为准。个人小游戏
![[C++]内存管理：串顺序存储的内存回收](http://pic.xiahunao.cn/yaotu/[C++]内存管理：串顺序存储的内存回收)
