异步编程的发展

线程的终结早年写服务端逻辑很简单一个请求一个线程。用户 A 请求 → 创建线程 A → 查数据库 → 返回结果 用户 B 请求 → 创建线程 B → 查数据库 → 返回结果代码写起来像同步程序一样自然——因为它本来就是同步的。你不需要关心什么异步、回调、事件循环写完就走。问题是线程很重。一个线程默认 1MB 栈空间上下文切换要进内核态。100 个并发没问题10000 个并发呢操作系统受不了。这就是 2000 年代初著名的C10K 问题——同时处理一万个连接线程模型扛不住。所以人们抛弃了线程。回调地狱Node.js 带来的思路是不要用线程用事件循环。所有 I/O 操作读数据库、发 HTTP 请求、读文件都不阻塞当前线程而是我发个请求等它回来再调你这个函数。同一个线程可以同时挂起几百个请求。getUser(userId,(err,user){if(err)returnhandleError(err);getOrders(user.id,(err,orders){if(err)returnhandleError(err);render(user,orders);});});内存问题解决了。一万个连接只用一个线程因为挂起的连接几乎不占内存。但代码结构被毁了。本来应该从上往下读的代码变成了右斜式的嵌套。嵌套深了叫“回调地狱”callback hell每个回调都要单独处理错误if (err)写得到处都是正常的函数调用栈断了——错误没法按正常方式传播想取消一个还没回来的请求没有这个机制回调解决了并发量的问题但让代码没法读了。Promise 的救赎Promise 的核心思路异步操作应该返回一个未来的结果而不是要求你传一个回调进去。// 回调风格嵌套、每个层级都要处理错误getUser(userId,(err,user){if(err)returnhandleError(err);getOrders(user.id,(err,orders){if(err)returnhandleError(err);render(user,orders);});});// Promise 风格链式调用、错误统一处理getUser(userId).then(usergetOrders(user.id)).then(ordersrender(orders)).catch(handleError);Promise 做了三件回调做不到的事把回调压平——.then()链式调用不用右斜嵌套了错误统一收口——一个.catch()管住整条链异步结果成了一等公民——你可以把 Promise 存到变量里、传给函数、组合起来但 Promise 也有自己的坑。Promise 是一次性的一个 Promise 只能 resolve 或 reject 一次。它解决不了持续产生数据的场景——比如 WebSocket 推送、实时日志流。后面这类场景得用 StreamPromise 管不了。组合多个 Promise 很别扭三个互不依赖的异步操作你想并行执行const[a,b,c]awaitPromise.all([fetchA(),fetchB(),fetchC()]);如果是条件分支呢“A 成功了再决定要不要调 B”——.then()链就开始变得尴尬了。你不得不在.then()里套.then()又回到了嵌套的老路。静默失败早期 Promise 如果被 reject 了但没人.catch()错误就消失了。程序看起来运行正常实际上数据已经丢了。后来浏览器和 Node 加了unhandledrejection事件才勉强能监控到。类型分裂有了 PromiseAPI 签名分裂成两套同步版本和异步版本。// 同步版functiongetConfig(){return{theme:dark};}// 异步版从远程加载functiongetConfig(){returnPromise.resolve({theme:dark});}调用方必须适配异步版本。看起来小事但当生态里每个库都有自己的 async/sync 两套 API 时维护成本就上去了。async/await——看起来完美了async/await 让异步代码看起来像同步代码。asyncfunctionloadDashboard(userId){constuserawaitgetUser(userId);constordersawaitgetOrders(user.id);constrecommendationsawaitgetRecommendations(user.id);returnrender(user,orders,recommendations);}变量可以直接绑定不用在.then()回调里传值错误用try/catch处理跟同步代码一样代码从上往下读直觉上很舒服但它引入了三个更隐蔽的结构性问题。问题一函数染色Function Coloringasync/await 带来了一个根本性的分裂函数变成了两种颜色。普通函数白色可以在任何地方调用async 函数红色只能在另一个 async 函数里await或者用.then()调functionsayHello(){// 普通函数白色console.log(Hello);}asyncfunctionfetchData(){// async 函数红色returnfetch(/api/data);}// 白色函数里不能直接 await 红色函数functionmain(){constdataawaitfetchData();// 报错await 只能在 async 函数里用}当你的程序深处把一个同步操作改成异步比如从读缓存改成调 HTTP 接口调用链上所有函数都要改成 async。一个改动可能传染到几十上百个函数签名。问题二并行陷阱async/await 最大的陷阱它让你以为代码是并行的但实际上是串行的。asyncfunctionloadDashboard(userId){constuserawaitgetUser(userId);// 1 秒constordersawaitgetOrders(user.id);// 1 秒但它在等 getUser 完成constrecommendationsawaitgetRecommendations(user.id);// 1 秒又在等returnrender(user,orders,recommendations);// 总共 3 秒}orders和recommendations互不依赖完全可以同时发请求。但await的写法把它们变成了串行。你得主动打破像同步代码一样的幻觉才能恢复并行asyncfunctionloadDashboard(userId){constuserawaitgetUser(userId);const[orders,recommendations]awaitPromise.all([getOrders(user.id),getRecommendations(user.id),]);returnrender(user,orders,recommendations);// 总共 2 秒}你不得不放弃 async/await 的舒服写法来恢复性能。代码写得越舒服性能越差。问题三Futurelocks——暂停的锁这是 Rust 等语言里暴露出来的问题一个 async 函数持有锁但它暂停了等待 I/O其他任务就拿不到这个锁。// 伪代码asyncfnprocess(shared:MutexData){letguardshared.lock().await;// 拿到锁letdatafetch_remote().await;// 暂停等待网络// guard 还拿着锁其他任务全卡住了use(guard,data);}线程模型下持有锁的线程被挂起时操作系统会调度其他线程——但锁还是它的。async/await 里一个 future 暂停时别的 future 根本没机会被轮询所以锁永远拿不到。另一些人的选择不要 async/await意识到函数染色的负担后一些语言干脆拒绝了 async/await。Gogoroutinegofunc(){data,_:http.Get(url)// 处理数据}()所有函数签名都一样不需要标记 sync 还是 async。goroutine 是用户态的轻量级线程调度器自己管理。写代码的时候没有任何颜色区分。Java 21虚拟线程Thread.startVirtualThread(()-{vardatahttpClient.send(request);// 看起来是阻塞调用process(data);});虚拟线程也是用户态线程。代码看起来是阻塞的但运行时在 I/O 时会自动挂起、切换。函数签名不需要改变。Zig显式 I/O 参数fn fetchData(allocator: Allocator, io: *IOContext) ![]u8 { return io.fetch(/api/data); }Zig 不搞 async/await。异步还是同步取决于你传进去的 I/O 上下文。函数本身不需要被染色。回头看异步编程走了四步每一步都解决了上一步最严重的问题同时制造了一个新的线程 → 太重撑不住并发 回调 → 代码没法读 Promise → 组合困难、类型分裂 async/await → 函数染色、并行陷阱、Futurelocks核心问题是我们一直在问怎么管理并发执行“而不是为什么并发执行需要被特殊管理”每个抽象层都让写单个异步函数变得更舒服但让整个系统的结构变得更复杂。团队要管理分裂的生态、重复的库、手动分析哪些操作可以并行、处理全新的死锁类型。Go、Java 虚拟线程、Zig 的选择说明了一种可能如果运行时自己解决了并发问题开发者就不需要被异步语法绑架。实践建议如果你正在用 async/awaitJavaScript、Python、Rust这些是实际项目中最容易踩的坑1. 用性能测试工具看串行点// 看着像并行实际是串行constuserawaitgetUser(id);constordersawaitgetOrders(id);用Promise.all包装独立请求但别过度——有依赖关系的必须串行。2. 永远加全局 unhandled rejection 处理process.on(unhandledRejection,(reason){console.error(Unhandled rejection:,reason);});Promise 被 reject 但没人 catch 的时候你至少能知道。3. 设计 API 时尽量减少 async/sync 分裂如果一个函数今天同步、明天可能变异步直接一开始就返回 Promise。调用方不需要因为你改了实现而改签名。4. 拿锁时不要 await// 错误拿着锁等 I/Oconstlockawaitmutex.acquire();constdataawaitfetch(/api/data);// 其他任务全卡住mutex.release(lock);// 正确先拿数据再拿锁constdataawaitfetch(/api/data);constlockawaitmutex.acquire();state.update(data);mutex.release(lock);异步编程不是技术问题是认知问题。你在写的代码看起来像什么取决于你选择了哪个抽象层。选择之前想清楚你愿意为这个舒服付出什么代价。