GOMAXPROCS 用默认的，就是CPU的硬件线程数目，
对于大部分IO密集的应用是不合适的。
至少应该配置到硬件线程数目的5倍以上, 最大256。
具体参见。
我们来复习下Go的线程模型，M/P/G 三种对象，分别代表 操作系统线程、协程执行令牌、协程；
在任何情况下，Go运行时并行执行（注意，不是并发）的goroutines数量是小于等于P的数量的。
如果一个持有P的M，由于P当前执行的G调用了syscall而导致M被阻塞，那么：
注意
注意
注意
关键点：此时，GO的调度器是迟钝的，它很可能什么时都没做，直到M阻塞了想当长时间以后，才会发现有一个P/M被syscall阻塞了。然后，才会用空闲的M来强这个P。
补充说明：调度器迟钝不是M迟钝，M也就是操作系统线程，是非常的敏感的，只要阻塞就会被操作系统调度（除了极少数自旋的情况）。但是GO的调度器会等待一个时间间隔才会行动，这也是为了减少调度器干预的次数。也就是说，如果一个M调用了什么API导致了操作系统线程阻塞了，操作系统立刻会把这个线程M调度走，挂起等阻塞解除。这时候，Go调度器不会马上把这个M持有的P抢走。这就会导致一定的P被浪费了。
这就是为何，GOMAXPROCS 太小，也就是P的数量太少，会导致IO密集(或者syscall较多)的go程序运行缓慢的原因。
那么，GOMAXPROCS 很大，超过硬件线程的8倍，会不会有开销呢？
答案是，开销是有的，但是远小于Go运行时迟钝的调度M来抢夺P而导致CPU利用不足的开销。
P.S.
本文至少对Go 1.8版本是有效的。
有疑问加站长微信联系（非本文作者）
