近期尝试在搬砖专用语言 Java 上实现异步，起因和过程就不再详述了，总而言之，心中一万头草泥马奔过。但这个过程也没有白白浪费，趁机回顾了一下各种异步编程的实现。
这篇文章会涉及到回调、Promise、反应式、async/await、用户态线程等异步编程的实现方案。如果你熟悉它们中的一两种，那应该也能很快理解其他几个。
为什么需要异步？
操作系统可以看作是个虚拟机（VM），进程生活在操作系统创造的虚拟世界里。进程不用知道到底有多少 core 多少内存，只要进程不要索取的太过分，操作系统就假装有无限多的资源可用。
基于这个思想，线程（Thread）的个数并不受硬件限制：你的程序可以只有一个线程、也可以有成百上千个。操作系统会默默做好调度，让诸多线程共享有限的 CPU 时间片。这个调度的过程对线程是完全透明的。
那么，操作系统是怎样做到在线程无感知的情况下调度呢？答案是上下文切换（Context Switch），简单来说，操作系统利用软中断机制，把程序从任意位置打断，然后保存当前所有寄存器——包括最重要的指令寄存器 PC 和栈顶指针 SP，还有一些线程控制信息（TCB），整个过程会产生数个微秒的 overhead。
然而作为一位合格的程序员，你一定也听说过，线程是昂贵的：
- 线程的上下文切换有不少的代价，占用宝贵的 CPU 时间；
- 每个线程都会占用一些（至少 1 页）内存。
这两个原因驱使我们尽可能避免创建太多的线程，而异步编程的目的就是消除 IO wait 阻塞——绝大多数时候，这是我们创建一堆线程、甚至引入线程池的罪魁祸首。
Continuation
回调函数知道的人很多，但了解 Continuation 的人不多。Continuation 有时被晦涩地翻译成“计算续体”，咱们还是直接用单词好了。
把一个计算过程在中间打断，剩下的部分用一个对象表示，这就是 Continuation。操作系统暂停一个线程时保存的那些现场数据，也可以看作一个 Continuation。有了它，我们就能在这个点接着刚刚的断点继续执行。
打断一个计算过程听起来很厉害吧！实际上它每时每刻都在发生——假设函数 f() 中间调用了 g()，那 g() 运行完成时，要返回到 f() 刚刚调用 g() 的地方接着执行。这个过程再自然不过了，以至于所有编程语言（汇编除外）都把它掩藏起来，让你在编程中感觉不到调用栈的存在。
操作系统用昂贵的软中断机制实现了栈的保存和恢复。那有没有别的方式实现 Continuation 呢？最朴素的想法就是，把所有用得到的信息包成一个函数对象，在调用 g() 的时候一起传进去，并约定：一旦 g() 完成，就拿着结果去调用这个 Continuation。
这种编程模式被称为 Continuation-passing style（CPS）：
- 把调用者 f() 还未执行的部分包成一个函数对象 cont，一同传给被调用者 g()；
- 正常运行 g() 函数体；
- g() 完成后，连同它的结果一起回调 cont，从而继续执行 f() 里剩余的代码。
再拿 Wikipedia 上的定义巩固一下：
A function written in continuation-passing style takes an extra argument: an explicit "continuation", i.e. a function of one argument. When the CPS function has computed its result value, it "returns" it by calling the continuation function with this value as the argument.
CPS 风格的函数带一个额外的参数：一个显式的 Continuation，具体来说就是个仅有一个参数的函数。当 CPS 函数计算完返回值时，它“返回”的方式就是拿着返回值调用那个 Continuation。
你应该已经发现了，这也就是回调函数，我只是换了个名字而已。
异步的朴素实现：Callback
光有回调函数其实并没有卵用。对于纯粹的计算工作，Call Stack 就很好，为何要费时费力用回调来做 Continuation 呢？你说的对，但仅限于没有 IO 的情况。我们知道 IO 通常要比 CPU 慢上好几个数量级，在 BIO 中，线程发起 IO 之后只能暂停，然后等待 IO 完成再由操作系统唤醒。
