关于java:异步编程的几种方式你知道几种

作者：Eric Fu\
链接：https://ericfu.me/several-way…

近期尝试在搬砖专用语言 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）：

1. 把调用者 f() 还未执行的局部包成一个函数对象 cont，一起传给被调用者 g()；
2. 失常运行 g() 函数体；
3. 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 实现再由操作系统唤醒。

var input = recv_from_socket()  // Block at syscall recv()
var result = calculator.calculate(input)
send_to_socket(result) // Block at syscall send()

而异步 IO 中，过程发动 IO 操作时也会一并输出回调（也就是 Continuation），这大大解放了生产力——现场无需期待，能够立刻返回去做其余事件。一旦 IO 胜利后，AIO 的 Event Loop 会调用刚刚设置的回调函数，把剩下的工作实现。这种模式有时也被称为 Fire and Forget。

recv_from_socket((input) -> {var result = calculator.calculate(input)
    send_to_socket(result) // ignore result
})

就这么简略，通过咱们本人实现的 Continuation，线程不再受 IO 阻塞，能够无拘无束地跑满 CPU。

一颗语法糖：Promise

回调函数哪里都好，就是不大好用，以及太丑了。

第一个问题是可读性大大降落，因为咱们绕开操作系统自制 Continuation，所有函数调用都要传入一个 lambda 表达式，你的代码看起来就像要腾飞一样，缩进止不住地往右挪（the “Callback Hell”）。

第二个问题是各种细节解决起来很麻烦，比方，思考下异样解决，看来传一个 Continuation 还不够，最好再传个异样解决的 callback。

Promise 是对异步调用后果的一个封装，在 Java 中它叫作 CompletableFuture (JDK8) 或者 ListenableFuture (Guava)。Promise 有两层含意：

第一层含意是：我当初还不是真正的后果，然而承诺当前会拿到这个后果。这很容易了解，异步的工作迟早会实现，调用者如果比拟蠢萌，他也能够用 Promise.get() 强行要拿到后果，顺便阻塞了以后线程，异步变成了同步。

第二层含意是：如果你（调用者）有什么嘱咐，就通知我好了。这就乏味了，换句话说，回调函数不再是传给 g()，而是 g() 返回的 Promise，比方之前那段代码，咱们用 Promise 来书写，看起来悦目了不少。

var promise_input = recv_from_socket()
promise_input.then((input) -> {var result = calculator.calculate(input)
    send_to_socket(result) // ignore result
})

Promise 改善了 Callback 的可读性，也让异样解决稍稍优雅了些，但究竟是颗语法糖。

反应式编程

反应式（Reactive）最早源于函数式编程中的一种模式，随着微软发动 ReactiveX 我的项目并一步步壮大，被移植到各种语言战争台上。Reactive 最后在 GUI 编程中有宽泛的利用，因为异步调用的高性能，很快也在服务器后端畛域遍地开花。

Reactive 能够看作是对 Promise 的极大加强，相比 Promise，反应式引入了流（Flow）的概念。ReactiveX 中的事件流从一个 Observable 对象流出，这个对象能够是一个按钮，也能够是 Restful API，总之，它能被外界触发。与 Promise 不同的是，事件可能被触发屡次，所以解决代码也会被屡次调用。

一旦容许调用屡次，从数据流动的角度看，事实上模型曾经是 Push 而非 Pull。那么问题来了，如果调用频率十分高，以至于咱们处理速度跟不上了怎么办？所以 RX 框架又引入了 Backpressure 机制来进行流控，最简略的流控形式就是：一旦 buffer 满，就抛弃掉之后的事件。

ReactiveX 框架的另一个长处是内置了很多好用的算子，比方：merge（Flow 合并），debounce（开关除颤）等等，不便了业务开发。上面是一个 RxJava 的例子：

CPS 变换：Coroutine 与 async/await

无论是反应式还是 Promise，说到底依然没有解脱手工结构 Continuation：开发者要把业务逻辑写成回调函数。对于线性的逻辑根本能够应付自如，然而如果逻辑简单一点呢？（比方，思考下蕴含循环的状况）

有些语言例如 C#，JavaScript 和 Python 提供了 async/await 关键字。与 Reactive 一样，这同样出自微软 C# 语言。在这些语言中，你会感到前所未有的爽感：异步编程终于解脱了回调函数！惟一要做的只是在异步函数调用时加上 await，编译器就会主动把它转化为协程（Coroutine），而非低廉的线程。

魔法的背地是 CPS 变换，CPS 变换把一般函数转换成一个 CPS 的函数，即 Continuation 也能作为一个调用参数。函数不仅能从头运行，还能依据 Continuation 的批示持续某个点（比方调用 IO 的中央）运行。

能够看到，函数曾经不再是一个函数了，而是变成一个状态机。每次 call 它、或者它 call 其余异步函数时，状态机都会做一些计算和状态轮转。说好的 Continuation 在哪呢？就是对象本人（this）啊。

CPS 变换实现非常复杂，尤其是思考到 try-catch 之后。然而没关系，复杂性都在编译器里，用户只有学两个关键词即可。这个个性十分优雅，比 Java 那个废柴的 CompletableFuture 不晓得高到哪去了

JVM 上也有一个实现：electronicarts/ea-async，原理和 C# 的 async/await 相似，在编译期批改 Bytecode 实现 CPS 变换。

终极计划：用户态线程

有了 async/await，代码曾经简洁很多了，基本上和同步代码无异。是否有可能让异步代码和同步代码齐全一样呢？听起来就像收费午餐，然而确实能够做到！

用户态线程的代表是 Golang。JVM 上也有些实现，比方 Quasar，不过因为 JDBC、Spring 这些周边生态（它们占据了大部分 IO 操作）的缺失根本没有什么用。

用户态线程是把操作系统提供的线程机制齐全摈弃，换句话说，不去用这个 VM 的虚拟化机制。比方硬件有 8 个外围，那就创立 8 个零碎线程，而后把 N 个用户线程调度到这 8 个零碎线程上跑。N 个用户线程的调度在用户过程里实现，因为一切都在过程外部，切换代价要远远小于操作系统 Context Switch。

另一方面，所有可能阻塞零碎级线程的事件，例如 sleep()、recv() 等，用户态线程肯定不能碰，否则它一旦阻塞住也就带着那 8 个零碎线程中的一个阻塞了。Go Runtime 接管了所有这样的零碎调用，并用一个对立的 Event loop 来轮询和散发。

另外，因为用户态线程很轻量，咱们齐全没必要再用线程池，如果须要开线程就间接创立。比方 Java 中的 WebServer 简直肯定有个线程池，而 Go 能够给每个申请开拓一个 goroutine 去解决。并发编程从未如此美妙！

总结

以上计划中，Promise、Reactive 实质上还是回调函数，只是框架的存在肯定水平上升高了开发者的心智累赘。而 async/await 和用户态线程的解决方案要优雅和彻底的多，前者通过编译期的 CPS 变换帮用户发明出 CPS 式的函数调用；后者则绕开操作系统、从新实现一套线程机制，所有调度工作由 Runtime 接管。

不晓得是不是因为历史包袱太重，Java 语言自身提供的异步编程反对弱得可怜，即使是 CompletableFuture 还是在 Java 8 才引入，其结果就是很多库都没有异步的反对。尽管 Quasar 在没有语言级反对的状况下引入了 CPS 变换，然而因为短少周边生态的反对，理论很难用在我的项目中。

最初，关注公众号 Java 技术栈，在后盾回复：面试，能够获取我整顿的 Java 多线程系列面试题和答案，十分齐全。

References

1. https://blog.tsunanet.net/201…
2. http://reactivex.io/
3. https://zhuanlan.zhihu.com/p/…
4. http://docs.paralleluniverse….
5. http://morsmachine.dk/go-sche…
6. https://medium.com/@ThatGuyTi…

近期热文举荐：

1.600+ 道 Java 面试题及答案整顿(2021 最新版)

2. 终于靠开源我的项目弄到 IntelliJ IDEA 激活码了，真香！

3. 阿里 Mock 工具正式开源，干掉市面上所有 Mock 工具！

4.Spring Cloud 2020.0.0 正式公布，全新颠覆性版本！

5.《Java 开发手册（嵩山版）》最新公布，速速下载！

感觉不错，别忘了顺手点赞 + 转发哦！