先前在社区里分享了关于 golang 行情推送[1]的分享,有人针对 ppt 的内容问了我两个问题,一个是在 docker 下 golang 的 gomaxprocs 初始化混乱问题,另一个是 golang runtime.gomaxprocs 配置多少为合适?
![](https://i-blog.csdnimg.cn/blog_migrate/34138a7627d7e46c05bef3604f45ef44.png)
golang runtime
Golang 的 runtime 调度是依赖 pmg 的角色抽象,p 为逻辑处理器,m 为执行体(线程),g 为协程。p 的 runq 队列中放着可执行的 goroutine 结构。golang 默认 p 的数量为 cpu core 数目,比如物理核心为 8 cpu core,那么 go processor 的数量就为 8。另外,同一时间一个 p 只能绑定一个 m 线程,pm 绑定后自然就找 g 和运行 g。
那么增加 processor 的数量,是否可以用来加大 runtime 对于协程的调度吞吐?
大多 golang 的项目偏重网络 io,network io 在 netpoll 设计下都是非阻塞的,所涉及到的 syscall 不会阻塞。如果是 cpu 密集的业务,增加多个 processor 也没用,毕竟 cpu 计算资源就这些,居然还想着来回的切换????? 所以,多数场景下单纯增加 processor 是没什么用的。