协程和线程
通过以上（协程的CPU切换），可以理解上下文切换过程>线程>协程，也就是进化路线。
协程的问题
也就是系统不知道，所以操作系统不会为你切换。
那么谁来为你做转换？问题的关键是需要执行的协程获得更多的CPU时间。
协程的实现
目前的协程框架一般都是以1:N的方式设计的。
所谓1:N数据报告，就是以一个线程为容器，在其中放置多个协程。
那么谁来及时切换这些协程呢？答案是有协程主动放弃CPU，
即每个协程池都有一个调度器，是被动调度的。
表示他不会主动安排。
而当协程发现自己无法执行时（比如异步等待网络数据回来，但还没有数据到达），
此时可以通过这个协程通知调度器，
此时执行到调度器的代码unity 协程 线程，调度器根据预先设计好的调度算法找到当前最需要CPU的协程。
切换这个协程的CPU上下文，将CPU的运行权交给这个协程，直到协程无法执行，需要等待，
或者调用主动放弃CPU等的API，触发下一次调度。对了，和leader模式差不多，那么这个实现有什么问题吗？
其实是有问题的。假设这个线程中有一个协程是CPU密集型的，没有IO操作，即不会主动触发调度器的调度过程。
那么就会出现其他协程无法执行的情况，所以这种情况程序员需要避免。
如果业务开发人员不理解这个原则unity 协程 线程，就会出现这个问题。
协程的适用场景
协程适用于 IO 密集型程序。
由于IO操作远小于CPU操作，
CPU 经常需要等待 IO 操作。同步IO下，系统需要切换线程，以便操作系统在IO过程中执行其他事情。
虽然代码符合人类的思维习惯，但由于大量的线程切换带来了很多性能浪费，尤其是对于IO密集型程序。
于是人们发明了异步 IO。它是在数据到达时触发我的回调。减少线程切换带来的性能损失。
但这也是一个很大的缺点
#参考
为什么你认为协程是一种趋势？
