co

1. 协程

有史可考的起源，最早应该是高德纳1960年写cobol编译器时提出的。当时的cobol程序被写在一个磁带上，而磁带不支持随机读写，只能顺序读，而当时的内存又不可能把整个磁带的内容都装进去。所以一次读取没编译完就要再从头读…高德纳为此设计了一个只用读一次（one-pass）就能编译完成的编译器，在此时设计提出了协程的概念。

但协程终究没有火起来。主要原因在于和当时（事实上，也包括今天）主流的自顶而下的设计理念不合。自顶而下的设计理念要求你先对问题进行抽象，进行层次分解，建模，然后再进行具体实现，强调高内聚低耦合，强调模块完成自己所在抽象层次的任务并不多干预其他事情。这使得互不相干的多线程模型变得很自然，而协程则强调了模块间的耦合，模块间必须相互熟悉，才知道谁在什么时候该让出时间片，谁在什么时候该抢占时间片。高德纳的one-pass编译器事实上就是词法分析语法分析完全混在一块儿，低内聚高耦合的典范（事实上词法分析语法分析分离本身就是自顶而下设计的优秀样例）

今天协程之所以又火了起来的原因在于，人们把协程调度的逻辑缩减为单一的“等io，让出，io完毕，重启”，在此基础上人们发现协程的方式能解决多线程环境下很多代码逻辑“混乱”（本质上就是更贴合线程模型的思维方式，但对很多人而言这就是混乱难懂的毛线球）的问题，使得线性书写多线程代码成为了可能。

与自顶而下相对应的，是自底而上的抽象方式。这实际上是协程的思想方式。自底而上实际上说白了，就是要做什么，别先抽象，不管三七二十一，先把业务实现了，然后再一步步考虑如何将重复的部分，类似的部分，封装起来从实现转向抽象的方式。这种思路下使用协程就会很自然，因为你从一开始就在考虑具体实现，考虑耦合。

两种抽象方式本身没有高下之分，但自顶而下的方式可以让除了架构师以外的人都不用考虑任何抽象层次的问题，同时只要一开始抽象好后续基本不会有太多更新，因此更适合一个大佬带一群菜鸡的公司，而自底而上则要求每个工程师都有优秀的抽象能力，同时因为业务的扩展变更，抽象层次会经常变动，这要求整个开发团队要有能力抽象并时刻理解接受其他同事提出的抽象，这对整个开发团队的要求是比较高的，因此协程不火也很好理解了。

今天使用协程基本上只要遵循面向io调度即可，但如果有时间，有精力，可以从协程的角度多考虑考虑代码的设计实现。你会发现一个新天地。