IO 密集型服务线程池：核心数×2 还是 ×100，还是干脆上虚拟线程？——你们线上到底怎么选、踩过什么坑？

【背景】

做了 8 年性能优化，从 JDK 8 一路跟到 JDK 21，线程池这块我踩过的坑够写一本书。但最近半年发现一个很尴尬的现象：团队里关于「线程池到底开多大」的共识，基本是靠老员工口口相传，没有任何数据支撑。

举几个我真实经历过的场景：

• 某支付网关，4C8G，800 QPS，核心逻辑是 3 次 DB 查询 + 2 次下游 RPC。最初线程池 200，P99 稳定在 85ms。后来有人按「IO 密集型 = 核心数×N」把池子拉到 800，结果 P99 反而飙到 210ms——DB 连接池（HikariCP max=50）先打满了，大量线程排队等连接，上下文切换风暴。
• 某商品搜索服务，16C64G，接了 5 个下游（ES、Redis、推荐服务、风控、库存），单请求扇出 5 路并行。用传统线程池 500，高峰期线程栈 500×1MB = 500MB 纯栈内存，GC 压力肉眼可见。
• 去年切了 JDK 21 虚拟线程（Loom），一个订单聚合服务（10 路并行 IO）从 200 线程池直接换成虚拟线程，内存从 2GB 降到 600MB，P99 从 120ms 降到 78ms。但同一个服务里有一段 CPU 密集的加密校验逻辑，虚拟线程跑起来反而比平台线程慢 15%——pinning 问题。

【常见分歧 / 几种做法】

我观察下来，团队里大概分四派：

1. 保守派：核心数×2 或 ×4，够用就行，线程越少越可控。代表观点：「线程池开大了就是给自己埋雷，上下文切换和栈内存都是成本。」
2. 激进度量派：IO 密集就核心数×100 甚至 ×200，反正线程在等 IO，多开不亏。代表观点：「IO 等待时间 >> CPU 执行时间，线程越多吞吐越高。」
3. 虚拟线程派：JDK 21 都出了还纠结线程池大小？直接 Loom，一请求一线程，代码写起来和同步一样简单。代表观点：「线程池大小是个伪命题，虚拟线程把并发模型拉平了。」
4. 全异步派：上 WebFlux + R2DBC + Reactor，彻底告别线程池。代表观点：「同步模型本身就是瓶颈，异步才是终局。」

【我的倾向与理由】

我的结论是：线程池大小从来不是核心问题，瓶颈定位才是。但「怎么快速找到瓶颈」这件事，虚拟线程确实改变了游戏规则。

具体来说：

• 如果瓶颈在下游（DB / RPC），线程池大小只是「排队深度」的代理指标，真正该调的是下游连接池、超时、并发上限。
• 如果瓶颈在 CPU（加密、序列化、压缩），线程开再多也白搭，该做的是算法优化或加机器。
• 虚拟线程解决了「线程栈内存」和「并发模型复杂度」两个老问题，但不解决下游容量问题——你把 500 个平台线程换成 50000 个虚拟线程，下游 DB 连接池还是 50 个，该排队还是排队。
• 全异步（Reactor）在「单进程内扇出多路 IO」的场景下确实优雅，但跨服务调用链一旦有同步阻塞（比如某个 SDK 内部用了 synchronized），整条链路就退化回线程池模型，而且调试复杂度指数级上升。

所以我的实操建议是：先 profile 找到真正的瓶颈（async-profiler 火焰图 + HikariCP pending 指标 + 下游 RT 分布），再决定是调池子、调下游、还是换并发模型。不要一上来就纠结「开多少线程」。

【想听大家聊的】

1. 你们线上 IO 密集型服务（5+ 路并行下游调用）的线程池到底怎么定的？有没有量化依据，还是拍脑袋？
2. 切虚拟线程（JDK 21 Loom）的实际体验：pinning 问题你们怎么绕的？有没有遇到第三方库不兼容的情况？
3. 全异步（WebFlux/R2DBC）你们真上了吗？上线后性能收益 vs 开发维护成本，ROI 怎么算的？
4. 如果让你给一个「800 QPS、10 路并行 IO、4C8G」的服务做并发模型选型，你的第一选择是什么？