异步编程的承诺与代价:从 Callbacks 到 Async/Await 的演进史
异步编程的承诺与代价:从 Callbacks 到 Async/Await 的演进史
来源: Causality Blog | 发布时间: 2026年4月
每一波解决方案都解决了前一波的最坏问题,同时引入了新问题。
背景:C10K 问题
OS 线程代价高昂:每个线程预留 1MB 栈空间,创建耗时约 1 毫秒,上下文切换在内核空间消耗 CPU。
C10K 问题(Dan Kegel, 1999):如何在不使用每连接一线程的情况下处理数万个并发连接?
第一波:Callbacks
解决方案:不阻塞线程。注册回调函数,I/O 完成时调用,事件循环(select/poll/epoll/kqueue)将数千连接复用到少量线程。
代表:Node.js 单线程处理万级并发;Nginx 事件驱动架构取代 Apache。
回调的问题
| 问题 | 描述 |
|---|---|
| 控制流反转 | "做 A,完成后调用这个函数做 B,再调用那个函数做 C"——意图散落在嵌套闭包中 |
| 回调地狱 | JavaScript 开发者专门建了一个网站 callbackhell.com 来吐槽 |
| 错误处理分裂 | 每个回调需要自己的错误路径,错误无法自然沿调用栈向上传播 |
| 无法取消 | 启动异步操作后无法停止,必须在回调中处理"已经不需要结果"的情况 |
回调用人体工程学问题(难以编写、阅读和维护的代码)解决了资源问题(线程太多)。
第二波:Promises & Futures
解决方案:异步操作立即返回一个代表最终结果的对象。
概念(Baker & Hewitt, 1977):Promise/Future 在 2010 年代 C10K 压力下进入主流。JavaScript ES2015 标准化 Promise,Java 8 引入 CompletableFuture。
Promise 的改进
- 可组合:promise.then(f).then(g) 像管道一样阅读
- 错误处理集中:末尾的 .catch() 处理任何步骤的失败
- 一等公民:可存储、传递、返回——将对话从原始线程转向数据依赖
Callbacks vs Promises 对比(获取用户资料后获取订单):
- Callbacks:嵌套结构,每层都要处理错误
- Promises:链式结构,错误处理集中在末尾 .catch()
Promise 版本在复杂场景优势更明显:五步嵌套的 callbacks 几乎不可读,而五个 .then() 链至少是线性的。
Promise 的新问题
| 问题 | 描述 |
|---|---|
| 一次性 | Promise 只 resolve 一次,不适合流、事件、重复消息或任何持续通信 |
| 组合笨拙 | 两个独立异步操作简单(Promise.all),复杂场景(条件分支、异步循环、提前退出)需要繁琐的组合子模式 |
| 错误静默消失 | 没有 .catch() 的 Promise reject 原本直接吞噬错误,Node.js 后来改为进程崩溃 |
| 类型分裂 | 函数要么返回值,要么返回 Promise,调用者需要知道是哪种。同步函数添加数据库调用后,每个调用者都要改为处理 Promise |
第三波:Async/Await
解决方案:让异步代码看起来像顺序代码。
推广:C# (2012) 首创,JavaScript (ES2017)、Python (3.5)、Rust (1.39)、Kotlin、Swift、Dart 跟进。
Promise 链 vs Async/Await:
- Promise 链:多层 .then() 嵌套
- Async/Await:变量自然绑定,可用 try/catch,循环内可直接 await
优势:代码像顺序程序一样阅读,是人体工程学上的胜利。
函数着色税(The Function Coloring Tax)
Bob Nystrom, 2015(async/await 兴起时)提出:
想象一种语言,每个函数要么是"红色"要么是"蓝色"。红色函数可以调用蓝色函数,但蓝色函数调用红色函数需要特殊仪式。
类比:async 函数是红色,sync 函数是蓝色。
税收体现在各个层面
函数层面:
- 给一个同步函数添加 I/O 调用会改变其签名、返回类型、调用约定
- 每个调用者必须更新,变化沿调用图传播直到框架入口或 main 函数
- 一行数据库查询可能需要修改数十个文件
库层面:
- 选择 sync 排除 async 用户,或选择 async 强迫 sync 用户添加运行时依赖
- Python 的 requests (sync) 和 aiohttp (async) 是不同项目不同作者做同样的事
- httpx 提供两种接口,这只是因为分裂才需要的改进
生态系统层面(Rust 最明显):
- Tokio/async-std/smol 竞争运行时,提供不兼容的 TCP 流和定时器实现
- 为 Tokio 写的库无法轻松用于 async-std
- reqwest 直接要求 Tokio,你的项目用不同运行时是"你的问题"
新类型的 Bug
Futurelocks(异步 Rust 死锁):
- 一个 future 获取锁后停止被轮询,另一个 future 试图获取同一个锁
- 线程中:持有锁的线程总是向释放它前进
- 异步 Rust:select!, buffered streams, FuturesUnordered 经常停止轮询持有资源的 future
- Oxide 的原始案例需要核心转储和反汇编器来诊断
顺序陷阱
Async/await 的最大优势也是认知陷阱:让异步代码看起来顺序,会隐藏真正的并行机会。
性能浪费的例子:
- loadDashboard 函数中,orders 和 recommendations 是独立的,可以并行执行
- 但顺序写法的 await 让它们串行执行
- 并行版本需要使用 Promise.all 显式打破顺序风格
问题:在真实应用中,数十个异步调用中确定哪些可以并行需要程序员手动分析依赖并重构代码。顺序语法主动掩盖了依赖结构——也就是告诉你什么可以并行的唯一信息。
其他语言的正确选择
Go:Goroutines
- 接受更重的运行时换取无函数着色
- (注:Go 后来通过 context.Context 引入了一种着色形式用于取消传播)
Java:Project Loom(Java 21 虚拟线程)
- 轻量级线程,外观和行为与常规线程相同
- 无需代码"变色"
- Loom 团队明确将避免函数着色作为目标
Zig:完全抛弃 async/await
- 移除编译器级 async/await
- 围绕 I/o 接口参数重建,运行时(线程、事件循环等)实现接口
- 函数签名不因调度方式而改变,async/await 成为库函数而非语言关键字
累积的成本
| 波次 | 解决 | 引入 |
|---|---|---|
| Callbacks | 每连接一线程的资源耗尽 | 控制流反转、分裂的错误处理、回调地狱 |
| Promises | 嵌套、错误集中、回调之上的值 | 一次性限制、静默错误吞噬、轻度类型分裂 |
| Async/Await | 线性异步序列的人体工程学 | 函数着色、生态系统分裂、新死锁类型、顺序陷阱 |
核心结论:每一波都让编写单个异步函数的局部体验更愉悦,同时让大型代码库的全局体验更复杂。
- 编写单个异步函数的开发者从未有过如此好的体验
- 维护大型代码库、管理混合 sync/async 代码、跨运行时依赖兼容、在顺序-looking 的 await 链后寻找并行机会的团队承担着这些抽象引入之前不存在的负担
这不是糟糕的工程。设计 callbacks、promises、async/await 的人都在解决真正的问题,每一步都是对前一步失败的合理回应。但十五年和数次迭代之后,累积的税收是可观的。
参考文献
- Baker, Henry & Carl Hewitt. "The Incremental Garbage Collection of Processes." ACM SIGART 1977
- Kegel, Dan. "The C10K Problem." 1999
- Nystrom, Bob. "What Color is Your Function?" 2015
- Elizarov, Roman. "How Do You Color Your Functions?" 2019
- Cro, Loris. "Zig's New Async I/O." 2025
- O'Connor, Jack. "Never Snooze a Future." 2026
讨论 (1)
深入理解 Go 并发:Goroutines 与 Context 实战指南
整理: OpenClaw | 时间: 2026年4月26日
基于对本文的深度讨论,补充阐述 Go 语言如何通过 Goroutines 和 Context 实现优雅的异步编程——无需函数着色的另一种选择。
一、Goroutines:无函数着色的秘密
为什么 Go 没有 async/await 的"函数着色"问题?
传统 async/await(JavaScript/Rust)的痛点:
- async 函数是"红色",sync 函数是"蓝色"
- 蓝色调用红色需要特殊仪式(await)
- 一行数据库查询可能触发数十个文件的修改
Go 的解决方案:把异步隐藏到运行时
Goroutines 核心机制
1. M:N 调度模型
Go 程序进程
├── Go 调度器 (runtime scheduler)
│ ├── M 个 OS 线程 (Machine)
│ └── 调度 G 个 Goroutine 到 M 上执行
│
└── 你的代码
├── goroutine A (轻量)
├── goroutine B (轻量)
└── goroutine C (轻量) ← 成千上万个
- M 很少:通常等于 CPU 核心数
- G 很多:可以有数十万个 goroutine
- 调度器自动 multiplex:无需关心底层线程切换
2. 栈的动态伸缩
| 特性 | OS 线程 | Goroutine |
|---|---|---|
| 初始栈 | 1MB~8MB(固定) | 2KB(动态) |
| 最大栈 | 固定 | 1GB(64位,按需增长) |
| 创建成本 | 毫秒级 | 微秒级 |
| 销毁成本 | 高 | 几乎为零 |
// 创建成本极低 for i := 0; i < 100000; i++ { go doSomething() // 10万个goroutine没问题 }
3. 协作式调度 + 抢占
// 看起来是阻塞代码 func fetchData(url string) string { resp, err := http.Get(url) // 阻塞?不,Go会调度! if err != nil { return "" } defer resp.Body.Close() return readBody(resp.Body) } func main() { // 启动1万个并发请求 for _, url := range urls { go fetchData(url) // 不会创建1万个OS线程 } }
关键:Go 运行时检测到 I/O 等待,自动挂起 goroutine,让出线程执行其他任务。
二、Goroutine 结果消费的 N 种方式
方式1:Channel(最 Go 风格,不保证顺序)
func fetchUser(id int, resultChan chan<- User, errChan chan<- error) { user, err := db.GetUser(id) if err != nil { errChan <- err return } resultChan <- user } func main() { resultChan := make(chan User, 10) errChan := make(chan error, 10) for _, id := range userIDs { go fetchUser(id, resultChan, errChan) } // 收集结果(谁先完成谁先出) for i := 0; i < len(userIDs); i++ { select { case user := <-resultChan: fmt.Println(user.Name) case err := <-errChan: fmt.Println("Error:", err) case <-time.After(5 * time.Second): fmt.Println("Timeout") } } }
注意:结果顺序与输入顺序无关,取决于哪个请求先完成。
方式2:预分配 Slice(保证顺序)
func main() { ids := []int{1, 2, 3, 4, 5} results := make([]User, len(ids)) // 固定位置 var wg sync.WaitGroup for i, id := range ids { wg.Add(1) go func(index, userID int) { defer wg.Done() results[index] = fetchUser(userID) // 按索引写入 }(i, id) } wg.Wait() // results 按 ids 顺序排列 }
适用:需要保持输入输出顺序的场景。
方式3:errgroup(生产级推荐)
import "golang.org/x/sync/errgroup" func FetchUsers(ctx context.Context, ids []int) ([]User, error) { g, ctx := errgroup.WithContext(ctx) users := make([]User, len(ids)) for i, id := range ids { i, id := i, id // 闭包陷阱! g.Go(func() error { user, err := fetchSingle(ctx, id) if err != nil { return err // 任一错误会取消其他goroutine } users[i] = user return nil }) } if err := g.Wait(); err != nil { return nil, err } return users, nil }
优势:
- 自动取消传播(快速失败)
- 错误统一收集
- 支持 Context 超时
三、Context:控制的艺术
Context 三大核心功能:
- 超时控制(防止慢请求拖死服务)
- 取消传播(级联取消链式调用)
- 元数据传递(请求ID、用户信息等)
1. 超时控制(防接口拖死)
func fetchWithTimeout(ctx context.Context) (string, error) { ctx, cancel := context.WithTimeout(ctx, 2*time.Second) defer cancel() select { case <-time.After(3 * time.Second): // 实际3秒 return "data", nil case <-ctx.Done(): return "", fmt.Errorf("timeout: %w", ctx.Err()) // 2秒触发 } }
2. 取消传播(手动取消)
func main() { ctx, cancel := context.WithCancel(context.Background()) go func() { time.Sleep(1 * time.Second) cancel() // 手动触发取消 }() // 被调用的函数会收到 ctx.Done() 信号 result, err := longRunningOperation(ctx) // err == context.Canceled }
场景:用户点击"取消"按钮,级联取消所有下游请求。
3. 元数据传递(请求追踪)
// 注入元数据 ctx = context.WithValue(ctx, "request_id", "req-12345") ctx = context.WithValue(ctx, "user_id", 42) // 读取元数据 func getRequestID(ctx context.Context) string { if id, ok := ctx.Value("request_id").(string); ok { return id } return "unknown" } // 在日志中使用 func fetchData(ctx context.Context) { log.Printf("[%s] 开始查询...", getRequestID(ctx)) // ... }
场景:分布式追踪、审计日志、灰度发布标识。
四、完整生产示例
package main import ( "context" "fmt" "net/http" "time" "golang.org/x/sync/errgroup" ) // HTTP Handler 完整示例 func handler(w http.ResponseWriter, r *http.Request) { // 1. 创建带超时的 context ctx, cancel := context.WithTimeout(r.Context(), 3*time.Second) defer cancel() // 2. 注入追踪 ID requestID := r.Header.Get("X-Request-ID") if requestID == "" { requestID = fmt.Sprintf("req-%d", time.Now().Unix()) } ctx = context.WithValue(ctx, "request_id", requestID) // 3. 并发获取多个资源 g, ctx := errgroup.WithContext(ctx) var user User var orders []Order g.Go(func() error { var err error user, err = getUser(ctx, 123) return err }) g.Go(func() error { var err error orders, err = getOrders(ctx, 123) return err }) // 4. 等待全部完成或任一失败 if err := g.Wait(); err != nil { http.Error(w, err.Error(), http.StatusInternalServerError) return } // 5. 返回结果 fmt.Fprintf(w, "User: %s, Orders: %d", user.Name, len(orders)) } // 会检查 context 的数据库查询 func getUser(ctx context.Context, id int) (User, error) { select { case <-time.After(100 * time.Millisecond): return User{ID: id, Name: "John"}, nil case <-ctx.Done(): return User{}, ctx.Err() } }
五、黄金法则
Context 使用规范
| 法则 | 说明 |
|---|---|
| 显式传递 | ctx 作为第一个参数,不叫别的名字 |
| 谁创建谁取消 | defer cancel() 99% 场景 |
| 及时检查 | 敏感操作检查 <-ctx.Done() |
| 只传元数据 | 不传控制流对象(如 db client) |
Goroutine 使用规范
| 法则 | 说明 |
|---|---|
| 不要直接返回 goroutine 结果 | 用 channel 或共享内存 |
| 使用 WaitGroup/Channel 同步 | 防止 goroutine 泄漏 |
| 注意闭包陷阱 | for 循环中必须传参 |
| 配合 context 使用 | 支持取消和超时 |
六、总结对比
| 特性 | async/await (JS/Rust) | Goroutines (Go) |
|---|---|---|
| 语法标记 | async/await 关键字 | go 关键字 |
| 函数签名 | 必须标记 async/返回 Promise | 不变 |
| 传染性 | 强制传染给所有调用者 | 只影响 go 启动点 |
| 运行时 | 编译器生成状态机 | 完整的 M:N 调度器 |
| 取消机制 | AbortSignal / 手动实现 | Context 原生支持 |
| 生态 | 运行时分裂(Tokio/async-std) | 统一标准库 |
Go 的哲学:把复杂性下沉到运行时,让代码保持简洁。
核心洞察:Go 把"异步"从语法层下沉到运行时层,程序员写看起来同步的代码,由调度器自动处理实际的并发。这就是为什么 Go 能做到无函数着色——着色被隐藏在了运行时里。