Skip to content

Commit

Permalink
14.5-14.6
Browse files Browse the repository at this point in the history
  • Loading branch information
unknwon committed Jan 5, 2016
1 parent 7ccbf39 commit 5942213
Show file tree
Hide file tree
Showing 4 changed files with 47 additions and 26 deletions.
2 changes: 1 addition & 1 deletion README.md
Original file line number Diff line number Diff line change
Expand Up @@ -9,7 +9,7 @@

## 翻译进度

14.4 [使用 select 切换协程](eBook/14.4.md)
14.6 [协程和恢复(recover)](eBook/14.6.md)

## 支持本书

Expand Down
2 changes: 1 addition & 1 deletion README_gc.md
Original file line number Diff line number Diff line change
Expand Up @@ -31,4 +31,4 @@ Golang 编程:245386165

|更新日期 |更新内容
|----------|------------------
|2015-1-5|14.4 使用 select 切换协程
|2015-1-6|14.6 协程和恢复(recover)
59 changes: 39 additions & 20 deletions eBook/14.5.md
Original file line number Diff line number Diff line change
@@ -1,20 +1,23 @@
# 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.
// contains filtered or unexported fields
...
}
```
时间间隔的单位是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()
Expand All @@ -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"
Expand All @@ -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

Expand All @@ -81,7 +89,9 @@ func main() {
}
}
```

输出:

```
.
.
Expand All @@ -100,17 +110,21 @@ tick.
tick.
BOOM!
```

习惯用法:简单超时模式

要从通道`ch`中接收数据,但是最多等待1秒。先创建一个信号通道,然后启动一个`lambda`协程,协程在给通道发送数据之前是休眠的:
要从通道 `ch` 中接收数据,但是最多等待1秒。先创建一个信号通道,然后启动一个 `lambda` 协程,协程在给通道发送数据之前是休眠的:

```go
timeout := make(chan bool, 1)
go func() {
time.Sleep(1e9) // one second
timeout <- true
}()
```
然后使用`select`语句接收`ch`或者`timeout`的数据:如果`ch`在1秒内没有收到数据,就选择到了`time`分支并放弃了`ch`的读取。

然后使用 `select` 语句接收 `ch` 或者 `timeout` 的数据:如果 `ch` 在 1 秒内没有收到数据,就选择到了 `time` 分支并放弃了 `ch` 的读取。

```go
select {
case <-ch:
Expand All @@ -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) } ()
Expand All @@ -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)
Expand All @@ -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)(译者注:这个网页已经失效了)讨论了一种方式,使用协程和计时器对象来实现。
应用程序中用到了来自数据库(或者常见的数据存储)的数据时,经常会把数据缓存到内存中,因为从数据库中获取数据的操作代价很高;如果数据库中的值不发生变化就没有问题。但是如果值有变化,我们需要一个机制来周期性的从数据库重新读取这些值:缓存的值就不可用(过期)了,而且我们也不希望用户看到陈旧的数据。

## 链接

Expand Down
10 changes: 6 additions & 4 deletions eBook/14.6.md
Original file line number Diff line number Diff line change
@@ -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
Expand All @@ -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` 的协程内部的:不能被另外一个协程恢复。


## 链接
Expand Down

0 comments on commit 5942213

Please sign in to comment.