在runtime包中,有一个方法是GOMAXPROCS。在我看来,这个函数名有点误导人:人们经常认为这个函数与主机上逻辑处理器的数量有关, 但是这个函数真正控制着将要托管所谓的“工作队列”的操作系统线程的数量。在第6章我们会讨论关于它的更多详细信息。
在Go 1.5之前,GOMAXPROCS总是设置为1,通常你会在大多数Go程序中找到这个片段:
```
runtime.GOMAXPROCS(runtime.NumCPU())
```
几乎所有的开发人员都希望利用其进程能够使用计算机上的所有内核。因此,在随后的Go版本中,它被自动设置为主机上的逻辑CPU数量。
那么,如果你想调整这个值呢? 大多数时候你尽量别这么想。Go的调度算法在大多数情况下足够好,即增加或减少工作队列和线程的数量可能会造成更多的伤害,但仍然有些情况下可能会更改此值。
例如,我曾经参与过一个项目,该项目有一个受竞争条件困扰的测试套件。事实上,该团队有一些测试包有时会失败。我们运行测试的基础架构只有四个逻辑CPU,因此在任何一个时间点,我们都有四个goroutines同时执行。 通过增加GOMAXPROCS超过我们所拥有的逻辑CPU数量,我们能够更频繁地触发竞态条件,从而更快地纠正它们。
有人可能会通过实验发现,他们的程序在一定数量的工作队列和线程下运行得更好,但我敦促谨慎行事。如果你通过调整CPU来压缩性能,请务必在每次提交后,使用不同硬件以及使用不同版本的Go时执行此操作。调整这个值是以更高的抽象和长期性能稳定性的降低为代价的。
* * * * *
学识浅薄,错误在所难免。我是长风,欢迎来Golang中国的群(211938256)就本书提出修改意见。
- 前序
- 谁适合读这本书
- 章节导读
- 在线资源
- 第一章 并发编程介绍
- 摩尔定律,可伸缩网络和我们所处的困境
- 为什么并发编程如此困难
- 数据竞争
- 原子性
- 内存访问同步
- 死锁,活锁和锁的饥饿问题
- 死锁
- 活锁
- 饥饿
- 并发安全性
- 优雅的面对复杂性
- 第二章 代码建模:序列化交互处理
- 并发与并行
- 什么是CSP
- CSP在Go中的衍生物
- Go的并发哲学
- 第三章 Go的并发构建模块
- Goroutines
- sync包
- WaitGroup
- Mutex和RWMutex
- Cond
- Once
- Pool
- Channels
- select语句
- GOMAXPROCS
- 结论
- 第四章 Go的并发编程范式
- 访问范围约束
- fo-select循环
- 防止Goroutine泄漏
- or-channel
- 错误处理
- 管道
- 构建管道的最佳实践
- 便利的生成器
- 扇入扇出
- or-done-channel
- tee-channel
- bridge-channel
- 队列
- context包
- 小结
- 第五章 可伸缩并发设计
- 错误传递
- 超时和取消
- 心跳
- 请求并发复制处理
- 速率限制
- Goroutines异常行为修复
- 本章小结
- 第六章 Goroutines和Go运行时
- 任务调度