同步与异步：一个关于「谁来等」的问题

定义：一句话，两个角色

一次调用里有两个角色：调用方（caller）和被调方（callee）。

注意这个定义里完全没有提到线程。这不是疏忽，这是重点 —— 同步/异步说的是控制流的形状，不是线程的下场（那是下一章的事）。

同一个 HTTP 请求，四种写法

下面这个 demo 把四种写法的时序泳道摆在一起。请重点看两条泳道之间的关系 —— 调用方那一条，什么时候是「粘住的」，什么时候是「自由的」。

异步的三次进化

异步这件事，业界折腾了三十年，走了三步。每一步都在解决上一步的痛。

第一步：回调 —— 把「接下来干什么」交出去

// 这是「控制反转」:你不再决定接下来执行什么,
// 你把「接下来执行什么」写成一个函数,交给别人替你调。
getUser(id, function (err, user) {
    if (err) return handle(err);
    getOrders(user.id, function (err, orders) {
        if (err) return handle(err);
        getItems(orders[0].id, function (err, items) {   // ← 三层了
            if (err) return handle(err);
            render(items);
        });
    });
});

它能工作，而且是最底层、最诚实的形态 —— 所有的异步机制，剥到最底下都是回调。

但它有三个致命伤：

• 回调地狱。每多一次异步调用，就多缩进一层。三层还能看，五层就没人愿意碰了。
• 错误处理是手工的。每一层都得自己 if (err)。try/catch 完全失效 —— 因为回调是在未来的某个时刻、由别人的栈调用的，你的 try 早就退出了。
• 组合不了。「并发发三个请求，全部完成后继续」—— 用裸回调写，你得手工维护一个计数器。

第二步：Future / Promise —— 把「凭据」拿回来

关键的一步反转：不是把「接下来干什么」交出去，而是把「一张凭据」拿回来。

// 调用立刻返回一个 Deferred(Kotlin 里 Future 的名字)
val userD: Deferred<User> = async { api.getUser(id) }

doSomethingElse()          // 我还是自由的

val user = userD.await()   // 需要结果时,才来兑现这张凭据

凭据（Future / Promise / Deferred / CompletableFuture，名字各异，是同一个东西）是一个代表「未来的值」的对象。它有三个状态：进行中、成功、失败。

这一步解决了什么：

• 可以组合了。awaitAll(a, b, c)、Promise.all([...])、errgroup.Wait() —— 「并发做三件事，都好了再继续」变成了一行。
• 错误可以传播了。失败是凭据的一个状态，可以一路 .map() / .flatMap() 传下去。
• 嵌套变成了链式。a.then(b).then(c) —— 至少不再往右缩进了。

但它还是有味道：.then().then().catch() 这种链，和你脑子里那个「先 A 再 B 再 C」的顺序流程，长得不一样。你得在两种心智模型之间来回翻译。

第三步：async / await —— 把异步伪装成同步

最后一步是语法层面的：既然人脑最擅长读顺序代码，那就让异步代码长得跟同步代码一模一样。

getUser(id, (err, user) => {
  if (err) return handle(err)
  getOrders(user.id, (err, os) => {
    if (err) return handle(err)
    render(os)
  })
})

try {
  val user   = getUser(id)
  val orders = getOrders(user.id)
  render(orders)
} catch (e: Exception) {
  handle(e)          // try/catch 回来了!
}

右边那段代码看起来完全是同步的：从上往下读、局部变量、try/catch、for 循环、早返回 —— 所有你熟悉的控制流结构全都回来了。

但它行为上是异步的：在每个挂起点，当前线程被交还回去干别的活了。

「函数染色」：async/await 的税

async/await 不是免费的。它有一个著名的代价，叫函数染色（function coloring）——出自 Bob Nystrom 2015 年的博文《What Color is Your Function?》。

规则很简单，也很烦人：

• 一个 async 函数，只能被另一个 async 函数调用。
• 于是：你在调用链的最底层加了一个 async，整条链上的每一个函数都得跟着变成 async。

async def query_db(sql):        # 底层:改成了异步
    ...

async def get_user(id):          # 于是它也得是 async
    return await query_db(...)

async def handle_request(req):   # 于是它也得是 async
    return await get_user(...)

# 一路染到 main()。这就是「染色」。
# 你的代码库里从此有两个世界:async 的和非 async 的,
# 而它们之间的每一次穿越都要付出代价。

Kotlin 的 suspend 也有一模一样的问题。

一个反直觉的推论

异步不会让单个请求变快。

这一点值得单独说，因为它是最常见的期望落空：

还有一种「异步」：消息队列

最后提一下，免得混淆。当架构师说「这个流程改成异步的」，他说的经常不是上面任何一种，而是：

// 同步:用户等着,直到订单真的创建完
func CreateOrder(req) Response {
    order := db.Insert(req)      // 50ms
    sendEmail(order)             // 800ms  ← 用户为什么要等这个?
    updateInventory(order)       // 300ms
    return Response{order.ID}    // 用户等了 1150ms
}

// 「异步」:把不重要的活扔进队列,立刻返回
func CreateOrder(req) Response {
    order := db.Insert(req)      // 50ms
    mq.Publish("order.created", order)   // 1ms,扔出去就不管了
    return Response{order.ID}    // 用户只等了 51ms
}
// 发邮件、扣库存由别的 worker 慢慢做。

这是架构层面的异步，和语言层面的 async/await 是两个话题，但内核思想完全一致：调用方不等结果，接着往下走。

它的代价也很实在：最终一致性（用户看到「下单成功」时，邮件其实还没发）、失败处理（邮件发失败了怎么办？谁重试？重试几次？）、消息丢失（队列挂了呢？）。

下一章：把第二组词钉死。同步和阻塞不是一回事 —— 一个说的是「我能不能往下走」，一个说的是「那个线程还活着吗」。