高并发后端该选哪种并发模型：线程池、事件循环还是虚拟线程？

【背景】 最近翻了社区几篇帖子——连接池从 200 调到 2000 反而雪崩的复盘、JDK 21 虚拟线程把 HikariCP 池打满、carrier 池大小怎么定——发现大家聊的全是「具体某个模型的参数怎么调」，但有个更上游的问题很少被正面讨论：选并发模型这件事本身，团队内部到底是怎么对齐的？

我自己在高并发后端这 8 年，见过三种团队的风格，分歧不在「对不对」，而在「优先级」：

做法 A：线程池派（thread-per-request）。 最直觉，代码就是同步写，调试友好，出问题 stack trace 直接可读。代价是 IO 等待期间线程被占着，QPS 上限被线程数锁死，而且线程是昂贵的——上下文切换、栈内存、调度抖动。这类团队通常靠「池小 + 队列 + 拒绝」来兜底。

做法 B：事件循环派（Reactor / Netty / Go 协程）。 非阻塞 + 回调/链式，单机吞吐天花板高，资源利用率好。代价是代码组织方式完全变了——同步心智模型失效，调试要抓调用链，第三方库不兼容非阻塞 IO 时容易「隐式阻塞」把整个 event loop 拖死（这个坑我见过两次，都是某个 SDK 内部偷偷用了 synchronized + 阻塞 IO）。

做法 C：虚拟线程派（JDK 21+ / Kotlin Coroutines）。 看起来「两全其美」：代码写成同步的样子，运行时自动调度。但我见过三次翻车，根因都不在「虚拟线程本身」，而在下游是阻塞的——HikariCP 连接池没跟着扩、carrier 池压到 CPU 核数后 JSON 反序列化段 P99 反升、某个同步锁把 carrier 线程 pin 住导致整个服务卡顿。换句话说，虚拟线程把「并发模型」的问题，转移成了「阻塞依赖治理」的问题，后者更难排查。

我的倾向：偏 C，但有一个前提条件——选模型之前，先量化你的 IO 等待占比和阻塞依赖数量。如果下游全是阻塞的（DB、RPC、第三方 SDK），那 C 和 A 的差别只是「谁帮你等」，真正的瓶颈在连接池、锁、carrier 池，换模型不解决问题。如果下游是非阻塞的（Redis、Kafka、gRPC），那 C 和 B 差别不大，选 C 主要是为了代码可读性。A 适合的场景其实很少——只有当你需要「强同步语义 + 简单调试」且 QPS 不高时。

【想听大家聊】

1. 你们团队选并发模型时，决策依据是什么？是「架构师拍板」、还是「压测跑一轮」、还是「哪个库生态好」？有没有「先选模型再调参数」和「先调参数再换模型」两种路径的真实对比？
2. 虚拟线程派的同学：你们怎么治理「下游阻塞」这个转移过来的问题？连接池怎么扩？carrier 池怎么定？有没有一个可复现的 checklist？
3. 事件循环派的同学：你们怎么定位「隐式阻塞」？（我个人的做法是：加一个 thread-safety 检测器 + 定期跑非阻塞 IO 审计，但成本不低）
4. 如果只能留一个指标来判断「当前并发模型是不是瓶颈」，你选什么？（我的选择是：carrier 线程的 runnable 时间占比，而不是 QPS 或 P99——聊聊看）