Merge remote-tracking branch 'upstream/master'

This commit is contained in:
songleo
2016-01-03 14:06:34 +08:00
10 changed files with 391 additions and 51 deletions

View File

@@ -9,7 +9,7 @@
## 翻译进度
13.10 [性能调试:分析并优化 Go 程序](eBook/13.10.md)
14.1 [并发、并行和协程](eBook/14.1.md)
## 支持本书

View File

@@ -31,9 +31,4 @@ Golang 编程245386165
|更新日期 |更新内容
|----------|------------------
|2015-11-25|13.10 性能调试:分析并优化 Go 程序
|2015-12-10|15.0 15.1 15.2
|2015-12-12|15.3
|2015-12-22|15.4
|2015-12-25|14.1
|2015-12-28|14.2
|2015-12-31|14.1 并发、并行和协程

View File

@@ -1,8 +1,8 @@
# 14 协程goroutine与通道channel
作为一门21世纪的语言Go 原生支持应用之间的通信(网络,客户端和服务端,分布式计算,参见 15 章和程序的并发。程序可以在不同的处理器和计算机上同时执行不同的代码段。Go 语言为构建并发程序的基本代码块是 协程 (goroutine) 与通道 (channel)。他们需要语言编译器和runtime的支持。Go 语言提供的垃圾回收器对并发编程至关重要。
作为一门 21 世纪的语言Go 原生支持应用之间的通信(网络,客户端和服务端,分布式计算,参见 15 章和程序的并发。程序可以在不同的处理器和计算机上同时执行不同的代码段。Go 语言为构建并发程序的基本代码块是 协程 (goroutine) 与通道 (channel)。他们需要语言编译器和runtime的支持。Go 语言提供的垃圾回收器对并发编程至关重要。
*不要通过共享内存来通信,而通过通信来共享内存。*
**不要通过共享内存来通信,而通过通信来共享内存。**
通信强制协作。
@@ -10,4 +10,4 @@
- [目录](directory.md)
- 上一节:[性能调试:分析并优化 Go 程序](13.10.md)
- 下一节:[并发并行和协程](14.1.md)
- 下一节:[并发并行和协程](14.1.md)

View File

@@ -1,4 +1,4 @@
# 14.1 并发并行和协程
# 14.1 并发并行和协程
## 14.1.1 什么是协程
@@ -6,18 +6,17 @@
并行是一种通过使用多处理器以提高速度的能力。所以并发程序可以是并行的,也可以不是。
公认的,使用多线程的应用难以做到准确,最主要的问题是内存中的数据共享,它们会被多线程以无法预知的方式进行操作,导致一些无法重现或者随机的结果(称作 `竞态`)。
公认的,使用多线程的应用难以做到准确,最主要的问题是内存中的数据共享,它们会被多线程以无法预知的方式进行操作,导致一些无法重现或者随机的结果(称作`竞态`
**不要使用全局变量或者共享内存,它们会给你的代码在并发运算的时候带来危险。**
!!不要使用全局变量或者共享内存,它们会给你的代码在并发运算的时候带来危险
解决之道在于同步不同的线程,对数据加锁,这样同时就只有一个线程可以变更数据。在 Go 的标准库 `sync` 中有一些工具用来在低级别的代码中实现加锁;我们在第 [9.3](9.3.md) 节中讨论过这个问题。不过过去的软件开发经验告诉我们这会带来更高的复杂度,更容易使代码出错以及更低的性能,所以这个经典的方法明显不再适合现代多核/多处理器编程:`thread-per-connection` 模型不够有效
解决之道在于同步不同的线程对数据加锁这样同时就只有一个线程可以变更数据。在Go的标准库`sync`中有一些工具用来在低级别的代码中实现加锁;我们在章节[9.3](9.3.md)中讨论过这个问题。不过过去的软件开发经验告诉我们这会带来更高的复杂度,更容易使代码出错以及更低的性能,所以这个经典的方法明显不再适合现代多核/多处理器编程:"`thread-per-connection`"模型不够有效
Go更倾向于其他的方式在诸多比较合适的范式中有个被称作`Communicating Sequential Processes顺序通信处理`(CSP, C. Hoare发明的)还有一个叫做`message passing-model消息传递`已经运用在了其他语言中比如Eralng
Go 更倾向于其他的方式,在诸多比较合适的范式中,有个被称作 `Communicating Sequential Processes顺序通信处理`CSP, C. Hoare 发明的)还有一个叫做 `message passing-model消息传递`(已经运用在了其他语言中,比如 Eralng
在 Go 中,应用程序并发处理的部分被称作 `goroutines协程`,它可以进行更有效的并发运算。在协程和操作系统线程之间并无一对一的关系:协程是根据一个或多个线程的可用性,映射(多路复用,执行于)在他们之上的;协程调度器在 Go 运行时很好的完成了这个工作。
协程工作在相同的地址空间中,所以共享内存的方式一定是同步的;这个可以使用`sync`包来实现(参见章节[9.3](9.3.md))不过我们很不鼓励这样做Go使用`channels`来同步协程(可以参见[14.2](14.2.md)等章节)
协程工作在相同的地址空间中,所以共享内存的方式一定是同步的;这个可以使用 `sync` 包来实现(参见[9.3](9.3.md) 节)不过我们很不鼓励这样做Go 使用 `channels` 来同步协程(可以参见[14.2](14.2.md)等章节)
当系统调用(比如等待 I/O阻塞协程时其他协程会继续在其他线程上工作。协程的设计隐藏了许多线程创建和管理方面的复杂工作。
@@ -25,9 +24,9 @@ Go更倾向于其他的方式在诸多比较合适的范式中有个被称
协程可以运行在多个操作系统线程之间,也可以运行在线程之内,让你可以很小的内存占用就可以处理大量的任务。由于操作系统线程上的协程时间片,你可以使用少量的操作系统线程就能拥有任意多个提供服务的协程,而且 Go 运行时可以聪明的意识到哪些协程被阻塞了,暂时搁置它们并处理其他协程。
存在两种并发方式:确定性的(明确定义排序)和非确定性的(加锁/互斥从而未定义排序。Go的协程和通道理所当然的支持确定性的并发方式例如通道具有一个sender和一个receiver。我们会在章节[14.7](14.7.md)中使用一个常见的算法问题(工人问题)来对比两种处理方式。
存在两种并发方式:确定性的(明确定义排序)和非确定性的(加锁/互斥从而未定义排序。Go 的协程和通道理所当然的支持确定性的并发方式(例如通道具有一个 sender 和一个 receiver。我们会在[14.7](14.7.md)中使用一个常见的算法问题(工人问题)来对比两种处理方式。
协程是通过使用关键字`go`调用执行一个函数或者方法来实现的也可以是匿名或者lambda函数。这样会在当前的计算过程中开始一个同时进行的函数在相同的地址空间中并且分配了独立的栈比如`go sum(bigArray)`// 在后台计算总和
协程是通过使用关键字 `go` 调用(执行)一个函数或者方法来实现的(也可以是匿名或者 lambda 函数)。这样会在当前的计算过程中开始一个同时进行的函数,在相同的地址空间中并且分配了独立的栈,比如:`go sum(bigArray)`在后台计算总和
协程的栈会根据需要进行伸缩,不出现栈溢出;开发者不需要关心栈的大小。当协程结束的时候,它会静默退出:用来启动这个协程的函数不会得到任何的返回值。
@@ -49,11 +48,11 @@ Go的并发原语提供了良好的并发设计基础表达程序结构以便
## 14.1.3 使用 GOMAXPROCS
在gc编译器下6g或者8g你必须设置GOMAXPROCS为一个大于默认值1的数值来允许运行时支持使用多于1个的操作系统线程所有的协程都会共享同一个线程除非将GOMAXPROCS设置为一个大于1的数。当GOMAXPROCS大于1时,会有一个线程池管理许多的线程。通过`gccgo`编译器GOMAXPROCS有效的与运行中的协程数量相等。假设n是机器上处理器或者核心的数量。如果你设置环境变量GOMAXPROCS>=n或者执行`runtime.GOMAXPROCS(n)`,接下来协程会被分割(分散)到n个处理器上。更多的处理器并不意味着性能的线性提升。有这样一个经验法则,对于n个核心的情况设置GOMAXPROCSn-1以获得最佳性能也同样需要遵守这条规则协程的数量 > 1 + GOMAXPROCS > 1
gc 编译器下6g 或者 8g你必须设置 GOMAXPROCS 为一个大于默认值 1 的数值来允许运行时支持使用多于 1 个的操作系统线程,所有的协程都会共享同一个线程除非将 GOMAXPROCS 设置为一个大于 1 的数。当 GOMAXPROCS 大于 1 时,会有一个线程池管理许多的线程。通过 `gccgo` 编译器 GOMAXPROCS 有效的与运行中的协程数量相等。假设 n 是机器上处理器或者核心的数量。如果你设置环境变量 GOMAXPROCS>=n或者执行 `runtime.GOMAXPROCS(n)`,接下来协程会被分割(分散)到 n 个处理器上。更多的处理器并不意味着性能的线性提升。有这样一个经验法则,对于 n 个核心的情况设置 GOMAXPROCSn-1 以获得最佳性能,也同样需要遵守这条规则:协程的数量 > 1 + GOMAXPROCS > 1
所以如果在某一时间只有一个协程在执行,不要设置 GOMAXPROCS
还有一些通过实验观察到的现象:在一台1颗CPU的笔记本电脑上增加GOMAXPROCS到9会带来性能提升。在一台32核的机器上设置GOMAXPROCS=8会达到最好的性能在测试环境中更高的数值无法提升性能。如果设置一个很大的GOMAXPROCS只会带来轻微的性能下降设置GOMAXPROCS=100使用“top”命令和“H”选项查看到只有7个活动的线程。
还有一些通过实验观察到的现象:在一台 1 颗 CPU 的笔记本电脑上,增加 GOMAXPROCS 到 9 会带来性能提升。在一台 32 核的机器上,设置 GOMAXPROCS=8 会达到最好的性能,在测试环境中,更高的数值无法提升性能。如果设置一个很大的 GOMAXPROCS 只会带来轻微的性能下降;设置 GOMAXPROCS=100使用 `top` 命令和 `H` 选项查看到只有 7 个活动的线程。
增加 GOMAXPROCS 的数值对程序进行并发计算是有好处的;
@@ -64,6 +63,7 @@ Go的并发原语提供了良好的并发设计基础表达程序结构以便
## 14.1.4 如何用命令行指定使用的核心数量
使用 `flags` 包,如下:
```go
var numCores = flag.Int("n", 2, "number of CPU cores to use")
@@ -75,6 +75,7 @@ runtime.GOMAXPROCS(*numCores)
协程可以通过调用`runtime.Goexit()`来停止,尽管这样做几乎没有必要。
示例 14.1-[goroutine1.go](examples/chapter_14/goroutine1.go) 介绍了概念:
```go
package main
@@ -105,7 +106,9 @@ func shortWait() {
fmt.Println("End of shortWait()")
}
```
输出
输出:
```
In main()
About to sleep in main()
@@ -115,6 +118,7 @@ End of shortWait()
End of longWait()
At the end of main() // after 10s
```
`main()``longWait()``shortWait()` 三个函数作为独立的处理单元按顺序启动,然后开始并行运行。每一个函数都在运行的开始和结束阶段输出了消息。为了模拟他们运算的时间消耗,我们使用了 `time` 包中的 `Sleep` 函数。`Sleep()` 可以按照指定的时间来暂停函数或协程的执行这里使用了纳秒ns符号 1e9 表示 1 乘 10 的 9 次方e=指数)。
他们按照我们期望的顺序打印出了消息,几乎都一样,可是我们明白这是模拟出来的,以并行的方式。我们让 `main()` 函数暂停 10 秒从而确定它会在另外两个协程之后结束。如果不这样(如果我们让 `main()` 函数停止 4 秒),`main()` 会提前结束,`longWait()` 则无法完成。如果我们不在 `main()` 中等待,协程会随着程序的结束而消亡。
@@ -126,6 +130,7 @@ At the end of main() // after 10s
为了对比使用一个线程,连续调用的情况,移除 go 关键字,重新运行程序。
现在输出:
```
In main()
Beginning longWait()
@@ -135,19 +140,21 @@ End of shortWait()
About to sleep in main()
At the end of main() // after 17 s
```
协程更有用的一个例子应该是在一个非常长的数组中查找一个元素。
将数组分割为若干个不重复的切片,然后给每一个切片启动一个协程进行查找计算。这样许多并行的线程可以用来进行查找任务,整体的查找时间会缩短(除以协程的数量)。
## 14.1.5 Go 协程goroutines和协程coroutines
译者注标题中的“Go协程goroutines”即是14章讲的协程指的是go语言中的协程。而“协程coroutines”指的是其他语言中的协程概念仅在本节出现。
译者注标题中的“Go协程goroutines 即是 14 章讲的协程指的是 Go 语言中的协程。而“协程coroutines”指的是其他语言中的协程概念仅在本节出现。
在其他语言中,比如 C#Lua 或者 Python 都有协程的概念。这个名字表明它和 G o协程有些相似不过有两点不同
* go协程意味着并行或者可以以并行的方式部署协程一般来说不是这样的
* go协程通过通道来通信协程通过让出和恢复操作来通信
Go协程比协程更强大也很容易从协程的逻辑复用到go协程。
- Go 协程意味着并行(或者可以以并行的方式部署),协程一般来说不是这样的
- Go 协程通过通道来通信;协程通过让出和恢复操作来通信
Go 协程比协程更强大,也很容易从协程的逻辑复用到 Go 协程。
## 链接

View File

@@ -626,7 +626,6 @@ func main() {
}
```
## 链接
- [目录](directory.md)

110
eBook/14.3.md Normal file
View File

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

177
eBook/14.4.md Normal file
View File

@@ -0,0 +1,177 @@
# 14.4 使用select切换协程
从不不同的并发执行的协程中获取值可以通过关键字`select`来完成,它和`switch`控制语句非常相似章节5.3)也被称作通信开关;它的行为像是“你准备好了吗”的轮询机制;`select`监听进入通道的数据,也可以是用通道发送值的时候。
```go
select {
case u:= <- ch1:
...
case v:= <- ch2:
...
...
default: // no value ready to be received
...
}
```
`default`语句是可选的fallthrough行为和普通的switch相似是不允许的。在任何一个case中执行`break`或者`return`select就结束了。
`select`做得就是:选择处理列出的多个通信情况中的一个。
* 如果都阻塞了,会等待直到其中一个可以处理
* 如果多个可以处理,随机选择一个
* 如果没有通道操作可以处理并且写了`default`语句,它就会执行:`default`永远是可运行的(这就是准备好了,可以执行)。
`select`中使用发送操作并且有`default`可以确保发送不被阻塞如果没有casesselect就会一直阻塞。
`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秒后结束。
示例 14.10-[goroutine_select.go](examples/chapter_14/goroutine_select.go)
```go
package main
import (
"fmt"
"time"
)
func main() {
ch1 := make(chan int)
ch2 := make(chan int)
go pump1(ch1)
go pump2(ch2)
go suck(ch1, ch2)
time.Sleep(1e9)
}
func pump1(ch chan int) {
for i := 0; ; i++ {
ch <- i * 2
}
}
func pump2(ch chan int) {
for i := 0; ; i++ {
ch <- i + 5
}
}
func suck(ch1, ch2 chan int) {
for {
select {
case v := <-ch1:
fmt.Printf("Received on channel 1: %d\n", v)
case v := <-ch2:
fmt.Printf("Received on channel 2: %d\n", v)
}
}
}
```
输出:
```
Received on channel 2: 5
Received on channel 2: 6
Received on channel 1: 0
Received on channel 2: 7
Received on channel 2: 8
Received on channel 2: 9
Received on channel 2: 10
Received on channel 1: 2
Received on channel 2: 11
...
Received on channel 2: 47404
Received on channel 1: 94346
Received on channel 1: 94348
```
一秒内的输出非常惊人如果我们给它计数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.8
从示例6.10的斐波那契程序开始,制定解决方案,使斐波那契周期计算独立到协程中,并可以把结果发送给通道。
结束的时候关闭通道。`main()`函数读取通道并打印结果:[goFibonacci.go](exercises/chapter_14/gofibonacci.go)
使用练习6.9中的算法写一个更短的[gofibonacci2.go](exercises/chapter_14/gofibonacci2.go)
使用`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.10[polar_to_cartesian.go](exercises/chapter_14/polar_to_cartesian.go)
这是一种综合练习使用到章节4,9,11的内容和本章内容。写一个可交互的控制台程序要求用户输入二位平面极坐标上的点半径和角度。计算对应的笛卡尔坐标系的点的x和y并输出。使用极坐标和笛卡尔坐标的结构体。
使用通道和协程:
`channel1`用来接收极坐标
`channel2`用来接收笛卡尔坐标
转换过程需要在协程中进行从channel1中读取然后发哦送到channel2。实际上做这种计算不提倡使用协程和通道但是如果运算量很大很耗时这种方案设计就非常合适了。
练习14.11 [concurrent_pi.go](exercises/chapter_14/concurrent_pi.go) / [concurrent_pi2.go](exercises/chapter_14/concurrent_pi2.go)
使用以下序列在协程中计算pi开启一个协程来计算公式中的每一项并将结果放入通道`main()`函数收集并累加结果打印出pi的近似值。
![](../images/14.4_piseries.png?raw=true)
计算执行时间(参见章节[6.11](6.11.md)
再次声明这只是为了一边练习协程的概念一边找点乐子。
如果你需要的话可使用`math.pi`中的Pi而且不使用协程会运算的更快。一个急速版本使用`GOMAXPROCS`,开启和`GOMAXPROCS`同样多个协程。
习惯用法:后台服务模式
服务通常是是用后台协程中的无限循环实现的,在循环中使用`select`获取并处理通道中的数据:
```go
// Backend goroutine.
func backend() {
for {
select {
case cmd := <-ch1:
// Handle ...
case cmd := <-ch2:
...
case cmd := <-chStop:
// stop server
}
}
}
```
在程序的其他地方给通道`ch1``ch2`发送数据,比如:通道`stop`用来清理结束服务程序。
另一种方式(但是不太灵活)就是(客户端)在`chRequest`上提交请求,后台协程循环这个通道,使用`switch`根据请求的行为来分别处理:
```go
func backent() {
for req := range chRequest {
switch req.Subjext() {
case A1: // Handle case ...
case A2: // Handle case ...
default:
// Handle illegal request ..
// ...
}
}
}
```
## 链接
- [目录](directory.md)
- 上一节:[通道的同步:关闭通道-测试阻塞的通道](14.3.md)
- 下一节:[通道,超时和计时器](14.5.md)

51
eBook/14.5.md Normal file
View File

@@ -0,0 +1,51 @@
# 14.5 通道,超时和计时器
`time`包中有一些有趣的功能可以和通道组合使用。
其中就包含了`time.Ticker`结构体这个对象以指定的时间间隔重复的向通道C发送时间值
```go
type Ticker struct {
C <-chan Time // the channel on which the ticks are delivered.
// contains filtered or unexported fields
...
}
```
时间间隔的单位是ns纳秒int64在工厂函数`time.NewTicker`中以`Duration`类型的参数传入:`func Newticker(dur) *Ticker`
在协程周期性的执行一些事情(打印状态日志,输出,计算等等)的时候非常有用。
调用`Stop()`使计时器停止,在`defer`语句中使用。这些都很好的适应`select`语句:
```go
ticker := time.NewTicker(updateInterval)
defer ticker.Stop()
...
select {
case u:= <-ch1:
...
case v:= <-ch2:
...
case <-ticker.C:
logState(status) // call some logging function logState
default: // no value ready to be received
...
}
```
`time.Tick()`函数声明为`Tick(d Duration) <-chan Time`当你想返回一个通道而不必关闭它的时候这个函数非常有用它以d为周期给返回的通道发送时间d是纳秒数。如果需要像下边的代码一样限制处理频率函数`client.Call()`是一个RPC调用这里暂不赘述参见章节[15.9](15.9.md)
```go
import "time"
rate_per_sec := 10
var dur Duration = 1e9 / rate_per_sec
chRate := time.Tick(dur) // a tick every 1/10th of a second
for req := range requests {
<- chRate // rate limit our Service.Method RPC calls
go client.Call("Service.Method", req, ...)
}
```
## 链接
- [目录](directory.md)
- 上一节:[使用select切换协程](14.4.md)
- 下一节:[对协程使用recover](14.6.md)

View File

@@ -136,9 +136,10 @@
- 13.9 [用(测试数据)表驱动测试](13.9.md)
- 13.10 [性能调试:分析并优化 Go 程序](13.10.md)
- 第14章[协程goroutine与通道channel](14.0.md)
- 14.1 [并发并行和协程](14.1.md)
- 14.1 [并发并行和协程](14.1.md)
- 14.2 [使用通道进行协程间通信](14.2.md)
- 14.3 [协程同步:关闭通道-对阻塞的通道进行测试](14.3.md)
- 14.4 [使用select切换协程](14.4.md)
- 第15章[网络、模版与网页应用](15.0.md)
- 15.1 [tcp服务器](15.1.md)
- 15.2 [一个简单的web服务器](15.2.md)

BIN
images/14.4_piseries.png Normal file

Binary file not shown.

After

Width:  |  Height:  |  Size: 13 KiB