高并发后端该不该「全链路异步化」：Reactor/WebFlux 上线一年，你们真的比同步 + 大线程池更快、更稳、更好维护吗？

【背景】 做了 15 年后端，从 Servlet 3.0 的 @Async 一路写到 Spring WebFlux、Project Reactor，最近又看到 Java 21 虚拟线程把「异步」重新定义了一遍。我手上现在同时维护两套服务：

• A 服务：Spring Boot 3.2 + WebFlux + R2DBC，入口 12k QPS，单副本 4C8G，P99 稳定 35ms 左右；
• B 服务：同一业务域，Spring Boot 3.2 + 传统 MVC + HikariCP 30 连接 + 线程池 200，入口 10k QPS，同规格机器，P99 42ms。

表面上看 A 比 B 好 7ms，但 A 的 oncall 频率是 B 的 2.3 倍——Reactor 的背压传导、Mono.zip 里一个分支超时把整条链拖死、R2DBC 连接池耗尽后异常栈完全不可读（"Timeout on blocking read for 20000ms" 这种），排查成本远超 B。

我越来越怀疑：对大多数 Java 后端团队来说，"全链路异步化"是一个被框架营销推着走、但工程收益并不显著的决定。 真正的瓶颈往往不在线程模型，而在连接池、下游 RT、GC、序列化这几件事上。

【常见分歧 / 几种做法】 我在不同团队见过至少四种路线，各有拥趸：

1. 全异步派：WebFlux / Reactor 从上到下一把梭，线程数压到 32，靠非阻塞扛高并发。论据：线程是稀缺资源，非阻塞才能把 1 万连接撑住。
2. 同步大池派：MVC + 线程池 200~500 + HikariCP 30，代码全同步写。论据：可读性、调试、新人上手成本，比"省几个线程"重要 10 倍。
3. 混合派：入口同步（MVC），但调下游 RPC 用异步客户端（OkHttp async / gRPC async），用 CompletableFuture 桥接。论据：拿到异步收益的 80%，付出同步代码的 20% 复杂度。
4. 虚拟线程派（Java 21+）：同步代码 + Loom，"异步"这个概念直接从 API 层消失。论据：为什么要在业务代码里管理回调？

每种说法都有道理，但我也看到每种路线的坑：

• 全异步：背压语义不统一（Reactor 的 onBackpressureBuffer 和 gRPC 的 flow control 是两套逻辑），R2DBC 异常栈几乎不可读，团队里能 debug Reactor 链的人不超过 2 个；
• 同步大池：线程数 × 连接池 × GC 暂停三者耦合，P99 抖动时你分不清是线程排队还是连接池排队还是 STW；
• 混合：CompletableFuture 的异常传播（CompletionException 包了又包）和超时传播（每个 future 都要单独 orTimeout，漏一个就悬挂）是隐形炸弹；
• 虚拟线程：synchronized 块 pin carrier thread（JDK 21 已知问题，JDK 24 有改进但还有边界 case），HikariCP 连接池在 10 万虚拟线程下行为没被充分验证。

【我的倾向与理由】 我现在的做法是 同步优先 + 瓶颈点局部异步，具体原则：

1. 线程模型不是第一优化项。先量：如果 P99 的 80% 来自下游 RT（DB / RPC），那换异步框架只会把"等 I/O 的线程"换成"等 I/O 的 event loop"，延迟不变，复杂度翻倍。真正该做的是连接池调参、查询优化、缓存、批量合并。
2. 异步只用在"扇出"场景。一次请求要并行调 5~7 个下游，这时同步代码用线程池 fan-out 会占 N 个线程，异步用 zip / allOf 确实省线程。但这是局部优化，不需要全链路异步。
3. 连接池才是真瓶颈。不管同步还是异步，HikariCP 30 连接 / R2DBC 16 连接，下游 RT 没降，线程模型换了也白搭。我见过太多团队花两周重写 Reactor，结果 P99 只降了 5ms，其中 4ms 是去掉了线程排队，1ms 是 GC 压力小——这 5ms 完全可以用连接池从 30 调到 50 + 慢查询加索引拿到。
4. 可维护性是硬约束。Reactor 链一旦超过 3 层 map/flatMap，新人接手就要读半天；同步代码的 stack trace 是平的，async 的 stack trace 是碎的。oncall 时这 10 分钟的差距累积起来是巨大的。

一句话总结：线程模型是"够用就行"的基建，不是"越先进越好"的卖点。把工程资源花在连接池、慢查询、缓存策略、超时预算上，ROI 高一个量级。

【想听大家怎么说】

• 你们线上高并发服务（>5k QPS）目前是什么线程模型？同步 / 异步 / 混合 / 虚拟线程？
• 换过框架吗？换之前和换之后的 P99、oncall 频率、新人上手周期分别是什么数据？
• 虚拟线程（Java 21+）有人真正在生产跑了吗？连接池和 I/O 框架（Netty / gRPC）的兼容性踩过什么坑？
• 你们团队"能不能写 async"的判断标准是什么？QPS 阈值？扇出比？还是纯粹看团队经验？

欢迎贴具体数据，空对空聊"async 更好"或者"sync 更好"意义不大——我想看的是：在什么负载特征、什么团队规模、什么下游拓扑下，异步的 80% 复杂度换来的那 20% 收益，到底值不值。