[!info] 关联笔记

• 所属 MOC：并发 MOC · 学习路线
• 前置：channel、goroutine、select
• 后续：worker pool、pipeline、并发模式、context
• 相关：nil 形态、sync

Go channel 所有权与关闭

这个概念为什么会出现

channel 把“谁可以发送、谁可以接收、何时结束”绑在同一条管道上。若发送、接收、关闭三者“大家都能碰”，很快出现：

• 向已关闭 channel 发送 → panic
• 重复 close → panic
• 无人 close → range 永久阻塞（goroutine 泄漏）
• 接收方擅自 close → 与发送方竞态
• 多发送者各自 close → 竞态 panic

**所有权（ownership）**把 channel 当成有负责人的资源：谁有权发送、谁在何时关闭、接收方如何退出与排空。这是并发代码可推理的前提，也是 pipeline / fan-in / worker pool 的共同地基。

[!abstract] 一句话理解 关闭表示“不会再有新值”；通常由唯一发送所有权方（或协调完所有发送者之后的一方）关闭。接收方负责消费与退出，而不是关闭共享发送通道。

最小可运行示例

业务场景：后台生成任务 ID，前台逐个处理

比如管理后台点“批量创建 3 个导出任务”：

1. 后台 goroutine 负责生产任务编号
2. 前台 for range 负责消费并处理
3. 生产结束后必须发“没有更多任务了”的信号，前台才能退出循环

这个信号就是 close(channel)。
关键纪律：谁发送，谁关闭；消费者只读，不关。

package main

import "fmt"

// startExportJobs 模拟“提交 n 个导出任务”。
// 返回值类型是 <-chan int：调用方只能接收，不能发送/关闭。
// 这在类型上把“所有权”固定住了。
func startExportJobs(n int) <-chan int {
	// 双向 channel 只在函数内部持有
	out := make(chan int)

	// 后台生产者：唯一有权发送和关闭 out 的角色
	go func() {
		// 无论正常结束还是中途 return，都关闭 channel
		// 关闭 = 告诉消费者“不会再有新任务”
		defer close(out)

		for i := 1; i <= n; i++ {
			// 发送任务 ID；无缓冲时会等待消费者准备好
			out <- i
		}
		// 函数结束时 defer 执行 close(out)
	}()

	// 交给外部的是只读视图
	return out
}

func main() {
	// 消费者：处理任务流
	// range 会一直读到 channel 关闭并且缓冲排空
	for jobID := range startExportJobs(3) {
		fmt.Println("processing export job", jobID)
	}
	fmt.Println("all jobs done")
}

建议运行：

go run .

期望输出：

processing export job 1
processing export job 2
processing export job 3
all jobs done

模式要点（对着场景记）

1. 创建者返回 <-chan T：前台想关也关不了，避免消费者误 close。
2. 内部 goroutine 独占发送：所有权单一。
3. defer close(out)：任务发完一定有结束信号，range 才能停。
4. 若多个生产者写同一个 channel，需要另有协调者在全部结束后 close（见后文）。

核心概念与准确模型

1. close 的语义

对 channel 调用 close：

1. 标记“不再有新发送”
2. 已阻塞的接收者被唤醒；若缓冲仍有数据先读完
3. 缓冲排空后，接收立即得到零值，且 ok == false
4. range 终止

不是：

• 通用析构器
• 中断正在进行的业务函数的魔法
• “清空并丢弃所有人状态”

规范：Close、Channel types、Receive operator

2. 会 panic 的操作

操作	结果
向已关闭 channel 发送	panic
关闭已关闭 channel	panic
关闭 nil channel	panic
从已关闭 channel 接收	不 panic：得零值，ok=false
向 nil channel 发送/接收	永久阻塞（不 panic）

见 go-nil-forms。

3. 单向类型固化所有权

func stage(in <-chan Req, out chan<- Resp) {
	defer close(out)
	for r := range in {
		out <- handle(r)
	}
}

• <-chan：只能收
• chan<-：只能发
• 双向 chan：仅留给拥有完整控制权的创建处

单向转换是编译期约束，帮助审查“谁不该 close”。

4. 单一发送者（最简且优选）

一个 goroutine 发送 → 它负责 close → 多个接收者 range/读

多接收者竞争同一 channel 合法；关闭仍只一次，由发送者执行。

5. 多发送者：必须协调后关闭

**错误：**每个 worker close(out)
**正确：**WaitGroup 等全部发送结束后，一个 closer 关闭

func fanIn(cs ...<-chan int) <-chan int {
	out := make(chan int)
	var wg sync.WaitGroup
	wg.Add(len(cs))
	for _, c := range cs {
		c := c
		go func() {
			defer wg.Done()
			for v := range c {
				out <- v
			}
		}()
	}
	go func() {
		wg.Wait()
		close(out)
	}()
	return out
}

要点：

• worker 不 close out
• 单独 goroutine 等 Wait 后 close
• 输入侧 cs 应由各自拥有者关闭，以便 worker 的 range 结束

6. 接收方何时可以 close？

仅当接收方同时是发送所有权协议的一部分且文档保证无其他发送者——实际上这几乎总是坏味道。

经验法则：

接收方不关闭它正在从中接收的、由上游拥有的 channel。

接收方要停止时：

• cancel context
• 关闭自己拥有的 done/cancel 信号 channel
• 或不再读，但要确保发送方能感知并退出（否则发送方泄漏）

7. 完成信号的几种表达

手段	含义
close(ch)	数据流结束（常用于数据 channel）
done := make(chan struct{}); close(done)	广播“停止/完成”事件
context.Cancel	请求树取消
WaitGroup	等待一组 goroutine，不传递数据

不要混用语义：数据 channel 的 close 表示“无更多数据”；控制 channel 的 close 表示“事件已发生”。

8. 排空（draining）

关闭后接收方应：

for v := range ch {
	process(v)
}

或：

for {
	v, ok := <-ch
	if !ok {
		break
	}
	process(v)
}

若提前退出循环且发送方仍可能发送，必须有取消协议，否则发送方阻塞泄漏。

9. 与 select、默认分支

select {
case v, ok := <-ch:
	if !ok {
		// 已关闭且空
	}
case <-ctx.Done():
	return ctx.Err()
}

关闭与取消同时存在时，要定义优先级与是否排空剩余。见 go-select、go-context。

10. 不关闭 channel 可以吗？

可以。当：

• 没有 range 依赖关闭
• 进程/任务结束由其他同步（WaitGroup）完成
• channel 生命周期与进程同终，GC 回收

但：

• range 需要关闭或另设退出
• “永远不关”若伴随阻塞发送，仍可能泄漏

关闭不是必须的内存管理动作；它是协议信号。

11. 缓冲与关闭

• 关闭时缓冲中剩余数据仍可被接收
• 关闭后发送仍 panic（即使缓冲未满）
• 设计上：关闭前应保证无发送者再发

12. nil channel 技巧（高级）

在 select 中把 case 设为 nil channel 可禁用该分支：

var out chan<- int
if backpressure {
	out = nil // 禁用发送 case
} else {
	out = realOut
}
select {
case out <- v:
case <-ctx.Done():
}

这与所有权正交，但是退出/背压控制的常用手段。见 go-nil-forms。

13. 所有权文档化

导出 API 若接受或返回 channel，必须写清：

// Watch returns a channel of events.
// The channel is closed when the watcher stops or ctx is done.
// The caller must not close the channel.
func Watch(ctx context.Context) <-chan Event

模糊文档 = 未来 panic。

边界与限制

1. close 不是分布式取消：跨进程无效。
2. 类型系统不能完全防止错误 close：单向类型有帮助，但同一包内仍可能误用。
3. 关闭后读零值：可能掩盖“业务零值 vs 关闭”的区分——需要 ok 或包装 Optional。
4. 性能：close 与 channel 操作有成本；热路径要测量，但正确性优先。
5. panic 不可当控制流：用协议避免“尝试发送看是否 panic”。
6. 与 Mutex 混用：共享状态仍要锁；channel 不自动保护外部 map。
7. 公平性与顺序：多接收者时元素给谁不确定。
8. 测试：泄漏用超时 + goleak；竞态用 -race。

常见误区

[!warning] 误区 1：每个 goroutine 结束都 close 同一个 channel 重复 close → panic。要单一 closer。

[!warning] 误区 2：接收方 close 以“通知发送方停止” 应用 done/context；接收方 close 数据通道极易竞态。

[!warning] 误区 3：不 close 也能 range range 将永久阻塞。

[!warning] 误区 4：close 会打断对方已经开始的函数 只影响 channel 操作语义，不自动 abort 任意代码。

[!warning] 误区 5：从关闭 channel 读会 panic 不会；发送到关闭 channel 才会。

[!warning] 误区 6：为了“干净”总是 defer close 双向共享 channel 先问谁拥有发送权。

[!warning] 误区 7：用 panic/recover 处理 send on closed 应修所有权，而不是捕获 panic。

[!warning] 误区 8：fan-in 在某个 worker 里 close out 其他 worker 仍可能发送 → panic。

工程实践

所有权检查清单

1. 谁创建 channel？
2. 谁被允许发送？几个发送者？
3. 谁 close？只有一个吗？
4. 接收者如何知道结束？
5. 取消时发送者如何解除阻塞？
6. API 返回的是 <-chan 还是双向？

推荐模式库

1. 生产者返回 <-chan + 内部 close
2. pipeline 阶段 defer close(out)
3. fan-in：WaitGroup + 单 closer goroutine
4. 任务输入 channel：由调度器关闭 jobs，worker 不关
5. 用 ctx 取消，而不是关别人的数据 channel

worker pool 中的角色

主 goroutine：创建 jobs、results；投递任务；关闭 jobs
worker：从 jobs 收；向 results 发；不关 results
closer：WaitGroup 等 worker 结束后关 results
消费者：range results

见 go-worker-pool。

错误通道

errc := make(chan error, 1) // 缓冲 1 避免发送错误时阻塞

错误 channel 的所有权同样要清晰；常只发送一次错误后结束。

Code Review 红线

• 看到 close 就问“发送者都退出了吗？”
• 看到返回 chan T（双向）就问“能否改成单向？”
• 看到接收循环无 ctx/done 就问“如何停止？”

实验

实验 A：send on closed

package main

func main() {
	ch := make(chan int)
	close(ch)
	ch <- 1 // panic
}

实验 B：双 close

ch := make(chan int)
close(ch)
close(ch) // panic

实验 C：关闭后排空

package main

import "fmt"

func main() {
	ch := make(chan int, 2)
	ch <- 1
	ch <- 2
	close(ch)
	for v := range ch {
		fmt.Println(v)
	}
	v, ok := <-ch
	fmt.Println(v, ok) // 0 false
}

实验 D：错误 fan-in closer

写两个发送者都 close(out)，用 race 与多次运行观察 panic。再改成 WaitGroup 单 closer。

实验 E：取消与泄漏

发送方无 select ctx，接收方提前 return：观察发送方是否卡住。修复为：

select {
case out <- v:
case <-ctx.Done():
	return
}

总结

问题	答案
close 表示什么？	无更多发送
谁 close？	发送所有权方或协调后的唯一 closer
接收方职责？	消费、排空、用 ctx/done 退出
多发送者？	WaitGroup/信号汇合后单次 close
必须 close 吗？	非必须；range/协议需要时才关
最大危险？	send/close on closed、泄漏、所有权模糊

一句话收束：

把 channel 当有主人的管道：一人（协议上）负责关，其他人负责按协议读与停。

自测题

1. 为什么接收方关闭上游数据 channel 通常是错的？

2. fan-in 中 WaitGroup 的作用？

3. 关闭后 v, ok := <-ch 的 ok 何时为 false？

4. 不 close channel 是否一定内存泄漏？

5. 返回 <-chan T 如何帮助所有权？

6. 向 nil channel 发送与向 closed channel 发送的区别？

答案

1. 发送方可能仍发送 → panic；停止信号应用 ctx/done。
2. 等待所有转发/发送 goroutine 结束后再唯一 close。
3. channel 已关闭且缓冲为空时。
4. 不一定；channel 可被 GC。泄漏通常来自阻塞的 goroutine，而非“未 close”本身。
5. 编译期阻止外部发送与 close。
6. nil：永久阻塞；closed：panic。

依据与延伸

• Go Spec — Channel types
• Go Spec — Close
• Go Spec — Receive operator
• Go Spec — Send statements
• Effective Go — Channels
• Go Blog — Pipelines
• Go Blog — Share Memory By Communicating
• Go Blog — Advanced Concurrency Patterns
• sync.WaitGroup
• context