共计 2776 个字符，预计需要花费 7 分钟才能阅读完成。
从过程谈起
过程与线程的区别是什么？这是一个老成长谈的一道面试题。处于不同层面对该问题的了解也大不相同。对于用户层面来说，过程就是一块运行起来的程序，线程就是程序里的一些并发的性能。对于操作系统层面来说，规范答复是“过程是资源分配的最小单位，线程是 cpu 调度的最小单位”。接下来先从操作系统层面介绍一下过程与线程。
过程
在程序启动时，操作系统会给该程序调配一块内存空间，对于程序但看到的是一整块间断的内存空间，称为虚拟内存空间，落实到操作系统内核则是一块一块的内存碎片的货色。为的是节俭内核空间，不便对内存治理。
就这片内存空间，又划分为用户空间与内核空间，用户空间只用于用户程序的执行，若要执行各种 IO 操作，就会通过零碎调用等进入内核空间进行操作。每个过程都有本人的 PID，能够通过 ps 命令查看某个过程的 pid，进入 /proc/ 能够查看该过程的详细信息，如 cgroup，过程资源大小等信息。
线程
线程是过程的一个执行单元，一个过程能够蕴含多个线程，只有领有了线程的过程才会被 CPU 执行，所以一个过程起码领有一个主线程。
因为多个线程能够共享同一个过程的内存空间，线程的创立不须要额定的虚拟内存空间，线程之间的切换也就少了如过程切换的切换页表，切换虚拟地址空间此类的微小开销。至于过程切换为什么较大，简略了解是因为过程切换要保留的现场太多如寄存器，栈，代码段，执行地位等，而线程切换只须要上下文切换，保留线程执行的上下文即可。线程的的切换只须要保留线程的执行现场 (程序计数器等状态) 保留在该线程的栈里，CPU 把栈指针，指令寄存器的值指向下一个线程。相比之下线程更加轻量级。
能够说过程面向的次要内容是内存调配治理，而线程次要面向的 CPU 调度。
协程
尽管线程比过程要轻量级，然而每个线程仍然占有 1M 左右的空间，在高并发场景下十分吃机器内存，比方构建一个 http 服务器，如果一个每来一次申请调配一个线程，申请数暴增容易 OOM，而且线程切换的开销也是不可漠视的。同时，线程的创立与销毁同样是比拟大的零碎开销，因为是由内核来做的，解决办法也有，能够通过线程池或协程来解决。
协程是用户态的线程，比线程更加的轻量级，操作系统对其没有感知，之所以没有感知是因为协程处于线程的用户栈能感知的范畴，是由用户创立的而非操作系统。
如一个过程可领有以有多个线程一样，一个线程也能够领有多个协程。协程之于线程如同线程之于 cpu，领有本人的协程队列，每个协程领有本人的栈空间，在协程切换时候只须要保留协程的上下文，开销要比内核态的线程切换要小很多。
GMP 模型
含意
Goroutine 的并发编程模型基于 GMP 模型，简要解释一下 GMP 的含意：
G: 示意 goroutine，每个 goroutine 都有本人的栈空间，定时器，初始化的栈空间在 2k 左右，空间会随着需要增长。
M: 抽象化代表内核线程，记录内核线程栈信息，当 goroutine 调度到线程时，应用该 goroutine 本人的栈信息。
P: 代表调度器，负责调度 goroutine，保护一个本地 goroutine 队列，M 从 P 上取得 goroutine 并执行，同时还负责局部内存的治理。
模型
从大体看一下 GMP 模型。
M 代表一个工作线程，在 M 上有一个 P 和 G，P 是绑定到 M 上的，G 是通过 P 的调度获取的，在某一时刻，一个 M 上只有一个 G（g0 除外）。在 P 上领有一个 G 队列，外面是曾经就绪的 G，是能够被调度到线程栈上执行的协程，称为运行队列。
接下来看一下程序中 GMP 的散布。
每个过程都有一个全局的 G 队列，也领有 P 的本地执行队列，同时也有不在运行队列中的 G。如正处于 channel 的阻塞状态的 G，还有脱离 P 绑定在 M 的(零碎调用)G，还有执行完结后进入 P 的 gFree 列表中的 G 等等，接下来列举一下常见的几种状态。
状态汇总
G 状态
G 的次要几种状态：
本文基于 Go1.13，具体代码见（<GOROOT>/src/runtime/runtime2.go）
_Gidle：刚刚被调配并且还没有被初始化，值为 0，为创立 goroutine 后的默认值
_Grunnable：没有执行代码，没有栈的所有权，存储在运行队列中，可能在某个 P 的本地队列或全局队列中(如上图)。
_Grunning：正在执行代码的 goroutine，领有栈的所有权(如上图)。
_Gsyscall：正在执行零碎调用，领有栈的所有权，与 P 脱离，然而与某个 M 绑定，会在调用完结后被调配到运行队列(如上图)。
_Gwaiting：被阻塞的 goroutine，阻塞在某个 channel 的发送或者接管队列(如上图)。
_Gdead：以后 goroutine 未被应用，没有执行代码，可能有调配的栈，散布在闲暇列表 gFree，可能是一个刚刚初始化的 goroutine，也可能是执行了 goexit 退出的 goroutine(如上图)。
_Gcopystac：栈正在被拷贝，没有执行代码，不在运行队列上，执行权在
_Gscan：GC 正在扫描栈空间，没有执行代码，能够与其余状态同时存在
P 的状态
_Pidle：处理器没有运行用户代码或者调度器，被闲暇队列或者扭转其状态的构造持有，运行队列为空
_Prunning：被线程 M 持有，并且正在执行用户代码或者调度器(如上图)
_Psyscall：没有执行用户代码，以后线程陷入零碎调用(如上图)
_Pgcstop：被线程 M 持有，以后处理器因为垃圾回收被进行
_Pdead：以后处理器曾经不被应用
M 的状态
自旋线程：处于运行状态然而没有可执行 goroutine 的线程(如下图)，数量最多为 GOMAXPROC，若是数量大于 GOMAXPROC 就会进入休眠。
非自旋线程：处于运行状态有可执行 goroutine 的线程。
调度场景
Channel 阻塞：当 goroutine 读写 channel 产生阻塞时候，会调用 gopark 函数，该 G 会脱离以后的 M 与 P，调度器会执行 schedule 函数调度新的 G 到以后 M。可参考上一篇文章 channel 探秘。
零碎调用：当某个 G 因为零碎调用陷入内核态时，该 P 就会脱离以后的 M，此时 P 会更新本人的状态为 Psyscall，M 与 G 相互绑定，进行零碎调用。完结当前若该 P 状态还是 Psyscall，则间接关联该 M 和 G，否则应用闲置的处理器解决该 G。
系统监控：当某个 G 在 P 上运行的工夫超过 10ms 时候，或者 P 处于 Psyscall 状态过长等状况就会调用 retake 函数，触发新的调度。
被动让出：因为是合作式调度，该 G 会被动让出以后的 P，更新状态为 Grunnable，该 P 会调度队列中的 G 运行。
总结
Go 语言中通过 GMP 模型实现了对 CPU 和内存的正当利用，使得用户在不必放心内存的状况下体验到线程的益处。虽说协程的空间很小，然而也须要关注一下协程的生命周期，避免过多的协程滞留造成 OOM。最近遇到了线上的 OOM 问题，期待下期一起剖析。
