这是我参与8月更文挑战的第3天，活动详情查看：8月更文挑战
常见的线程模型
- 单线程服务器编程模型：Redis、Node.、JavaScript
- 多线程服务器编程模型：并发多个线程，每条线程并行执行不同的任务
- 主从多线程模式：两个线程池
专有名称说明
内核线程（Kernel-Level Thread ，KLT） 轻量级进程（Light Weight Process,LWP）：轻量级进程就是我们通常意义上所讲的线程，由于每个轻量级进程都由一个内核线程支持，因此只有先支持内核线程，才能有轻量级进程
三种线程模型
- 一对一模型
- 多对一模型
- 多对多模型
一对一模型
用户线程与系统线程一一对应，用户线程执行如lo操作的系统调用时，来回切换操作开销相对比较大
多对一模型
多个用户线程对应一个内核线程，当内核线程对应的一个用户线程被阻塞挂起时候，其他用户线程也阻塞不能执行了。
多对多模型
多对多模型是可以充分利用多核CPU提升运行效能的
Go线程模型属于多对多线程模型
go线程模型包含三个概念：内核线程(M)，goroutine(G),G的上下文环境（P）；
GMP模型
GMP模型是goalng特有的。
- G是goroutine，基于协程建立的用户态线程
- M是machine，它直接关联一个os内核线程，用于执行G。
- P是processor，P里面一般会存当前goroutine运行的上下文环境（函数指针，堆栈地址及地址边界），P会对自己管理的goroutine队列做一些调度
P与M一般是一一对应的。P（上下文）管理着一组G（goroutine）挂载在M（内核线程）上运行，图中左边蓝色为正在执行状态的goroutine，右边为待执行状态的goroutiine队列。P的数量由环境变量GOMAXPROCS的值或程序运行runtime.GOMAXPROCS()进行设置。
GMP调度
当一个os线程在执行M1一个G1发生阻塞时，调度器让M1抛弃P，等待G1返回，然后另起一个M2接收P来执行剩下的goroutine队列（G2、G3...），这是golang调度器厉害的地方，可以保证有足够的线程来运行剩下所有的goroutine。
当G1结束后，M1会重新拿回P来完成，如果拿不到就丢到全局runqueue中，然后自己放到线程池或转入休眠状态。空闲的上下文P会周期性的检查全局runqueue上的goroutine，并且执行它。
另一种情况就是当有些P1太闲而其他P2很忙碌的时候，会从其他上下文P2拿一些G来执行。
详细可以翻看下方第一个参考链接，写得真好。
特点
- 用户空间 避免了内核态和用户态的切换导致的成本
- 可以由语言和框架层进行调度
- 更小的栈空间允许创建大量的实例
总结
最后用大佬的总结来做最后的收尾———— Go语言运行时，通过核心元素G，M，P 和 自己的调度器，实现了自己的并发线程模型。调度器通过对G，M，P的调度实现了两级线程模型中操作系统内核之外的调度任务。整个调度过程中会在多种时机去触发最核心的步骤 “一整轮调度”，而一整轮调度中最关键的部分在“全力查找可运行G”，它保证了M的高效运行（换句话说就是充分使用了计算机的物理资源），一整轮调度中还会涉及到M的启用停止。最后别忘了，还有一个与Go程序生命周期相同的系统监测任务来进行一些辅助性的工作。
