Virtual Threads在Spring WebFlux中的性能价值、用法及代码规范问询

一、在Spring WebFlux中使用虚拟线程是否有性能提升意义？能获得增益吗？ #

• 先明确核心逻辑：Spring WebFlux的核心是非阻塞事件驱动，靠少量内核线程处理高并发；而虚拟线程是为了让阻塞代码的并发实现更简单，用同步写法就能获得近似异步的性能。
• 能获得性能增益的场景：当你的WebFlux应用存在大量阻塞操作（比如调用阻塞JDBC、同步第三方接口），用虚拟线程包裹这些逻辑，可避免内核线程被占满，提升系统并发能力。因为虚拟线程阻塞时会自动挂起，不会占用内核线程资源，WebFlux的事件循环线程就能处理更多其他请求。
• 无增益甚至反效果的场景：如果你的WebFlux已经全是非阻塞代码（比如用R2DBC、非阻塞客户端），引入虚拟线程意义不大，反而会增加上下文切换开销，不如原生WebFlux性能。
• 你提到的“标准Spring Boot（配虚拟线程）优于WebFlux”的测试，大概率是测试场景里有大量阻塞操作——此时虚拟线程让同步Spring Boot的并发能力暴涨，而WebFlux如果还是用传统方式处理阻塞逻辑，自然比不过。

二、使用虚拟线程会产生阻塞操作吗？ #

• 虚拟线程不会消除阻塞，阻塞行为依然存在，只是虚拟线程的阻塞不会占用内核线程。比如你的doBlockOperation()如果是阻塞的，虚拟线程执行它时还是会阻塞，但JVM会把这个虚拟线程挂起，释放对应的内核线程去处理其他虚拟线程。
• 关键提醒：绝对不能在WebFlux的事件循环线程（比如Netty的EventLoop）里直接调用阻塞方法，这会卡死整个事件循环；用虚拟线程包裹阻塞逻辑，就是把阻塞逻辑转移到虚拟线程中执行，避免影响事件循环。

三、如何在Spring WebFlux中使用虚拟线程？ #

常见的几种实现方式：

• 自定义虚拟线程池 + Mono.fromFuture：就是你代码里的方式，用Executors.newVirtualThreadPerTaskExecutor()创建官方推荐的虚拟线程池，把阻塞逻辑放到CompletableFuture提交到池，再转为Mono。
• 利用Spring 6.1+的原生支持：Spring 6.1及以上版本提供了Schedulers.virtual()，可以直接用它来调度虚拟线程，写法更简洁；也可以给Bean标注@VirtualThreadScope，或给方法加@Async并指定虚拟线程池，让Spring自动用虚拟线程执行。
• Mono.fromCallable结合虚拟线程调度器：比如：

  public Mono<String> myMethod() {
      return Mono.fromCallable(() -> doBlockOperation())
                 .subscribeOn(Schedulers.virtual());
  }
  

四、你的代码是否属于良好实践？ #

• 你的代码是可行的，但有优化空间：
  1. 虚拟线程池建议用官方的Executors.newVirtualThreadPerTaskExecutor()，无需手动管理线程数量，更符合虚拟线程的设计理念。
  2. 要保证virtualPool是单例，避免重复创建池造成资源浪费。
  3. 如果你的Spring版本是6.1+，更推荐用Schedulers.virtual()替代自定义线程池，写法更简洁且无需自己维护池的生命周期。
  4. 禁忌：不要在虚拟线程里调用WebFlux非阻塞API后用block()等方式阻塞等待，这会浪费虚拟线程的优势，要保持链式调用的非阻塞风格。

内容的提问来源于stack exchange，提问作者Максим