目录
- 停止信号
- 任务定时
- 解耦生产方和消费方
- 控制并发数
停止DAJANptS信号
channel 用于停止信号的场景还是挺多的,经常是关闭某个 channel 或者向 channel 发送一个元素,使得接收 channel 的那一方获知道此信息,进而做一些其他的操作。
任务定时
与 timer 结合,一般有两种玩法:实现超时控制,实现定期执行某个任务。
有时候,需要执行某项操作,但又不想它耗费太长时间,上一个定时器就可以搞定:
select { case <-time.After(100 * time.Millisecond): case <-s.stopc: return false }
等待 100 ms 后,如果 s.stopc 还没有读出数据或者被关闭,就直接结束。这是来自 etcd 源码里的一个例子,这样的写法随处可见。
定时执行某个任务,也比较简单:
func worker() { ticker := time.Tick(1 * time.Second) for { select { case <- ticker: // 执行定时任务 fmt.Println("执行 1s 定时任务") } } }
每隔 1 秒种,执行一次定时任务。
解耦生产方和消费方
服务启动时,启动 n 个 worker,作为工作协程池,这些协程工作在一个 for {}
无限循环里,从某个 channel 消费工作任务并执行:
func main() { taskCh := make(chan int, 100) go worker(taskjavascriptCh) // 塞任务 for i := 0; i < 10; i++ { taskCh <- i } // 等待 1 小时 select { case <-time.After(time.Hour): } } func worker(taskCh <-chan int) { http://www.devze.comconst N = 5 // 启动 5 个工作协程 for i := 0; i < N; i++ { go func(id int) { for { task := <- taskCh fmt.Printf("finish task: %d by worker %d\n", task, id) time.Sleep(time.Second) } }(i) } }编程客开发者_C开发栈
5 个工作协程在不断地从工作队列里取任务,生产方只管往 channel 发送任务即可,解耦生产方和消费方。
finish task: 1 by workjser 4
finish task: 2 by worker 2finish task: 4 by worker 3finish task: 3 by worker 1finish task: 0 by worker 0finish task: 6 by worker 0finish task: 8 by worker 3finish task: 9 by worker 1finish task: 7 by worker 4finish task: 5 by worker 2
控制并发数
有时需要定时执行几百个任务,例如每天定时按城市来执行一些离线计算的任务。但是并发数又不能太高,因为任务执行过程依赖第三方的一些资源,对请求的速率有限制。这时就可以通过 channel 来控制并发数。
下面的例子来自《Go 语言高级编程》:
var limit = make(chan int, 3) func main() { // ………… for _, w := range work { go func() { limit <- 1 w() <-limit }() } // ………… }
构建一个缓冲型的 channel,容量为 3。接着遍历任务列表,每个任务启动一个 goroutine 去完成。真正执行任务,访问第三方的动作在 w() 中完成,在执行 w() 之前,先要从 limit 中拿“许可证”,拿到许可证之后,才能执行 w(),并且在执行完任务,要将“许可证”归还。这样就可以控制同时运行的 goroutine 数。
这里,limit <- 1
放在 func 内部而不是外部,原因是:
如果在外层,就是控制系统 goroutine 的数量,可能会阻塞 for 循环,影响业务逻辑。
limit 其实和逻辑无关,只是性能调优,放在内层和外层的语义不太一样。
还有一点要注意的是,如果 w() 发生 panic,那“许可证”可能就还不回去了,因此需要使用 defer 来保证。
到此这篇关于golang channel使用介绍的文章就介绍到这了,更多相关Go channel内容请搜索我们以前的文章或继续浏览下面的相关文章希望大家以后多多支持我们!
精彩评论