虚拟线程绝不可池化，因其是轻量级任务执行载体，创建销毁开销近乎为零，池化反而破坏JVM协作调度、降低吞吐；应直接使用newVirtualThreadPerTaskExecutor()，避免ThreadLocal和旧线程池适配。
虚拟线程不是线程池的“可复用单元”
官方明确说 VirtualThread 永远不该被池化，这不是性能建议，而是模型层面的否定。传统线程池把 Thread 当作昂贵资源反复调度，而虚拟线程的创建/销毁开销近乎为零——它不绑定 OS 线程，也不需要栈空间预分配（默认 1MB → 实际按需增长，通常几 KB）。你池化一个几乎免费的对象，就像给一次性纸杯装上锁扣、编号、归还流程。
常见错误现象：
- 用
Executors.newThreadPerTaskExecutor()或自定义ForkJoinPool包裹虚拟线程，误以为“更可控” - 把
ThreadLocal直接搬进虚拟线程任务里，结果上下文泄漏或值错乱 - 在 Spring 的
@Async中强行注入虚拟线程Executor，却没改掉拦截器里的线程上下文传递逻辑
它本质是“任务的轻量执行载体”，不是“执行者”
虚拟线程的设计目标是让每个任务拥有专属的、隔离的、可挂起/恢复的执行上下文。JVM 调度器（基于 ForkJoinPool.commonPool()）会在 I/O 阻塞点自动挂起该虚拟线程，并立刻唤醒另一个待命的虚拟线程继续跑——这个过程对开发者透明，也无需你手动管理生命周期。
所以它的定位是：
-
Runnable/Callable的自然延伸：写同步代码，交由 JVM 自动并发化 - 不是
ThreadPoolExecutor的替代品，而是绕过“线程复用”这一整套抽象 - 不承担资源复用职责，只承担“一次任务 + 一次上下文”的语义保证
为什么池化反而破坏调度效率？
当你把虚拟线程塞进池子，就等于强制它脱离 JVM 的协作式调度体系。例如：
- 池中虚拟线程空闲时仍被
ForkJoinPool视为“活跃任务”，干扰工作窃取逻辑 - 阻塞操作（如
Thread.sleep()、Object.wait()）在池化后可能无法被及时挂起，导致底层平台线程被长期占用 - 监控工具（如 JFR）看到的是“大量虚拟线程处于 TIMED_WAITING”，但实际它们根本没在干活——只是被池子卡住了
真实场景中，用 Executors.newVirtualThreadPerTaskExecutor() 启动 10 万次 HTTP 调用，JVM 只会调度约 20–50 个平台线程；若用池化方式模拟，反而可能因排队、争用和虚假活跃态拖慢整体吞吐。
真正该关注的不是“怎么池”，而是“怎么退”
虚拟线程不是银弹。它在 CPU 密集型任务中毫无优势，甚至因频繁挂起/恢复带来额外开销。它的价值边界非常清晰：
- 适合：Servlet 容器请求处理、RPC 客户端调用、数据库连接池上的单次查询（配合
CompletableFuture+unpark回调） - 不适合：并行流（
parallelStream()）、矩阵计算、图像编码等纯计算任务 - 必须做：设置全局未捕获异常处理器（
Thread.setUncaughtExceptionHandler()），否则异常静默丢失 - 必须关：
ExecutorService实例要用try-with-resources或显式close()，否则底层ForkJoinPool不释放，内存缓慢泄漏
别想着“改造旧线程池”，先确认你的任务是不是真的 I/O-bound；如果是，直接用 newVirtualThreadPerTaskExecutor()，然后删掉所有 ThreadLocal 和线程池配置——这才是虚拟线程想让你做的事。
