在编程领域,并发异步这两个概念并没有初学者想象的那么高深,本文将以最普通的白话,拆解这两个概念,读完后下面这一系列问题,或许你就有了答案。

  • 协程是什么?
  • 协程线程的本质区别是啥?
  • 哪些编程语言支持协程?有栈协程无栈协程有什么区别?
  • CSP模型是什么意思?
  • Actor模型是什么意思?
  • I/O多路复用到底解决了什么问题?
  • 线程间上下文切换的成本真的很高吗?
  • 为什么用同步原语进行并发编程常常出BUG?
  • 怎么解决异步回调模式的可维护性问题?
  • async/await算协程吗?和Generator函数是什么关系?
  • 什么是函数响应式编程(FRP)
  • 为什么Node.js要用单线程?真的只有一个线程吗?
  • 为什么Java到JDK 16还没有协程
  • 为什么更优雅的Actor模型、FRP没有成为主流?

篇幅较长,建议点赞收藏后慢慢看~。

主流编程语言的并发模型

为了方便理解,我们用餐厅打个比方,贯穿整篇文章。

CPU核心,或者说Processor,是厨师

Thread是灶台

理想情况下,一个厨师一个灶台,厨师一刻不停的炒菜。这种情况餐厅老板是最开心的。

但是,客人不仅吃炒菜,也喜欢喝鸡汤。厨师(Processor)需要在一个灶台炖汤(I/O操作)的时候,换到别的灶台(Thread)炒菜,换灶台就叫线程间上下文切换

于是,一系列问题就出现了。

我们先从大家熟悉的多线程编程开始讲。

三头六臂:多线程模型

典型代表:Java。

哦,放错图了。

加入客人要100锅鸡汤,最朴素的办法就是放100个灶台,每个灶台炖一锅。厨师需要有三头六臂来回奔波,哪个炖了多久、哪个要加调料,都要厨师操心。

这种方案好像除了换灶台费点事,好像也没什么大问题。编程语言实现多线程模型,大多基于操作系统提供的原生线程,再包装一层出来给开发者用。而封装的线程OS线程一对一关系,线程调度完全交给操作系统就完事了,编程语言的Runtime实现也相对简单。

不过,当生意越来越好,老板雇两个厨师来一起干(多核并行编程),问题就出来了。对于同一锅鸡汤:

  • 1号厨师放过盐了,2号厨师不知道又放了一次,客户非常生气;
  • 两个厨师都以为对方放了盐,结果都没放盐,客户非常生气;
  • 1号厨师和2号厨师正巧准备一起放,两人互相扯皮了半天还没放,所有客户都非常生气。

这叫竞态条件(Race Condition)。解决这类问题,需要用到各种同步原语:从CPU硬件层面的CAS指令;到OS级别的临界区、信号量、互斥量;再到编程语言的原子类型、各种锁、同步栅栏、并发安全的集合,都是让内存数据能被多核CPU安全地修改

除了同步原语,有没有其他办法呢?餐厅的老板很聪明,想到了两种新的方案,下面两节分别介绍。

万剑归宗:I/O多路复用 + 单线程模型

典型代表:JavaScript。

回顾上一节那个餐厅的难题:炖的汤越来越多,换灶台要时间,灶台太多放不下,厨师多了会打架

餐厅老板脑袋一拍:咱就炖个汤还请那么多厨师干嘛?就雇一个厨师不就好了吗!什么,厨师忙不过来?雇勤杂工!

厨师放调料要1秒,炖的过程要等1小时。类比计算机世界也类似,不同部件的执行速度严重失衡:CPU计算 >> 主存读写 >> 网络或文件I/O

  • CPU很快:1核CPU在一眨眼的功夫,100毫秒,就可以执行数亿条指令。
  • I/O很慢:如果一次主存访问想象成1天的话,一趟局域网数据传输就要13.7年。

老板雇了勤杂工之后,炖鸡的这些锅,全都交给勤杂工一起批量照看就好了,大厨只负责在恰当的时候放调料。脑补一下关东煮就明白了:

我们把每个小格子想象成一个Socket连接,这就叫I/O多路复用

在餐厅里:有一个手持任务队列、名为EventLoop的大厨线程,加上N个任劳任怨的勤杂工线程一起干活。

以Node.js为例,厨师是这样的:

1
2
3
cooker.on("该放调料了", () => {
console.log("一眨眼功夫就放好啦")
})

苦逼的勤杂工们,被关在一个叫“libuv”的小黑屋里,切到内核态进行系统调用,干着类似这样的活:

1
2
3
4
5
6
7
8
9
// 设置Socket非阻塞
setnonblocking(socket_fd);
ep_fd = epoll_create(max_events);

while (true) {
// 被困在系统里的“勤杂工”
epoll_wait(..)
// 阻塞式读取数据,交给大厨处理
}

从这个模型来看,I/O多路复用,本质上是解决了I/O与计算职责分离的问题。当网络I/O的脏活、累活分离出去了,只要一位大厨,炖百万只鸡不在话下。Node.js、Redis都是这么干的。篇幅原因,只简单说明了网络I/O的案例。定时器、文件I/O等异步任务的实现原理是不一样的,和I/O多路复用无关

然鹅,这里有一个巨大的隐患。

如果不仅要做关东煮或者炖鸡(I/O密集型任务),还时常要做炒菜(CPU密集型任务)怎么办?

协程,该出场了。

千手观音:协程模型

典型代表:Erlang / Golang。

为了解决既要炒菜又要炖汤的问题,聪明的餐厅老板又脑袋一拍,想到一个万全之策

  • 多雇几个厨师,但是每个人只管面前这一个灶台 —— 不需要线程切换,有多少核CPU就建多少OS线程;
  • 不用增加灶台,但要购置一大批锅 —— 这些“锅”就是协程(coroutine);
  • 之前雇的勤杂工继续照看炖鸡的锅和关东煮的锅 —— 继续保留 非阻塞I/O + I/O多路复用 的优良传统;
  • 再雇一波勤杂工,就叫他们“换锅侠”吧,专门负责看厨师们面前的锅有没有炒好、放好调料,弄好了就立刻帮厨师换锅 —— 协程调度

协程最核心的特点就是:不用OS线程的上下文切换,在用户态实现超轻量的执行单元调度。协程的实现有很多,可以根据协程之间有无调用栈分为有栈协程无栈协程;也可以根据协程间是否存在从属关系分为对称协程非对称协程

多面手:你有我有全都有~

其实,编程语言的演进过程也是互相“借鉴”的过程,最后的结果就是“你有我有全都有”。其中最典型的“借鉴”就是Generator函数,搭配async/await或yield实现无栈协程

async/await模式我们在下面讲异步编程范式再细谈,是一个兼顾实现成本、迁移成本、性能、可维护性的方案,因此多数主流编程语言都可以看到async/await协程的身影。比如:

  • C++(20): co_await/co_return/co_yield
  • C#: async/wait, yield
  • JavaScript: async/await, yield
  • Dart: async/await, yield
  • Python:async/await, yield

注:

  • 虽然C++ 20在语法层面提供的是无栈协程,C/C++ 生态也有诸多使用汇编或其他方式实现的有栈协程库
  • 执行线程是单线程的Node.js,也早已提供了多线程的支持,用于处理CPU密集型任务。

异步编程范式

上面一节我们讲了3种并发模型,基于编程语言实现的并发模型,又演化出了多种异步编程范式。下面一节,我们逐个讲解各类异步编程范式,仍然举餐厅的例子,设想一个场景:现在想让厨师做鸡汤给我们喝,需要 startBoil/coolDown/drinkSoap 3个耗时操作。

在讲异步编程范式之前,我们先看同步编程是怎么做的。为了保持简洁,假设都在一个线程执行了,不涉及多线程间共享数据。

1
2
3
4
5
new Thread(() -> {
startBoil();
coolDown();
drinkSoap();
}).start();

异步回调模式

这三个操作要转换成异步调用模式,最直观的解决方案就是用回调函数。什么是回调函数呢?

声明一个函数,把函数指针丢给调度器,这次I/O搞定了就来执行它,这就是一个Callback。

1
2
3
4
5
6
7
8
9
startBoil(function callback() {
console.log("炖好了,撒点盐")
coolDown(function callback() {
console.log("现在可以喝了")
drinkSoap(function callback() {
console.log("嗝~~")
})
})
})

虽然避免了线程间上下文切换的问题,但这样写异步代码,写着写着屏幕就不够宽了。嵌套回调越来越深,变成了回调地狱,下面几节就是常见解法。

  • async/await/yield:熨平callback嵌套褶皱;
  • 发布订阅模式:把callback丢出去不管了;
  • 函数响应式编程:把callback做成烤串;
  • CSP模型/Actor模型:回归同步调用,放到有栈的协程/线程。

涅槃:async/await范式

async/await本质上是编程语言对generator/yield的一层语法糖。懂了Generator也就明白了async/await的原理,以及为什么Generator函数可以熨平回调函数的嵌套褶皱。

具体的原理分析网上有很多文章,比如这个Node.js的:async/await 源码实现

一句话概况就是:Generator可以看做状态机,遇到yield就进入Pending状态出让执行权,遇到resume/next就继续执行,直到下一个yield。编程语言或者SDK把generator函数包装成 async/await 关键字,就能在看似同步的代码块中异步执行,由于Generator实现的协程是在当前栈顶上继续调用函数,只能模拟携带上下文,并不是真正的保存当前上下文,切换到另一个协程栈,因此是无栈协程。

1
2
3
4
5
async () => {
await startBoil();
await coolDown();
await drinkSoap();
}

这种看上去像同步的调用,让心智负担大大降低,也是实际工程中权衡利弊的工程中非常实用的方案。

不过,async/await因为是无栈协程,存在一个小问题:关键字传染

1
2
3
4
5
async () => {
someArray.forEach(async () => {
// 只要调用链底存在异步,一条链全部都要带上async关键字
})
}

下次写async function,理解了调用栈存在异步代码,这是第一层;理解了是在写一个Generator状态机实现的无栈协程,这是第二层。

蜕变:函数响应式编程范式

除了async/await/yield,异步回调地狱还有另一个解法 —— 函数响应式编程(FRP)。

在讲FRP之前,我们先复习一下,小学二年级学过的“发布订阅模式”。

1
2
3
4
5
6
7
8
9
10
11
// cooker.js
eventBus.on("炖好了", () => {
eventBus.emit("可以喝了")
})

// eater.js
eventBus.on("可以喝了", () => {
console.log("嗝~~")

console.log("对了,汤咋做出来的,炖汤之前嘎哈了?")
})

发布订阅模式在异步编程中,从另一个维度解决掉了回调地狱问题。让Event Bus统一管理一大锅Callback,每个Callback挂了一个onXXXEvent的标签,来了什么异步事件,就让Event Bus统一来调用对应的函数。

既然一个Event Bus就解决了回调地狱问题,为什么还要函数响应式编程呢?

因为解开的Callback,会带来逻辑碎片化的问题。也就是说,完全靠Event Listener无法写出高内聚的代码。

那有没有办法,把碎片化的回调函数整合起来,让代码重新内聚呢?

萝卜加大棒,听说发布订阅模式函数式编程更配哦?

函数式编程(FP)是一个自古有之的概念,把一沓纯净的函数声明式地组合起来,理论上就可以实现任何功能。事件驱动的异步回调函数,经过FP的洗礼,变成了Callback烤串,外酥里嫩。

我理解的函数响应式编程:就是通过一系列操作符对函数组合,实现复杂的异步事件流的操纵和处理,异步事件与函数式编程的完美结合。

比如下面是一段用RxJS实现异步事件流处理的代码,没有回调地狱,也不需要async/await。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
// incoming$ is a stream that flows
MessageBus.incoming$.pipe(
// delay messages after call pauseDispatcher()
delayWhen(() => this.pauseUnAvailable()),

// dispatch input messages, transform input stream to output stream
mergeMap((input) => this.handleCommand(input)),

// publish output messages
mergeMap((output) => this.sendAckIfNeed(output)),

// record output
tap((output) => {
this.logOutput(output);
})
)
.subscribe(() => {})

大家熟知的Java界新秀:Vert.x, WebFlux 等等框架,前端的Angular/Vue/React框架都有FRP的影子,尤其是Angular就是RxJS用做状态管理。

CSP/Actor模型:一切皆消息

Do not communicate by sharing memory; instead, share memory by communicating.

上面这句名言,Share Nothing架构,也解释了CSP模型和Actor模型的共性:把编程问题转换为通信问题,不同的执行单元不共享同一份内存数据,因此就不需要任何同步原语控制共享数据的访问。

我们先说CSP模型,CSP是上个世纪七十年代提出的,用于描述两个独立的并发实体通过共享的 channel 进行通信的并发模型。Golang用channel炖鸡汤的代码如下:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
package main

import (
"fmt"
"time"
)

func main() {
boiled := make(chan struct{})
drinkable := make(chan struct{})
finished := make(chan struct{})

go func() {
fmt.Printf("开始炖\n")
time.Sleep(time.Second)
fmt.Printf("炖好了\n")
boiled <- struct{}{}
}()

go func() {
<-boiled
fmt.Printf("凉一凉\n")
time.Sleep(time.Second)
fmt.Printf("凉好啦,可以喝了\n")
drinkable <- struct{}{}
}()

go func() {
<-drinkable
fmt.Printf("喝完啦\n")
finished <- struct{}{}
}()

<-finished
}

注:Golang虽然部分实现了CSP模型,但语言本身也允许共享内存数据,如果不用channel机制,直接多协程更新共享数据,不正确使用同步原语也一样会出现并发BUG。

至于常常一起被提到的Actor模型,我们常说Erlang、Scala-Akka就是典型的Actor模型(虽然Erlang的诞生比Actor模型概念的提出更早,Erlang的作者也不认为Erlang是Actor模型),其主要特点也是在于把编程问题转换为通信问题

  • Actor之间完全不存在共享数据,创建Actor非常廉价;
  • 每个Actor,在Erlang中叫微进程,有自己的执行栈,互相之间完全隔离
  • 每个Actor有一个“邮箱”, Actor之间通过收发邮箱通信。

与CSP模型不同的是,Actor模型更进一步,每个独立的并发实体都有一份自己的“Channel”,在Erlang中叫“具名邮箱”。可以看出,这种抽象非常适合消息相关的领域,比如曾经WhatsApp增长到9亿用户也只有50人维护的聊天服务器、Zoom的聊天服务器、一些著名的分布式消息队列组件,都是用Erlang开发的。

因此,简单的理解Actor模型就是:有栈协程/线程 + 发布订阅模式 + Share-nothing 架构。CSP模型与Actor更细节的原理可以阅读这篇文章:并发之痛 Thread,Goroutine,Actor

到底哪个范式最好?

我们从主流编程语言的并发模型出发,了解了几类异步编程范式及其演化历程,学习了5种喝汤姿势。那么,这些并发模型下的异步编程范式,谁最好,谁最差?

理论 vs 现实

理论上,上面介绍的4种范式中:函数响应式编程、Sharing noting的Actor模式 似乎是最优雅的解决方案;
实际上,目前世界上大部分代码,都是在用 同步编程、Async/Await的假装同步,这两个看似一堆缺点的方案。

为什么会这样呢?

其原因我们从FP的发展历程可以看出来。猿界有一支神秘的学院派函数式编程的崇拜者,念叨着函子,单子、纯函数、柯里化之类的咒语,膜拜Lisp、Pascal,鄙视新泽西派简陋的C、C++、Golang、蓝领语言Java。从工程师的视角看,FP的确在一些基础库和特定领域解决了非常关键的问题,但很难成为软件系统中的砖头和水泥。

类似的,Actor模型、FRP这类技术或许一直将是小众,因为:

  • 世界是不确定的:世界充满不确定的变化,无法用完美的模型来表示,打补丁才是常态;
  • 人脑带宽有限:当一种知识,学习它的心智成本过高,学习它的人数就会呈幂律分布骤减。

为什么Java没有协程

广泛使用的Java就是线程池、JUC类库撸到底,协程是什么,我不听,我不听。Java官方的协程特性支持(Project Loom)从JDK 14就说要发布了,难产了好几个大版本,至今还没生出来。

那么,为什么Java头这么铁,是道德的沦丧还是人性的扭曲?

其实也不能怪Java,这里有一系列很棒的回答:为什么Java坚持多线程不选择协程?,总结一下主要原因有:

  • 数据库操作无法协程化,20多年的JDBC标准就是同步的、一个连接一个线程。其他部分花里胡哨的NIO/Reactor也没法根除线程池模式,除非不用JDBC;
  • 大部分网络I/O已经被Netty们剥离出去,性能瓶颈问题已经解决大半,JDBC的数据库I/O剥不出去也没太大问题,毕竟大部分数据库自己就处理不了太高并发;
  • 同步编程的业务线程池就算切换白耗一点CPU又咋地了,毕竟JVM已经那么吃内存了,Spring全家桶各种AOP、反射的损耗已经那么多了,不在乎再多耗一点;
  • 同步编程模式符合直观思维模式,已经深入广大JAVAer的心,Reactor/ReactiveX那一套即使学会了,习惯了传统的Java编程模式的开发者用起来也别扭;
  • 历史包袱太沉,核心生态对线程池、ThreadLocal、JDBC这些东西的依赖太强,迁移成本很高,从Project Loom的Virtual Thread的设计也可以看出来;
  • 其实线程上下文切换的开销也没有那么恐怖,现代CPU可以做到约每秒33万次线程切换,一次耗时约3μs,即使相比于Golang的协程切换慢了30倍,这些开销也可以接受。

没有协程的Java活的很好。其实多线程模型下,内存数据共享也不是原罪,关键在于数据共享时,执行上下文自动被外部调度器切换了才是BUG之源,于是需要依靠同步原语头发稀疏程度来保障不出BUG。

因此,Java的面试总要问成堆的并发、同步栅栏、锁、线程池问题,JavaScript的面试就不会。

结语

综上,哪个语言的并发模型最好、哪种异步编程范式最好,不会存在标准答案。

想象中的世界只会存在于想象,现实世界总是 Worse is better。能解决掉实际问题的技术,就会有市场,不管我们是认为它们好还是坏、优雅还是丑陋。即使是被诟病的回调模式也存在应用场景,毕竟直接传函数指针过去,没有性能损耗,是运行效率最高的方案。

对于编程语言和范式的选择,并不一定是单选题。实际开发中,我们完全可以混合范式编程,对特定的业务类型应用特定的编程范式,找最优解对付现实问题。

不管黑猫白猫,抓到老鼠就是好猫。