面经策

虚拟线程适合什么场景？哪些场景下应该继续用平台线程？ ​

  • 标签：Java、新特性

🏛 业务架构师 ​

虚拟线程的场景选择，我按"瓶颈在哪"判断：

适合虚拟线程的场景（IO 密集型）：

  • HTTP 服务/微服务网关：大量请求在等下游响应；
  • 外部 API 聚合调用：调第三方支付、物流、风控接口的服务；
  • 数据库访问为主的应用（配合连接池扩容）；
  • 消息消费、爬虫、文件轮询类批处理；
  • 特征：单请求 CPU 时间短、等待时间长——线程数是吞吐瓶颈的业务。

应继续用平台线程的场景：

  1. CPU 密集型：编解码、加解密、大数据计算——虚拟线程不会凭空创造 CPU，线程池大小≈核数才是正解；
  2. 有 Pinning（钉住）风险的老代码：synchronized 块内执行 IO、老版本 native 调用（JDK 24 前 synchronized 会 pin 住载体线程）——先改 ReentrantLock 或等 JDK 24 的修复；
  3. 依赖 ThreadLocal 重缓存大对象的组件：百万虚拟线程×每线程大对象=内存爆炸（见注意事项题）；
  4. 低并发内部工具：百级并发的服务用平台线程毫无压力，改造无收益。

我的落地节奏：新服务（Java 21+Spring Boot 3.2+）默认开虚拟线程；存量服务按"IO 等待占比×并发压力"排序改造——压测验证收益再上生产。一句话：虚拟线程解决的是"IO 等待贵"，不是"计算不够快"，场景错配就白忙一场。

🏗 系统架构师 ​

选型判据一句话：等 I/O 的用虚拟线程，烧 CPU 的用平台线程。

虚拟线程适合：

  • 高并发 I/O 密集服务：Web 后端（每请求一线程，Tomcat/Spring Boot 已支持）、RPC 客户端扇出、爬虫、消息消费（等待型消费者）——下游是 DB/HTTP/中间件，线程大量时间在"等"；
  • 百万级长连接/任务：推送、WebSocket、批处理的并行子任务编排；
  • 需要简单同步代码的场景：替代 CompletableFuture 链/响应式（Reactor）编写的可维护性泥潭——虚拟线程最大的工程价值是"异步性能 + 同步可读性"；
  • 结构化并发（见专题）下的并发子任务。

继续用平台线程（或不用线程）的场景：

  • CPU 密集计算：编解码、加解密、大数据处理——核数是硬上限，虚拟线程无增益（还多了调度开销），用平台线程池（大小 ≈ 核数）、parallel stream/ForkJoin；
  • 需要长期稳定的后台守护线程：调度器、心跳、事件循环——数量少生命周期长，平台线程的确定性更合适；
  • 依赖 ThreadLocal 重缓存 + 高创建频率的场景：虚拟线程海量创建会让 ThreadLocal（每线程一份）的内存模型失效，用 ScopedValue；
  • Pinning 敏感的存量代码：重 synchronized 的库无法快速改造时（JDK 24 前的注意项）；
  • JFR/老工具链兼容：老版本 APM 对虚拟线程支持不完善的环境。

容量视角的混合架构：典型服务是"平台线程池（CPU 任务）+ 虚拟线程（请求处理）+ 消息队列（削峰）"——按负载类型分层，而不是一刀切换。

💻 全栈开发专家 ​

我的选型线：看阻塞在哪里。

虚拟线程适合（IO 密集 + 高并发）：

  • Web 服务/网关：大量请求等下游（HTTP/RPC/DB/Redis）；
  • 爬虫、消息消费、文件轮询这类「开 1 万个并发任务」的场景；
  • 典型收益：Tomcat 换虚拟线程后，阻塞型接口吞吐 2~4 倍，代码零改动。
yaml
# Spring Boot 3.2+ 的开启方式
spring:
  threads:
    virtual:
      enabled: true

继续用平台线程（CPU 密集 / 特殊约束）：

  1. CPU 密集计算：编解码、加解密、批处理——虚拟线程对计算无加速能力（核就那么多），并行还得靠平台线程池 + 合理的并行度（ForkJoinPool/parallelStream）；
  2. 长时间驻留的本地调用：JNI/本地库中阻塞的操作，JDK 拦截不到，照样钉住载体线程；
  3. 需要线程优先级/实时性控制：虚拟线程没有优先级概念；
  4. ThreadLocal 重度依赖的超大对象缓存（如每线程几十 MB 的 buffer）——虚拟线程数量巨大，ThreadLocal 内存会被放大百万倍（Java 25 有 Well-Finalizable…实际方案是换 ScopedValue）。

混合实践（真实项目）：Web 层虚拟线程接请求；计算型任务仍提交到固定大小的平台线程池（Executors.newFixedThreadPool(核数)），用 CompletableFuture 衔接——各取所长。

压测建议：开启前后用 Gatling/wrk 对比「吞吐、P99、载体线程数（JFR 看）」，别盲信理论收益——有 synchronized 老 JDBC 驱动或 ObjectInputStream 这类 pin 场景的代码，收益会打折（JDK 24 后此问题大幅缓解）。