内核态vs用户态
操作系统运行时使用的ram存储资源叫内核态
用户（上层软件）运行时使用的ram存储资源叫用户态
对于32位系统而言，其最大寻址空间为 2^32次方=4G内存。 linux系统内核态和用户态占比1:3，将最高的1G字节（从虚拟地址0xC0000000到0xFFFFFFFF），供内核使用，称为内核空间，而将较低的3G字节（从虚拟地址0x00000000到0xBFFFFFFF），供各个进程使用，称为用户空间。 windows系统内核态和用户态占比2:2
程序大多数时间是运行在用户态，当程序需要操作系统完成协助时会从用户态切换到内核态。
需要协助的场景有：
- 系统调用：读取文件、网卡发起网络请求
- 异常：缺页、除以0等触发异常
- 中断处理：接收网卡数据等
鉴于系统用户态与内核态的存在，线程实现方式分为内核态线程和用户态线程：
- 内核态线程: 操作系统层面实现的线程
- 用户态线程：在操作系统上层应用实现的线程库。但无论如何，用户态线程如果想执行(操作系统硬件资源)，都需要映射或者绑定到内核态线程
协程调度器模型演进
如何实现一个协程调度器？以下是协程调度器的模型演进
- 1:1模型。无需用户实现协程调度器，用户态的协程和内核线程一对一绑定，调度交由内核完成
- GM模型（普通m:n模型）。将内核线程进行池化，用户态协程加入一个全局队列，内核线程从全局队列中取出用户态协程并绑定（取出动作需要加全局锁）
- PM模型。GM模型全局队列加全局锁的操作过重，那么分而治之。我们引入一个结构作为中间介质，这个结构就是Proc。每个内核线程和一个Proc是一一对应关系，而Proc维护了一个私有的用户态协程队列。这样一来，每个内核线程都有私有的用户态协程队列。但问题又来了，私有的协程队列设置多大合适？太小的话，队列被占满了怎么办？太大的话，又会浪费。所以队列需要动态增减？
- GPM模型。在PM模型的基础上，设置一个全局队列。每次构建G先尝试放入P队列，如果P队列容量不足，则放入全局队列。队列是一个固定大小的数组，而全局队列是一个链表，可以无限扩容
GPM模型下G的调度
GPM模型下，调度器如何进行G的调度？如果内核态线程M阻塞（如socket请求）会阻塞相应P的所有G执行么？
M一旦进入系统调用后，会脱离go runtime的控制(此时控制权在操作系统内核)。万一系统调用阻塞，此时又无法进行抢占，整个M也就罢工了，M关联的PG就无法被执行。所以为了维持整个调度体系的高效运转，必然要在进入系统调用之前要做点什么以防患未然：
-
非阻塞的系统调用， G 会和MP分离（以进行network call为例，G会从M上移走并挂到netpoller）
G1 makes a network syscall
G1 is moved to NetPoller
G1 is back to LRQ of P -
阻塞的系统调用， MG 会和P分离（P另寻M），当M从系统调用返回时，不会继续执行，而是将G放到run queue
G1 is going to make a blocking syscall
可以看到，一次阻塞的系统调用，必然导致一个M被独占，这依然是耗费系统资源的事情
因此，Go 适合 IO 密集型的场景并不准确。更准确的是 Go 适合的是非阻塞式的IO 密集型的场景（如网络 IO 密集型场景，而非磁盘 IO 密集型）。甚至可以说，Go 对于磁盘 IO 密集型并不友好。
根本原因：网络 socket 句柄和文件句柄的不同。网络 IO 能够用异步非阻塞的事件驱动的方式来管理，磁盘 IO 则不行，只能是同步阻塞的方式。socket 句柄可读可写事件都有意义，socket buffer 里有数据，说明对端网络发数据过来了，即满足可读事件。有 buffer 可以写，那么说明还能发送数据，满足可写事件。socket 句柄可以设置为 noblocking （非阻塞的方式），这样当网络 IO 还未就绪的时候（比如read 一下没有数据）就可以在 Go 代码里把调度权切走，去执行其他协程，这样就实现了网络 IO 的并发。
文件句柄可读可写事件则没有意义，因为文件句柄理论上是永远都是可读可写的，文件 IO 的 read/write 都是同步的 IO（比如read 一下，没数据直接就卡住了），所以磁盘 IO 的完成只能同步等待。然而磁盘 IO 的等待则会带来 Go 最不能容忍的事情：卡线程。
Go 的代码执行者是系统线程，也就是 G-M-P 模型的 M ，M 不断的从队列 P 中取 G（协程任务）出来执行。当 G 出现等待事件的时候（比如网络 IO），那么立马切走，取下一个执行。这样让 M 一直不停的满载，就能保证 Go 协程任务的高吞吐。那么问题来了，如果某个 G 卡线程了，就相当于这个 M 被废了，吞吐能力就下降。如果 M 全卡住了那相当于整个程序卡死了。然而对于类似系统调用这种卡线程却是无法人为控制的。Go runtime 为了解决这个问题，就只能创建更多的线程来保证一直有可运行的 M 。所以，你经常会发现，当系统调用很慢的时候，M 的数量会变多，甚至会暴涨
参考：
https://qiankunli.github.io/2020/11/21/goroutine_system_call.html
