协程本质：

go协程本质上还是用线程来运行代码，只是在多线程上增加了调度器，通过调度器让每一个线程可以执行多个协程。

实现原理：

go协程使用GPM调度模型实现，具体内容如下：

G goroutine协程

P process 调度器，为每一个m分配g,

M machine 对应操作系统的线程，g的真正执行者。

P的数量默认是CPU核数，也可以通过GOMAXPROCS来指定数量，每个P都会维护一个runq队列，用于保存G，P会从队列头获取G交给M执行，执行完后放入到队列尾（如果需要继续执行），通过GPM模型实现了多个协程并行（不是并发）执行，可以最大限度地利用到CPU。

协程优点：

协程相对于多线程有哪些优点呢？

1.上下文切换更轻量

触发go上下文切换有两种场景，1是协作式抢占引起的协程切换，2是锁阻塞\IO阻塞\channel阻塞，两种场景保存的上下文数据结构都是g.sched，它的数据结构如下：

与栈相关的SP和BP寄存器

PC

用于保存函数闭包的上下文，也就是DX寄存器

相比多线程协程切换只需要修改少数寄存器内容，所以更轻量，但一个线程使用到的寄存器总大小非常有限，就算全部内容更新也不会消耗多少资源, 但为什么大部分人都会说协程减少了上下文切换带来的开销? 这里就要看上下文的定义了,如果不仅包括协程执行时所需要的数据，还包括内核态与用户态的切换则这句是对的。

2.节省了内核态与用户态的切换

用户态切换与内核态之间切换一次可能花费1000cycles，线程切换由操作系统内核完成，所以需要从用户态切换到内核态然后再切回用户态，而协程则不需要进行状态的切换。

下面这段话测试结果描述了上下文切换带来的损耗：

Since all the context switching is happening at the application level, we don’t lose the same ~12k instructions (on average) per context switch that we were losing when using Threads. In Go, those same context switches are costing you ~200 nanoseconds or ~2.4k instructions.

摘自：https://www.ardanlabs.com/blog/2018/08/scheduling-in-go-part2.html

3.提高了IO类任务的效率?

CPU执行线程是抢占式的,GO协程也是协作抢占式,工作原理都一样，都是为每次执行分配固定的时间片，如果只从这一点看，它们执行io类任务效率不会有多大差别，但实际上产生效果还是有区别的，这个后面会提到。

协程引发的思考

1.操作系统需要支持协程吗?

协程能减少线程切换带来的开销，那操作系统有必要开发一种支持协程的线程吗，或者用其它方式支持协程的API? 如果这样做确实可以降低用户或各语言的开发难度，那这种方案可行吗?或者有必要吗?

个人觉得虽然可行但没必要,这样会提高系统的复杂性,尤其是协程队列的维护,这样的功能更贴近业务应该让各开发语言来实现,而不是底层的操作来实现,那这里又引发了另外一个思考:java需要支持协程吗?

2. java需要支持协程吗?

暂时不会支持，以后可能会有,理由是JAVA的线程池同样也有协程带来的开销减少好处,虽然写协程代码更简洁方便，但JDK1.8开始函数式编程的完善让我们创建线程更快捷了。不过如果JAVA支持协程确实会带来一些执行效果上的改变，例如前面提到的IO类任务，在线程池方案中，只有当前活跃的线程会拿到CPU时间片，如果这些线程是IO类会导致正在排队的其它任务长时间不能执行，这样大大降低了CPU利用率，虽然提高线程池活跃数能解决一部分问题，但还是做不到像协程那样每个任务都能公平分配到时间片，所以JAVA实现协程还是有一点点价值的，同样运行在java虚拟机上的Kotlin就支持协程。