Golang Channel：带缓冲、无缓冲、关闭与 range

发送和接收

通道是 goroutine 之间带类型的管道。ch <- v 表示发送，<-ch 表示接收。用 make 创建通道：

package main

import "fmt"

func main() {
	messages := make(chan string)

	go func() {
		messages <- "ping" // blocks until main receives
	}()

	msg := <-messages // blocks until the goroutine sends
	fmt.Println(msg)
}

通道类型的零值是 nil，所以只写 var ch chan string 而不用 make，得到的通道会永远阻塞。请始终用 make 创建通道。

无缓冲通道用于同步

make(chan T) 创建一个无缓冲通道。发送会阻塞，直到接收方取走值；接收也会阻塞，直到发送方提供一个值。两个 goroutine 在这一点会合，因此无缓冲通道既是数据管道，也是同步工具。下面的 <-done 返回时，你就知道 worker 在发送之前的所有工作都已完成：

package main

import "fmt"

func main() {
	done := make(chan struct{})
	result := 0

	go func() {
		for i := 1; i <= 100; i++ {
			result += i
		}
		done <- struct{}{} // signal: finished
	}()

	<-done
	fmt.Println("sum:", result)
}

这里在 main 中读取 result 不需要互斥锁也是安全的。Go 的内存模型保证：worker 在发送之前做的所有事情，在对应的接收完成后对 main 都可见。chan struct{} 是纯信号的惯用类型，因为 struct{} 不占内存。

带缓冲通道

make(chan T, n) 给通道留出存放 n 个值的空间。缓冲区满之前，没有接收方发送也能成功；缓冲区空之前，接收都能成功。值按照放入的顺序取出。

package main

import "fmt"

func main() {
	ch := make(chan int, 3)

	ch <- 10
	ch <- 20
	fmt.Println("len:", len(ch), "cap:", cap(ch))

	ch <- 30 // buffer now full; a fourth send here would block forever

	fmt.Println(<-ch, <-ch, <-ch)
	fmt.Println("len:", len(ch))
}

缓冲区让发送方和接收方解耦，短时间的突发流量不会让发送方停下来。但它解决不了生产者一直比消费者快的问题，只是推迟了发送方阻塞的时刻。选择缓冲区大小要有依据（发送方的数量、已知的批量大小），而不是为了让死锁消失。

len(ch) 只是一个快照。等你根据它采取行动时，另一个 goroutine 可能已经改变了它，所以不要用它来判断发送是否会阻塞。这种情况请使用带 default 分支的 select。

关闭与 range

close(ch) 告诉接收方不会再有值发送过来。关闭之后：

• 缓冲区中已有的值仍会被送达，
• 之后每次接收都会立即返回零值，
• v, ok := <-ch 会得到 ok == false，
• for v := range ch 会结束。

package main

import "fmt"

func produce(n int) <-chan int {
	ch := make(chan int)
	go func() {
		defer close(ch) // the sender closes, when it is done
		for i := range n {
			ch <- i * i
		}
	}()
	return ch
}

func main() {
	for v := range produce(5) {
		fmt.Println(v)
	}

	ch := make(chan string, 1)
	ch <- "last"
	close(ch)
	v, ok := <-ch
	fmt.Printf("%q %v\n", v, ok)
	v, ok = <-ch
	fmt.Printf("%q %v\n", v, ok)
}

close 之后的第一次接收仍然拿到 "last"，且 ok == true。第二次拿到零值 "" 和 false。

会导致 panic 的规则：

• 向已关闭的通道发送会 panic，报错 send on closed channel，
• 关闭已经关闭的通道会 panic，
• 关闭 nil 通道会 panic。

所以只有发送方关闭通道，而且只关闭一次。有多个发送方时，没有哪个发送方知道其他发送方何时结束；这时让一个单独的 goroutine 等待所有发送方（用 sync.WaitGroup），在 Wait 返回后关闭通道。只有在接收方需要等待结束信号时才需要关闭。没有关闭、也没有任何引用的通道会像其他值一样被垃圾回收。

方向类型

函数可以声明它对某个通道只发送或只接收，编译器随后会拒绝另一种操作。

把 chan T 传给函数时，它会隐式转换为任意一种受限类型。这就是上面的 produce 可以返回 <-chan int 的原因：调用方可以用 range 遍历它，但不能向它发送，也不能关闭它。在所有适用的函数参数上都使用方向类型。它们说明了所有权，并把误用变成编译错误。

死锁

如果每个 goroutine 都被阻塞，并且没有任何东西能唤醒它们，运行时就会终止程序：

package main

import "fmt"

func main() {
	ch := make(chan int)
	ch <- 1 // no other goroutine exists to receive
	fmt.Println(<-ch)
}

fatal error: all goroutines are asleep - deadlock!

goroutine 1 [chan send]:
main.main()
	/tmp/main.go:7 +0x38
exit status 2

goroutine 转储会告诉你哪个操作卡住了（这里是 chan send，也可能是 chan receive、sync.WaitGroup.Wait、select）。常见原因：

• 向无缓冲通道发送，却没有正在运行的接收方，
• 对一个永远不会关闭的通道使用 range，
• WaitGroup 计数器永远到不了零，
• 两个 goroutine 互相等待对方。

运行时只能检测出所有 goroutine 都卡住的情况。在还有其他 goroutine 存活的服务器中（HTTP 监听器、定时器），同样的 bug 不会让程序崩溃，被阻塞的 goroutine 只会悄悄泄漏。

nil 通道

在 nil 通道上发送和接收都会永远阻塞。这听起来毫无用处，但在 select 中是一个常用技巧：把通道变量设为 nil 就能禁用它所在的分支。下面的代码合并两个通道，并在每个通道关闭后不再监听它：

package main

import "fmt"

func main() {
	a := make(chan int)
	b := make(chan int)
	go func() { defer close(a); a <- 1; a <- 2 }()
	go func() { defer close(b); b <- 10 }()

	sum := 0
	for a != nil || b != nil {
		select {
		case v, ok := <-a:
			if !ok {
				a = nil // a is finished: never select it again
				continue
			}
			sum += v
		case v, ok := <-b:
			if !ok {
				b = nil
				continue
			}
			sum += v
		}
	}
	fmt.Println("sum:", sum)
}

如果没有这些 nil 赋值，已关闭的通道总是处于就绪状态，循环就会在零值上空转。

流水线

通道可以组合成流水线：每个阶段都是一个 goroutine，从一个通道接收、向下一个通道发送，并在输入结束时关闭自己的输出。

package main

import "fmt"

func generate(nums ...int) <-chan int {
	out := make(chan int)
	go func() {
		defer close(out)
		for _, n := range nums {
			out <- n
		}
	}()
	return out
}

func square(in <-chan int) <-chan int {
	out := make(chan int)
	go func() {
		defer close(out)
		for n := range in {
			out <- n * n
		}
	}()
	return out
}

func main() {
	total := 0
	for v := range square(square(generate(1, 2, 3))) {
		fmt.Println(v)
		total += v
	}
	fmt.Println("total:", total)
}

每个阶段并发运行，而输出顺序是确定的（1、16、81），因为每个阶段都是单个 goroutine，会保持顺序。关闭会逐级传递：generate 关闭后，square 的 range 结束，它随即关闭自己的输出，依此类推，一直传到 main。

这条流水线的弱点：如果 main 提前停止读取，各个阶段就会永远阻塞在发送上。真实的流水线会接收一个 context.Context 或 done 通道，并在每次发送时用 select 同时监听它。

通道还是互斥锁

通道用于转移数据的所有权和发出事件信号。对于许多 goroutine 就地读取和更新的共享状态（比如缓存或计数器），用 sync.Mutex 保护更简单。内部带互斥锁的结构体，往往比一个拥有状态并通过通道响应请求的 goroutine 更清晰。哪种写法能让代码更短、所有权更明显，就用哪种。

速查表