Go channel 怎样设计生产者关闭边界

多个生产者共享一个 Go channel 时，不应让每个生产者都 defer close。关闭权交给一个协调者：它等所有发送者结束，再关闭输出；消费者只接收，提前离开时发取消信号，而不是关闭生产者仍可能使用的 channel。这样解决的是生命周期正确性，不能仅凭代码结构就声称吞吐量提高。

本文使用固定四批输入、每批 250 个整数的原创示例，以消息数量和收尾耗时作为观察指标。数字是可复现的负载设定，不是线上基线或已执行的压测结果。官方文档入口：https://go.dev/ref/spec#Close。

先定义消息总数与结束条件

先把一次完整运行的条件写清：四个生产者分别发送一批数据，消费者持续读取到输出关闭。无取消且发送者正常返回时，目标消息数为 1000。记录的不是“看起来没有阻塞”，而是完整接收计数、一次调用耗时和分配量。取消场景另记录从发出取消到输出被排空关闭的收尾耗时，不能拿提前结束的少量工作与完整处理直接比吞吐量。

基线还需要注明 Go 版本、GOMAXPROCS、通道容量、输入大小与消费者行为。下面使用无缓冲输出，让阻塞发送更容易暴露；它不是所有业务的最佳容量。关闭并不会丢弃已进入缓冲区的值，也不是给垃圾回收“释放通道”。它表达的是没有后续发送，供接收者结束读取。

把关闭权与发送完成分开

“由生产者关闭”更准确的解释是由发送侧的生命周期所有者关闭。一个生产者独占输出时，它自己负责关闭；多个生产者共享输出时，任何一个生产者结束，都不代表其他发送者已经结束。解决假设是把发送能力与关闭责任分开，而不是在每个发送者里添加 recover。

本例包含生产者、out、senders、关闭协调者和消费者五个实体。发送侧分组容纳生产者与 out；生命周期分组包含 senders 与关闭协调者；接收侧只有消费者。生产者与 out 存在发送关系，生产者与 senders 存在任务登记关系，关闭协调者依赖 senders 并承担 out 的关闭责任，消费者与 out 存在接收关系。

sync.Once 能限制重复 close，却不能证明没有其他 goroutine 继续发送。第一次关闭仍可能与另一个发送并发发生。正确边界必须同时满足“只关闭一次”和“关闭前没有剩余发送”，这两条不能互相替代。

多生产者使用一个关闭协调者

把下列示例保存为业务包中的实现。Produce 返回只接收通道，隐藏关闭权。每个输入批次拥有一个发送 goroutine；WaitGroup 在启动任务前统一 Add，每个任务用 defer Done，协调者只负责等待与关闭。这里没有复制输入内容，调用期间不得并发修改 batches 的底层数组。

package stream

import (
    "context"
    "sync"
)

// Produce 的输入切片在调用期间不得被并发修改。
// 输出只接收接口；调用者不能关闭结果通道。
func Produce(ctx context.Context, batches [][]int) 

先 Add 再启动任务，是为了避免协调者把未登记任务当成已经完成。Done 位于任务返回路径，而不是每次成功发送后，因此取消和正常结束都能注销该发送者。循环内检查 ctx.Err，再用 select 将阻塞发送与取消等待放在一起；检查和 select 之间仍可能发生取消，所以这不是“取消后绝不会再交付一条值”的强保证。

消费者要持续读到关闭。如果只需要前几条，应调用自己拥有的 cancel，然后根据业务需要排空结果或等待其他完成信号。不能直接 close(out)，更不能先等待所有发送者再开始接收：无缓冲通道的发送可能正等待接收，形成相互等待。ctx 必须是非 nil 的有效上下文。

用固定负载记录收尾指标

下面是与同包实现配套的基准入口，供读者复现。计数断言保障测量覆盖完整负载；它不是本文已经执行过的测试。不要用 runtime.NumGoroutine 的单次读数作为“绝无泄漏”的唯一证明，其他运行时活动也会影响读数。

package stream

import (
    "context"
    "testing"
)

// BenchmarkProduce 以完整排空作为一轮基准，计数不是实测性能结果。
func BenchmarkProduce(b *testing.B) {
    batches := make([][]int, 4)
    for i := range batches {
        batches[i] = make([]int, 250)
    }
    b.ReportAllocs()
    b.ResetTimer()
    for round := 0; round 

运行入口可使用：

# 在包含实现与基准文件的 Go 模块中执行，并重复采样。
go test -run '^$' -bench BenchmarkProduce -benchmem -count=5
# 若要检查并发访问问题，应独立执行实际测试，不混入性能对比。
go test -race ./...

复现时补充两组场景：消费者完整排空，检查消息数为 1000；消费者读取少量数据后 cancel，再继续排空至关闭，记录收尾耗时。第二组不要求消息数固定，因为取消与就绪发送可能同时可选。若输出一直不关闭，先检查阻塞操作是否观察取消、任务是否一定调用 Done，再考虑调度与业务处理耗时。

指标对象包括固定输入、BenchmarkProduce、接收计数、分配记录、取消信号和收尾耗时。负载定义分组包含固定输入与 BenchmarkProduce；正常观测分组包含接收计数与分配记录；取消观测分组包含取消信号与收尾耗时。它们是测量关系，不是绘制出来的压测成绩。

对照结构差异而非编造提速

表里的“四个”和“一个”是关闭责任结构的计数，不是 benchmark 输出。这个改动的主要收益是消除多方关闭及提前关闭的设计风险；额外协调 goroutine 与 WaitGroup 也有成本。是否需要优化，必须基于相同负载的实际测量。增大缓冲区会改变背压与内存占用，但不会补齐错误的关闭所有权。

取消、空输入与接口限制

空输入如何处理？本例登记零个发送者，协调者的 Wait 可以立即返回并关闭输出，消费者 range 结束；不需要返回 nil 通道，后者会让接收长期阻塞。

可以从接收端判断通道尚未关闭再发送吗？不能把瞬间观察当成关闭与发送之间的同步协议。关闭状态可能随后变化。用明确所有权与发送者完成条件约束行为，而不是用 len 或试探接收构造“安全发送”。

关闭意味着处理成功吗？不意味着。本例只用它表达没有更多结果；取消可能导致部分交付。如果要表达失败原因，另设计错误返回或结果对象，不能把“range 结束”当作业务全部成功。

生产者执行外部 I/O 怎么办？将 ctx 传给支持取消的底层调用。仅在 channel select 中观察取消，无法打断另一个不观察 ctx 的阻塞操作；WaitGroup 也不会自动终止 goroutine。动态注册发送者需要新的生命周期协议，不能在计数归零后随意 Add 并继续复用同一个已关闭输出。

本例的设计取舍是：共享输出隐藏在 Produce 内部，发送者只负责发送与退出，关闭协调者等待完整任务集合，消费者通过取消协议表达“不再需要”。只接收类型限制消费者关闭，但发送型通道在语言层面仍允许 close；唯一关闭责任仍必须由接口与封装保证。

参考官方资料：关闭语义 https://go.dev/ref/spec#Close；发送者完成与取消的原理 https://go.dev/blog/pipelines；WaitGroup 契约 https://pkg.go.dev/sync#WaitGroup。本文实现、负载和测量入口为原创，不是官方示例的复制，也不宣称已完成压测。