Merge remote-tracking branch 'upstream/master'

Conflicts:
	eBook/14.4.md

	modified:   README.md
	modified:   README_gc.md
	modified:   eBook/14.3.md
	modified:   eBook/14.4.md
	modified:   eBook/14.5.md

README.md

@@ -9,7 +9,7 @@
 
 ## 翻译进度
 
-14.2 [使用通道进行协程间通信](eBook/14.2.md)
+14.6 [协程和恢复（recover）](eBook/14.6.md)
 
 ## 支持本书
 

README_gc.md

@@ -32,4 +32,4 @@ Golang 编程：245386165
 
 |更新日期    |更新内容
 |----------|------------------
-|2015-1-4|14.2 使用通道进行协程间通信
+|2015-1-6|14.6 协程和恢复（recover）

eBook/14.3.md

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

eBook/14.4.md

@@ -1,6 +1,11 @@
-# 14.4 使用select切换协程
+# 14.4 使用 select 切换协程
 
+从不不同的并发执行的协程中获取值可以通过关键字 `select` 来完成，它和 `switch` 控制语句非常相似（第 5.3 节）也被称作通信开关；它的行为像是“你准备好了吗”的轮询机制；`select` 监听进入通道的数据，也可以是用通道发送值的时候。
+
+<<<<<<< HEAD
 从不同的并发执行的协程中获取值可以通过关键字`select`来完成，它和`switch`控制语句非常相似（章节5.3）也被称作通信开关；它的行为像是“你准备好了吗”的轮询机制；`select`监听进入通道的数据，也可以是用通道发送值的时候。
+=======
+>>>>>>> upstream/master
 ```go
 select {
 case u:= <- ch1:
@@ -12,20 +17,30 @@ default: // no value ready to be received
         ...
 }
 ```
-`default`语句是可选的；fallthrough行为，和普通的switch相似，是不允许的。在任何一个case中执行`break`或者`return`，select就结束了。
 
+<<<<<<< HEAD
 `select`做的就是：选择处理列出的多个通信情况中的一个。
 * 如果都阻塞了，会等待直到其中一个可以处理
 * 如果多个可以处理，随机选择一个
 * 如果没有通道操作可以处理并且写了`default`语句，它就会执行：`default`永远是可运行的（这就是准备好了，可以执行）。
+=======
+`default` 语句是可选的；fallthrough 行为，和普通的 switch 相似，是不允许的。在任何一个 case 中执行 `break` 或者 `return`，select 就结束了。
+
+`select` 做得就是：选择处理列出的多个通信情况中的一个。
+
+- 如果都阻塞了，会等待直到其中一个可以处理
+- 如果多个可以处理，随机选择一个
+- 如果没有通道操作可以处理并且写了 `default` 语句，它就会执行：`default` 永远是可运行的（这就是准备好了，可以执行）。
+>>>>>>> upstream/master
 
-在`select`中使用发送操作并且有`default`可以确保发送不被阻塞！如果没有cases，select就会一直阻塞。
+在 `select` 中使用发送操作并且有 `default`可以确保发送不被阻塞！如果没有 case，select 就会一直阻塞。
 
-`select`语句实现了一种监听模式，通常用在（无限）循环中；在某种情况下，通过`break`语句使循环退出。
+`select` 语句实现了一种监听模式，通常用在（无限）循环中；在某种情况下，通过 `break` 语句使循环退出。
 
-在程序[goroutine_select.go](examples/chapter_14/goroutine_select.go)中有2个通道`ch1`和`ch2`，三个协程`pump1()`，`pump2()`和`suck()`。这是一个典型的生产者消费者模式。在无限循环中，`ch1`和`ch2`通过`pump1()`和`pump2()`填充整数；`suck()`也是在无限循环中轮询输入的，通过`select`语句获取`ch1`和`ch2`的整数并输出。选择哪一个case取决于哪一个通道收到了信息。程序在main执行1秒后结束。
+在程序 [goroutine_select.go](examples/chapter_14/goroutine_select.go) 中有 2 个通道 `ch1` 和 `ch2`，三个协程 `pump1()`、`pump2()` 和 `suck()`。这是一个典型的生产者消费者模式。在无限循环中，`ch1` 和 `ch2` 通过 `pump1()` 和 `pump2()` 填充整数；`suck()` 也是在无限循环中轮询输入的，通过 `select` 语句获取 `ch1` 和 `ch2` 的整数并输出。选择哪一个 case 取决于哪一个通道收到了信息。程序在 main 执行 1 秒后结束。
+
+示例 14.10-[goroutine_select.go](examples/chapter_14/goroutine_select.go)：
 
-示例 14.10-[goroutine_select.go](examples/chapter_14/goroutine_select.go)
 ```go
 package main
 
@@ -68,7 +83,9 @@ func suck(ch1, ch2 chan int) {
 	}
 }
 ```
+
 输出：
+
 ```
 Received on channel 2: 5
 Received on channel 2: 6
@@ -84,60 +101,62 @@ Received on channel 2: 47404
 Received on channel 1: 94346
 Received on channel 1: 94348
 ```
-一秒内的输出非常惊人，如果我们给它计数（goroutine_select2.go），得到了90000个左右的数字。
+
+一秒内的输出非常惊人，如果我们给它计数（goroutine_select2.go），得到了 90000 个左右的数字。
 
 ##练习：
 
-练习14.7：
-*	a）在练习5.4的for_loop.go中，有一个常见的for循环打印数字。在函数`tel`中实现一个for循环，用协程开始这个函数并在其中给通道发送数字。`main()`线程从通道中获取并打印。不要使用`time.Sleep()`来同步：[goroutine_panic.go](exercises/chapter_14/goroutine_panic.go)
-*	b）也许你的方案有效，可能会引发运行时的panic：`throw:all goroutines are asleep-deadlock!` 为什么会这样？你如何解决这个问题？[goroutine_close.go](exercises/chapter_14/goroutine_close.go)
-*	c）解决a）的另外一种方式：使用一个额外的通道传递给协程，然后在结束的时候随便放点什么进去。`main()`线程检查是否有数据发送给了这个通道，如果有就停止：[goroutine_select.go](exercises/chapter_14/goroutine_select.go)
+练习 14.7：
 
+- a）在练习 5.4 的 for_loop.go 中，有一个常见的 for 循环打印数字。在函数 `tel` 中实现一个 for 循环，用协程开始这个函数并在其中给通道发送数字。`main()` 线程从通道中获取并打印。不要使用 `time.Sleep()` 来同步：[goroutine_panic.go](exercises/chapter_14/goroutine_panic.go)
+- b）也许你的方案有效，可能会引发运行时的 panic：`throw:all goroutines are asleep-deadlock!` 为什么会这样？你如何解决这个问题？[goroutine_close.go](exercises/chapter_14/goroutine_close.go)
+- c）解决 a）的另外一种方式：使用一个额外的通道传递给协程，然后在结束的时候随便放点什么进去。`main()` 线程检查是否有数据发送给了这个通道，如果有就停止：[goroutine_select.go](exercises/chapter_14/goroutine_select.go)
 
-练习14.8：
 
-从示例6.10的斐波那契程序开始，制定解决方案，使斐波那契周期计算独立到协程中，并可以把结果发送给通道。
+练习 14.8：
 
-结束的时候关闭通道。`main()`函数读取通道并打印结果：[goFibonacci.go](exercises/chapter_14/gofibonacci.go)
+从示例 6.10 的斐波那契程序开始，制定解决方案，使斐波那契周期计算独立到协程中，并可以把结果发送给通道。
 
-使用练习6.9中的算法写一个更短的[gofibonacci2.go](exercises/chapter_14/gofibonacci2.go)
+结束的时候关闭通道。`main()` 函数读取通道并打印结果：[goFibonacci.go](exercises/chapter_14/gofibonacci.go)
 
-使用`select`语句来写，并让通道退出（[gofibonacci_select.go](exercises/chapter_14/gofibonacci_select.go)）
+使用练习 6.9 中的算法写一个更短的 [gofibonacci2.go](exercises/chapter_14/gofibonacci2.go)
 
-注意：当给结果计时并和6.10对比时，我们发现使用通道通信的性能开销有轻微削减；这个例子中的算法使用协程并非性能最好的选择；但是[gofibonacci3](exercises/chapter_14/gofibonacci3.go)方案使用了2个协程带来了3倍的提速。
+使用 `select` 语句来写，并让通道退出（[gofibonacci_select.go](exercises/chapter_14/gofibonacci_select.go)）
 
+注意：当给结果计时并和 6.10 对比时，我们发现使用通道通信的性能开销有轻微削减；这个例子中的算法使用协程并非性能最好的选择；但是 [gofibonacci3](exercises/chapter_14/gofibonacci3.go) 方案使用了 2 个协程带来了 3 倍的提速。
 
-练习14.9：
 
-做一个随机位生成器，程序可以提供无限的随机0或者1的序列：[random_bitgen.go](exercises/chapter_14/random_bitgen.go)
+练习 14.9：
 
+做一个随机位生成器，程序可以提供无限的随机 0 或者 1 的序列：[random_bitgen.go](exercises/chapter_14/random_bitgen.go)
 
-练习14.10：[polar_to_cartesian.go](exercises/chapter_14/polar_to_cartesian.go)
+练习 14.10：[polar_to_cartesian.go](exercises/chapter_14/polar_to_cartesian.go)
 
-（这是一种综合练习，使用到章节4,9,11的内容和本章内容。）写一个可交互的控制台程序，要求用户输入二位平面极坐标上的点（半径和角度（度））。计算对应的笛卡尔坐标系的点的x和y并输出。使用极坐标和笛卡尔坐标的结构体。
+（这是一种综合练习，使用到第 4、9、11 章和本章的内容。）写一个可交互的控制台程序，要求用户输入二位平面极坐标上的点（半径和角度（度））。计算对应的笛卡尔坐标系的点的 x 和 y 并输出。使用极坐标和笛卡尔坐标的结构体。
 
 使用通道和协程：
-		`channel1`用来接收极坐标
-		`channel2`用来接收笛卡尔坐标
 
-转换过程需要在协程中进行，从channel1中读取然后发哦送到channel2。实际上做这种计算不提倡使用协程和通道，但是如果运算量很大很耗时，这种方案设计就非常合适了。
+- `channel1` 用来接收极坐标
+- `channel2` 用来接收笛卡尔坐标
 
+转换过程需要在协程中进行，从 channel1 中读取然后发哦送到 channel2。实际上做这种计算不提倡使用协程和通道，但是如果运算量很大很耗时，这种方案设计就非常合适了。
 
-练习14.11： [concurrent_pi.go](exercises/chapter_14/concurrent_pi.go) / [concurrent_pi2.go](exercises/chapter_14/concurrent_pi2.go)
+练习 14.11： [concurrent_pi.go](exercises/chapter_14/concurrent_pi.go) / [concurrent_pi2.go](exercises/chapter_14/concurrent_pi2.go)
 
-使用以下序列在协程中计算pi：开启一个协程来计算公式中的每一项并将结果放入通道，`main()`函数收集并累加结果，打印出pi的近似值。
+使用以下序列在协程中计算 pi：开启一个协程来计算公式中的每一项并将结果放入通道，`main()` 函数收集并累加结果，打印出 pi 的近似值。
 
 ![](../images/14.4_piseries.png?raw=true)
 
-计算执行时间（参见章节[6.11](6.11.md)）
+计算执行时间（参见第 [6.11](6.11.md) 节）
 
 再次声明这只是为了一边练习协程的概念一边找点乐子。
 
-如果你需要的话可使用`math.pi`中的Pi；而且不使用协程会运算的更快。一个急速版本：使用`GOMAXPROCS`，开启和`GOMAXPROCS`同样多个协程。
+如果你需要的话可使用 `math.pi` 中的 Pi；而且不使用协程会运算的更快。一个急速版本：使用 `GOMAXPROCS`，开启和 `GOMAXPROCS` 同样多个协程。
 
 习惯用法：后台服务模式
 
-服务通常是是用后台协程中的无限循环实现的，在循环中使用`select`获取并处理通道中的数据：
+服务通常是是用后台协程中的无限循环实现的，在循环中使用 `select` 获取并处理通道中的数据：
+
 ```go
 // Backend goroutine.
 func backend() {
@@ -153,9 +172,11 @@ func backend() {
 	}
 }
 ```
-在程序的其他地方给通道`ch1`，`ch2`发送数据，比如：通道`stop`用来清理结束服务程序。
 
-另一种方式（但是不太灵活）就是（客户端）在`chRequest`上提交请求，后台协程循环这个通道，使用`switch`根据请求的行为来分别处理：
+在程序的其他地方给通道 `ch1`，`ch2` 发送数据，比如：通道 `stop` 用来清理结束服务程序。
+
+另一种方式（但是不太灵活）就是（客户端）在 `chRequest` 上提交请求，后台协程循环这个通道，使用 `switch` 根据请求的行为来分别处理：
+
 ```go
 func backend() {
 	for req := range chRequest {

eBook/14.5.md

@@ -1,8 +1,9 @@
-# 14.5 通道，超时和计时器（Ticker）
+# 14.5 通道、超时和计时器（Ticker）
 
-`time`包中有一些有趣的功能可以和通道组合使用。
+`time` 包中有一些有趣的功能可以和通道组合使用。
+
+其中就包含了 `time.Ticker` 结构体，这个对象以指定的时间间隔重复的向通道 C 发送时间值：
 
-其中就包含了`time.Ticker`结构体，这个对象以指定的时间间隔重复的向通道C发送时间值：
 ```go
 type Ticker struct {
     C <-chan Time // the channel on which the ticks are delivered.
@@ -10,11 +11,13 @@ type Ticker struct {
     ...
 }
 ```
-时间间隔的单位是ns（纳秒，int64），在工厂函数`time.NewTicker`中以`Duration`类型的参数传入：`func Newticker(dur) *Ticker`
+
+时间间隔的单位是 ns（纳秒，int64），在工厂函数 `time.NewTicker` 中以 `Duration` 类型的参数传入：`func Newticker(dur) *Ticker`。
 
 在协程周期性的执行一些事情（打印状态日志，输出，计算等等）的时候非常有用。
 
-调用`Stop()`使计时器停止，在`defer`语句中使用。这些都很好的适应`select`语句:
+调用 `Stop()` 使计时器停止，在 `defer` 语句中使用。这些都很好的适应 `select` 语句:
+
 ```go
 ticker := time.NewTicker(updateInterval)
 defer ticker.Stop()
@@ -30,7 +33,8 @@ default: // no value ready to be received
     ...
 }
 ```
-`time.Tick()`函数声明为`Tick(d Duration) <-chan Time`，当你想返回一个通道而不必关闭它的时候这个函数非常有用：它以d为周期给返回的通道发送时间，d是纳秒数。如果需要像下边的代码一样，限制处理频率（函数`client.Call()`是一个RPC调用，这里暂不赘述（参见章节[15.9](15.9.md)））：
+
+`time.Tick()` 函数声明为 `Tick(d Duration) <-chan Time`，当你想返回一个通道而不必关闭它的时候这个函数非常有用：它以 d 为周期给返回的通道发送时间，d是纳秒数。如果需要像下边的代码一样，限制处理频率（函数 `client.Call()` 是一个 RPC 调用，这里暂不赘述（参见第 [15.9](15.9.md) 节）：
 
 ```go
 import "time"
@@ -43,19 +47,23 @@ for req := range requests {
     go client.Call("Service.Method", req, ...)
 }
 ```
-这样只会按照指定频率处理请求：`chRate`阻塞了更高的频率。每秒处理的频率可以根据机器负载（和/或）资源的情况而增加或减少。
 
-问题14.1：扩展上边的代码，思考如何承载周期请求数的暴增（提示：使用带缓冲通道和计时器对象）。
+这样只会按照指定频率处理请求：`chRate` 阻塞了更高的频率。每秒处理的频率可以根据机器负载（和/或）资源的情况而增加或减少。
+
+问题 14.1：扩展上边的代码，思考如何承载周期请求数的暴增（提示：使用带缓冲通道和计时器对象）。
 
-定时器（TImer）结构体看上去和计时器（Ticker）结构体的确很像（构造为`NewTimer(d Duration)`)），但是它只发送一次时间，在`Dration d`之后。
+定时器（Timer）结构体看上去和计时器（Ticker）结构体的确很像（构造为 `NewTimer(d Duration)`），但是它只发送一次时间，在 `Dration d` 之后。
+
+还有 `time.After(d)` 函数，声明如下：
 
-还有`time.After(d)`函数，声明如下：
 ```go
 func After(d Duration) <-chan Time
 ```
-在`Duration d`之后，当前时间被发到返回的通道；所以它和`NewTimer(d).C`是等价的；它类似`Tick()`，但是`After()`只发送一次时间。下边有个很具体的示例，很好的阐明了`select`中`default`的作用：
 
-示例14.11：[timer_goroutine.go](examples/chapter_14/timer_goroutine.go)：
+在 `Duration d` 之后，当前时间被发到返回的通道；所以它和 `NewTimer(d).C` 是等价的；它类似 `Tick()`，但是 `After()` 只发送一次时间。下边有个很具体的示例，很好的阐明了 `select` 中 `default` 的作用：
+
+示例 14.11：[timer_goroutine.go](examples/chapter_14/timer_goroutine.go)：
+
 ```go
 package main
 
@@ -81,7 +89,9 @@ func main() {
 	}
 }
 ```
+
 输出：
+
 ```
     .
     .
@@ -100,9 +110,11 @@ tick.
 tick.
 BOOM!
 ```
+
 习惯用法：简单超时模式
 
-要从通道`ch`中接收数据，但是最多等待1秒。先创建一个信号通道，然后启动一个`lambda`协程，协程在给通道发送数据之前是休眠的：
+要从通道 `ch` 中接收数据，但是最多等待1秒。先创建一个信号通道，然后启动一个 `lambda` 协程，协程在给通道发送数据之前是休眠的：
+
 ```go
 timeout := make(chan bool, 1)
 go func() {
@@ -110,7 +122,9 @@ go func() {
         timeout <- true
 }()
 ```
-然后使用`select`语句接收`ch`或者`timeout`的数据：如果`ch`在1秒内没有收到数据，就选择到了`time`分支并放弃了`ch`的读取。
+
+然后使用 `select` 语句接收 `ch` 或者 `timeout` 的数据：如果 `ch` 在 1 秒内没有收到数据，就选择到了 `time` 分支并放弃了 `ch` 的读取。
+
 ```go
 select {
     case <-ch:
@@ -120,9 +134,11 @@ select {
         break
 }
 ```
-第二种形式：取消耗时很长的同步调用：
 
-也可以使用`time.After()`函数替换`timeout-channel`。可以在`select`中使用以发送信号超时或停止协程的执行。以下代码，在`timeoutNs`纳秒后执行`select`的`timeout`分支时，`client.Call`不会给通道`ch`返回值：
+第二种形式：取消耗时很长的同步调用
+
+也可以使用 `time.After()` 函数替换 `timeout-channel`。可以在 `select` 中使用以发送信号超时或停止协程的执行。以下代码，在 `timeoutNs` 纳秒后执行 `select` 的 `timeout` 分支时，`client.Call` 不会给通道 `ch` 返回值：
+
 ```go
 ch := make(chan error, 1)
 go func() { ch <- client.Call("Service.Method", args, &reply) } ()
@@ -134,9 +150,11 @@ case <-time.After(timeoutNs):
     break
 }
 ```
-注意缓冲大小设置为1是必要的，可以避免协程死锁以及确保超时的通道可以被垃圾回收。
 
-第三种形式：假设程序从多个复制的数据库同时读取。只需要一个答案，需要接收首先到达的答案，`Query`函数获取数据库的连接切片并请求。并行请求每一个数据库并返回收到的第一个响应：
+注意缓冲大小设置为 1 是必要的，可以避免协程死锁以及确保超时的通道可以被垃圾回收。
+
+第三种形式：假设程序从多个复制的数据库同时读取。只需要一个答案，需要接收首先到达的答案，`Query` 函数获取数据库的连接切片并请求。并行请求每一个数据库并返回收到的第一个响应：
+
 ```go
 func Query(conns []conn, query string) Result {
     ch := make(chan Result, 1)
@@ -151,12 +169,13 @@ func Query(conns []conn, query string) Result {
     return <- ch
 }
 ```
-再次声明，结果通道`ch`必须是带缓冲的：以保证第一个发送进来的数据有地方可以存放，确保放入的首个数据总会成功，所以第一个到达的值会被获取而与执行的顺序无关。正在执行的协程可以总是可以使用`runtime.Goexit()`来停止。
+
+再次声明，结果通道 `ch` 必须是带缓冲的：以保证第一个发送进来的数据有地方可以存放，确保放入的首个数据总会成功，所以第一个到达的值会被获取而与执行的顺序无关。正在执行的协程可以总是可以使用 `runtime.Goexit()` 来停止。
 
 
 在应用中缓存数据：
 
-应用程序中用到了来自数据库（或者常见的数据存储）的数据时，经常会把数据缓存到内存中，因为从数据库中获取数据的操作代价很高；如果数据库中的值不发生变化就没有问题。但是如果值有变化，我们需要一个机制来周期性的从数据库重新读取这些值：缓存的值就不可用（过期）了，而且我们也不希望用户看到陈旧的数据。这篇文章：[http://www.tideland.biz/CachingValues](http://www.tideland.biz/CachingValues)（译者注：这个网页已经失效了）讨论了一种方式，使用协程和计时器对象来实现。
+应用程序中用到了来自数据库（或者常见的数据存储）的数据时，经常会把数据缓存到内存中，因为从数据库中获取数据的操作代价很高；如果数据库中的值不发生变化就没有问题。但是如果值有变化，我们需要一个机制来周期性的从数据库重新读取这些值：缓存的值就不可用（过期）了，而且我们也不希望用户看到陈旧的数据。
 
 ## 链接
 

eBook/14.6.md

@@ -1,7 +1,8 @@
 # 14.6 协程和恢复（recover）
 
-一个用到`recover`的程序（参见章节13.3）停掉了服务器内部一个失败的协程而不影响其他协程的工作。
-```go 
+一个用到 `recover` 的程序（参见第 13.3 节）停掉了服务器内部一个失败的协程而不影响其他协程的工作。
+
+```go
 func server(workChan <-chan *Work) {
     for work := range workChan {
         go safelyDo(work)   // start the goroutine for that work
@@ -17,9 +18,10 @@ func safelyDo(work *Work) {
     do(work)
 }
 ```
-上边的代码，如果`do(work)`发生panic，错误会被记录且协程会退出并释放，而其他协程不受影响。
 
-因为`recover`总是返回`nil`，除非直接在`defer`修饰的函数中调用，`defer`修饰的代码可以调用那些自身可以使用`panic`和`recover`避免失败的库例程（库函数）。举例，`safelyDo()`中`deffer`修饰的函数可能在调用`recover`之前就调用了一个`logging`函数，`panicking`状态不会影响`logging`代码的运行。因为加入了恢复模式，函数`do`（以及它调用的任何东西）可以通过调用`panic`来摆脱不好的情况。但是恢复是在`panicking`的协程内部的：不能被另外一个协程恢复。更多深入的细节处理可以在[http://www.tideland.biz/SupervisingGoroutines](http://www.tideland.biz/SupervisingGoroutines)（ref.43）找到。
+上边的代码，如果 `do(work)` 发生 panic，错误会被记录且协程会退出并释放，而其他协程不受影响。
+
+因为 `recover` 总是返回 `nil`，除非直接在 `defer` 修饰的函数中调用，`defer` 修饰的代码可以调用那些自身可以使用 `panic` 和 `recover` 避免失败的库例程（库函数）。举例，`safelyDo()` 中 `deffer` 修饰的函数可能在调用 `recover` 之前就调用了一个 `logging` 函数，`panicking` 状态不会影响 `logging` 代码的运行。因为加入了恢复模式，函数 `do`（以及它调用的任何东西）可以通过调用 `panic` 来摆脱不好的情况。但是恢复是在 `panicking` 的协程内部的：不能被另外一个协程恢复。
 
 
 ## 链接

eBook/directory.md

@@ -139,7 +139,7 @@
     - 14.1 [并发、并行和协程](14.1.md)
     - 14.2 [使用通道进行协程间通信](14.2.md)
     - 14.3 [协程同步：关闭通道-对阻塞的通道进行测试](14.3.md)
-    - 14.4 [使用select切换协程](14.4.md)
+    - 14.4 [使用 select 切换协程](14.4.md)
     - 14.5 [通道，超时和计时器（Ticker）](14.5.md)
     - 14.6 [协程和恢复（recover）](14.6.md)
 - 第15章：[网络、模版与网页应用](15.0.md)