理解golang调度

·# 线程模型
在细说 Go 的调度模型之前，先来说说一般意义的线程模型。线程模型一般分三种，由用户级线程和 OS 线程的不同对应关系决定的。

N:1，即全部用户线程都映射到一个OS线程上，上下文切换成本最低，但无法利用多核资源；

1:1 , 一个用户线程对应到一个 OS线程上， 能利用到多核资源，但是上下文切换成本较高，这也是 Java Hotspot VM 的默认实现；

M:N，权衡上面两者方案，既能利用多核资源也能尽可能减少上下文切换成本，但是调度算法的实现成本偏高。

为什么 Go Scheduler 需要实现 M:N 的方案？

线程创建开销大。对于 OS 线程而言，其很多特性均是操作系统给予的，但对于 Go 程序而言，其中很多特性可能非必要的。这样一来，如果是 1:1 的方案，那么每次 go func(){…} 都需要创建一个 OS 线程，而在创建线程过程中，OS 线程里某些 Go 用不上的特性会转化为不必要的性能开销，不经济。

减少 Go 垃圾回收的复杂度。依据1:1方案，Go 产生所用用户级线程均交由 OS 直接调度。 Go 的垃圾回收器要求在运行时需要停止所有线程，才能使得内存达到稳定一致的状态，而 OS 不可能清楚这些，垃圾回收器也不能控制 OS 去阻塞线程。

Go Scheduler 的 M:N 方案出现，就是为了解决上面的问题。

Go Scheduler