# 14.3 协程的同步：关闭通道-测试阻塞的通道
通道可以被显式的关闭；尽管它们和文件不同：不必每次都关闭。只有在当需要告诉接收者不会再提供新的值的时候，才需要关闭通道。只有发送者需要关闭通道，接收者永远不会需要。
继续看示例 goroutine2.go（示例 14.2）：我们如何在通道的 sendData() 完成的时候发送一个信号，getData() 又如何检测到通道是否关闭或阻塞？
第一个可以通过函数 close(ch) 来完成：这个将通道标记为无法通过发送操作 <- 接受更多的值；给已经关闭的通道发送或者再次关闭都会导致运行时的 panic。在创建一个通道后使用 defer 语句是个不错的办法（类似这种情况）：
ch := make(chan float64)
defer close(ch)
2
第二个问题可以使用逗号，ok 操作符：用来检测通道是否被关闭。
如何来检测可以收到没有被阻塞（或者通道没有被关闭）？
v, ok := <-ch // ok is true if v received value
通常和 if 语句一起使用：
if v, ok := <-ch; ok {
process(v)
}
2
3
或者在 for 循环中接收的时候，当关闭或者阻塞的时候使用 break：
v, ok := <-ch
if !ok {
break
}
process(v)
2
3
4
5
在示例程序 14.2 中使用这些可以改进为版本 goroutine3.go，输出相同。
实现非阻塞通道的读取，需要使用 select（参见第 14.4 节）。
示例 14.9-goroutine3.go：
package main
import "fmt"
func main() {
ch := make(chan string)
go sendData(ch)
getData(ch)
}
func sendData(ch chan string) {
ch <- "Washington"
ch <- "Tripoli"
ch <- "London"
ch <- "Beijing"
ch <- "Tokio"
close(ch)
}
func getData(ch chan string) {
for {
input, open := <-ch
if !open {
break
}
fmt.Printf("%s ", input)
}
}
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
改变了以下代码：
- 现在只有
sendData()是协程，getData()和main()在同一个线程中：
go sendData(ch)
getData(ch)
2
- 在
sendData()函数的最后，关闭了通道：
func sendData(ch chan string) {
ch <- "Washington"
ch <- "Tripoli"
ch <- "London"
ch <- "Beijing"
ch <- "Tokio"
close(ch)
}
2
3
4
5
6
7
8
- 在 for 循环的
getData()中，在每次接收通道的数据之前都使用if !open来检测：
for {
input, open := <-ch
if !open {
break
}
fmt.Printf("%s ", input)
}
2
3
4
5
6
7
使用 for-range 语句来读取通道是更好的办法，因为这会自动检测通道是否关闭：
for input := range ch {
process(input)
}
2
3
阻塞和生产者-消费者模式：
在第 14.2.10 节的通道迭代器中，两个协程经常是一个阻塞另外一个。如果程序工作在多核心的机器上，大部分时间只用到了一个处理器。可以通过使用带缓冲（缓冲空间大于 0）的通道来改善。比如，缓冲大小为 100，迭代器在阻塞之前，至少可以从容器获得 100 个元素。如果消费者协程在独立的内核运行，就有可能让协程不会出现阻塞。
由于容器中元素的数量通常是已知的，需要让通道有足够的容量放置所有的元素。这样，迭代器就不会阻塞（尽管消费者协程仍然可能阻塞）。然而，这实际上加倍了迭代容器所需要的内存使用量，所以通道的容量需要限制一下最大值。记录运行时间和性能测试可以帮助你找到最小的缓存容量带来最好的性能。