什么是协程？

        今天早上开会，对我而言听到了一个新的名字，当然，别人可能早就知道，是我自己孤陋寡闻而已吧。这个名词就是协程！

开完会之后我就去狂搜资料，什么是协程？现将收集到资料归纳如下：

早期的Unix时代崇尚同步编程，当时设计的时候也没多想，管他什么性能不性能，先做出来再说。所以最开始人是开多进程（process）再用管子（pipe）连接起来的；多直观啊，我把东西推进管子里，你走你那头接一下。

不知道哪天人注意到开个千儿八百个进程机器就卡死了，这怎么行，所以我们只搞一个进程，里面有一坨打开的网络连接和文件，用select这个系统调用对io事件同时进行监听，谁先来我就处理谁。然而发现性能也不好，没什么卵用。

人们在这两条路上都想办法提升性能。进程这边人们又搞了多线程，结果还是不够。多线程还是吃内核资源，抗不住。

Linux忍不住了，搞出个epoll（不过我不知道和bsd的kqueue哪个在前）系统调用，就是红黑树改良版的select。这下子人开心了，真他妈快啊，开千儿八百个连接小意思，同时进行事件监听，判断连接的的id和事件的类型，再打（dispatch）到不同的回调函数里。

协程是啥
首先我们得知道协程是啥？协程其实可以认为是比线程更小的执行单元。为啥说他是一个执行单元，因为他自带CPU上下文。这样只要在合适的时机，我们可以把一个协程 切换到 另一个协程。只要这个过程中保存或恢复 CPU上下文那么程序还是可以运行的。


协程和线程差异
那么这个过程看起来比线程差不多哇。其实不然 线程切换从系统层面远不止 保存和恢复 CPU上下文这么简单。操作系统为了程序运行的高效性每个线程都有自己缓存Cache等等数据，操作系统还会帮你做这些数据的恢复操作。所以线程的切换非常耗性能。但是协程的切换只是单纯的操作CPU的上下文，所以一秒钟切换个上百万次系统都抗的住。


协程的问题
但是协程有一个问题，就是系统并不感知，所以操作系统不会帮你做切换。那么谁来帮你做切换？让需要执行的协程更多的获得CPU时间才是问题的关键。

笔者知道协程的实现相关的
目前的协程框架一般都是设计成 1:N 模式。所谓 1:N 就是一个线程作为一个容器里面放置多个协程。那么谁来适时的切换这些协程？答案是有协程自己主动让出CPU，也就是每个协程池里面有一个调度器，这个调度器是被动调度的。意思就是他不会主动调度。而且当一个协程发现自己执行不下去了(比如异步等待网络的数据回来，但是当前还没有数据到)，这个时候就可以由这个协程通知调度器，这个时候执行到调度器的代码，调度器根据事先设计好的调度算法找到当前最需要CPU的协程。切换这个协程的CPU上下文把CPU的运行权交个这个协程，直到这个协程出现执行不下去需要等等的情况，或者它调用主动让出CPU的API之类，触发下一次调度。对的没错就是类似于 领导人模式

那么这个实现有没有问题？
其实是有问题的，假设这个线程中有一个协程是CPU密集型的他没有IO操作，也就是自己不会主动触发调度器调度的过程，那么就会出现其他协程得不到执行的情况，所以这种情况下需要程序员自己避免。这是一个问题，假设业务开发的人员并不懂这个原理的话就可能会出现问题。

最后讲讲协程的好处
在IO密集型的程序中由于IO操作远远小于CPU的操作，所以往往需要CPU去等IO操作。同步IO下系统需要切换线程，让操作系统可以再IO过程中执行其他的东西。这样虽然代码是符合人类的思维习惯但是由于大量的线程切换带来了大量的性能的浪费，尤其是IO密集型的程序。

所以人们发明了异步IO。就是当数据到达的时候触发我的回调。来减少线程切换带来性能损失。但是这样的坏处也是很大的，主要的坏处就是操作被 “分片” 了，代码写的不是 “一气呵成” 这种。 而是每次来段数据就要判断 数据够不够处理哇，够处理就处理吧，不够处理就在等等吧。这样代码的可读性很低，其实也不符合人类的习惯。

但是协程可以很好解决这个问题。比如 把一个IO操作 写成一个协程。当触发IO操作的时候就自动让出CPU给其他协程。要知道协程的切换很轻的。协程通过这种对异步IO的封装 既保留了性能也保证了代码的 容易编写和可读性。在高IO密集型的程序下很好。但是高CPU密集型的程序下没啥好处。

作者：饭后温柔
链接：https://www.zhihu.com/question/20511233/answer/24459911
来源：知乎

        我觉得线程是很丑陋的东西。线程不过是反映了当前硬件技术的物理限制瓶颈。单个cpu的计算能力不足，所以要多核。内存的容量太小太昂贵，所以需要硬盘。无须敬畏，当你认识到线程不过是个妥协的产物，学习的难度就低多了。比如计算能力低引入了多核，多核引入了并发，并发引入了竞态，竞态引入了锁，一层又一层的引入了复杂性，我等程序员的饭碗才能保住。当然有些问题确实不是单纯的计算能力或存储能力极大提升就能解决的，不是我的工作范围，就不献丑了。

协程比线程更基础。协程不能像线程那样，简单看做一种硬件妥协机制。协程是可以作为语言的内建机制的，因为协程反映了程序逻辑的一种需求：可重入能力。这个能力很重要，因为大多数语言的一个最重要的组件--函数，其实就依赖这个能力的弱化版本。函数中的局部变量，被你初始化为特定的值，每次你调函数，换种说法:重入函数，语言都保证这些局部变量的值不会改变。相同的输入，得到相同的输出。当然你跟我扯全局变量就没意思了。

语言实现到函数这一步，可以满足绝大多数日常需求了。但工程师就是又懒又爱折腾啊。函数在很多语言特别是早期语言中，有个别名：过程（具体特性不一定相同，就不追究了，整体的行为还是差不离的）。我觉得过程这个词比函数更贴切。现在我们把“函数中局部变量的值”换种说法，叫做“过程中的局部状态”，这个说法更广泛了。每次重入过程，过程中的局部状态都被重置。要想得到不同的输出状态，唯有改变输入的状态。要想明确一个输出状态，对应的输入状态，唯有记录下输入状态。so simple，so native。问题是那帮懒惰的工程师甚至连输入状态都不想保存判断啊。他们希望有这么一种过程，每次进入，过程里的局部状态，都能保留上一次进入的状态。自然也就不需要干针对输入状态的保存或判断工作了。换言之，这个特殊过程把原来需要在过程之外的用来控制过程输出状态的那些输入状态的管理工作，都交给过程本身了。

这个特殊的过程，就叫做协程。它能保留上一次调用时的状态（即所有局部状态的一个特定组合），每次过程重入时，就相当于进入上一次调用的状态，换种说法：进入上一次离开时所处逻辑流的位置。普通过程（函数）可看成这个特殊过程的一个特例：只有一个状态，每次进入时局部状态重置。这种逻辑控制上的方便当然让这帮懒惰的工程师乐翻了天，少打了好多字，可以向老板叫嚣生产力提高了，其实又可以多lol几把了，对不对？用协程的好处是，你处在更高的逻辑层面去审视需求，整理代码。没有函数之前，你只有表达式，没有表达式之前，你只有mov。没有if-else之前，你只有jump。脱离低级的逻辑处理，就意味着能在更高的抽象层面看问题。就好像如果你在算傅里叶变换时，还要每次去思考四则混合运算规则，只能是自作死。协程之所以陌生，是因为这个能力很强大，因此通常跟实际业务联系很紧密吧。

因此，协程不过是一个逻辑控制需求。一些语言原生支持，不支持也可以用原有的材料构建出来。协程的实现，无非是你要维护一组局部状态，在重新进入协程前，保证这些状态不被改变，你能顺利定位到之前的位置。你平时所写的一些逻辑控制代码，经典如状态机或对象等，也许就已经是一种“协程”了。区别在于是否精巧，适用条件是否苛刻，使用是否方便，效率是否足够罢了。

面向对象中的对象，函数式语言中过程的chunk实现，都跟协程有些相似的结构。这些语言的表达足够丰富，有没有协程，倒不构成问题。真要说起来，我觉得协程的最大的好处是在写过程式（命令式）风格的代码时，很好的简化了逻辑的流程。