一个接口需要调用商品服务、库存服务和价格服务。传统线程池若为每个请求占用一个平台线程很多时间都花在等待网络响应上。虚拟线程提供了一种更轻量的“一个任务一个线程”写法让同步代码在大量阻塞 I/O 场景下更容易扩展。但它不会让数据库查询本身变快也不能把下游服务的容量变成无限。本文讨论如何使用、在哪里设限以及迁移时要排查什么。一、虚拟线程解决的是等待成本平台线程通常对应操作系统线程数量受到线程栈和系统资源约束。虚拟线程由 JVM 调度当支持的阻塞 I/O 让虚拟线程挂起时承载它的平台线程可以执行其他任务。于是我们可以继续用直观的同步调用表达业务流程而不必把每一步都拆成回调。关键收益是吞吐扩展不是单次请求的网络延迟下降。这意味着两个前提。第一任务确实经常等待 I/O长期占满 CPU 的计算不会因为换成虚拟线程而自动提速。第二业务调用链中的资源仍是有限的数据库连接数、HTTP 连接池、磁盘带宽和远端限流都没有变化。虚拟线程减少了线程等待成本但没有减少下游真实工作量。Java 21 中可以直接启动一个虚拟线程ThreadworkerThread.ofVirtual().name(lookup-1).start(()-{System.out.println(Thread.currentThread());});worker.join();对于一批有结果的任务Executors.newVirtualThreadPerTaskExecutor()更方便。执行器会为每个提交的任务创建一个虚拟线程关闭执行器时需要考虑在途任务。不要把这个 API 误读成“自带线程数量限制的池”它的任务数和虚拟线程数本身不受固定上限约束。二、一个可运行的并发查询示例下面模拟从三个独立服务读取数据。将代码保存为VirtualThreadDemo.java后用javac VirtualThreadDemo.java和java VirtualThreadDemo运行。importjava.util.List;importjava.util.concurrent.Callable;importjava.util.concurrent.ExecutorService;importjava.util.concurrent.Executors;importjava.util.concurrent.Future;publicclassVirtualThreadDemo{staticStringquery(Stringservice)throwsInterruptedException{Thread.sleep(200);// 模拟阻塞 I/O生产代码换成真实客户端returnserviceOK;}publicstaticvoidmain(String[]args)throwsException{ListCallableStringcallsList.of(()-query(product),()-query(inventory),()-query(price));try(ExecutorServiceexecutorExecutors.newVirtualThreadPerTaskExecutor()){ListFutureStringfuturesexecutor.invokeAll(calls);for(FutureStringfuture:futures){System.out.println(future.get());}}}}三个任务彼此独立所以可以并发启动invokeAll等待全部完成Future.get取得结果。真实服务中若库存查询依赖商品查询返回的仓库编号就不能把两者当成独立任务。并发只用于没有数据依赖的阶段否则代码看似并行实际会引入难以解释的中间状态。示例中的睡眠用于说明等待不是性能基准。要评估虚拟线程对业务的收益应在相同连接池、下游限流、请求混合和机器资源下比较吞吐、延迟分位数、错误率与内存。只比较“十万个空任务用了多久”结论对真实系统帮助有限。三、不要池化虚拟线程要限制稀缺资源传统平台线程昂贵因此常用固定大小的线程池限制线程数量。虚拟线程的设计目标是大量、短生命周期任务为了复用而把虚拟线程池限制在十几个可能重新引入排队却没有保护真正稀缺的资源。应对数据库连接、下游并发请求或昂贵的第三方接口分别限流。例如第三方最多允许 20 个并行请求可以使用信号量importjava.util.concurrent.Semaphore;SemaphorepermitsnewSemaphore(20);StringcallWithLimit()throwsInterruptedException{permits.acquire();try{returnremoteCall();}finally{permits.release();}}这个限额是保护下游的不是保护虚拟线程的。等待许可的任务本身也会占用一定内存因此入口仍需设置队列、请求数量或整体并发上限。无界创建虚拟线程加无限等待信号量仍可能因排队堆积耗尽内存。背压要从接入层一路传递到执行层。超时同样重要。虚拟线程可以廉价等待不意味着应该永远等待。每个外部调用需有连接超时和读取超时整个请求也需有截止时间。若客户端在超时后继续执行调用方不应把“我不再等待”误认为“下游没有处理”。对写操作尤其要设计幂等键或状态查询。四、pinning 与阻塞代码审查虚拟线程在某些情形下可能被固定在承载线程上导致平台线程无法及时转去执行其他虚拟线程。Java 21 中一个典型场景是在synchronized块内执行长时间阻塞操作。不是说synchronized一律不能用而是应避免在持锁期间做慢网络访问或文件 I/O。// 不推荐锁的范围覆盖了外部调用。synchronized(lock){updateLocalState();remoteClient.send();}更好的做法通常是缩小临界区仅保护本地共享状态再在锁外调用远端若逻辑必须跨两者维持一致性单纯更换锁也不够需要重新设计事务与补偿。对确实存在长时间阻塞且必须互斥的区域可以评估ReentrantLock并通过 JFR 或线程转储验证而不是机械地替换所有锁。线程本地变量也值得审查。虚拟线程可能数量很大在每个线程里缓存大型对象会造成可观的内存开销。请求上下文、日志追踪和安全身份应有明确的传递与清理机制不能假设线程会被复用也不要把线程当成长期存储位置。五、错误传播、取消与关闭“为每个请求开一个虚拟线程”并不自动管理子任务。提交三个查询任务后若第一个失败另外两个是否继续接口超时时是否尝试取消剩余任务结果可否部分返回这些属于业务生命周期必须明确设计。Future.get()可能抛出ExecutionException其中 cause 才是任务原始异常。记录日志时应包含任务名称和请求标识避免只打印“执行失败”。Future.cancel(true)会尝试中断任务但实际 I/O 是否响应中断取决于客户端取消后还应确认连接和其他资源是否释放。执行器的生命周期也不能随意放在静态变量里。短批次任务可用 try-with-resources长期运行服务应由应用管理统一创建与关闭并在服务停止时拒绝新任务、处理在途任务。错误处理和清理逻辑与线程类型无关虚拟线程不是资源管理的替身。六、迁移顺序和监控指标迁移现有项目时先选择阻塞 I/O 明确、依赖关系清晰的一条业务链路。检查 JDBC 驱动、HTTP 客户端、连接池与日志上下文保持下游容量和超时设置不变先做小流量试验。观察吞吐、P95/P99 延迟、CPU、连接池等待、虚拟线程数量和内存而不只看请求是否成功。如果吞吐提升后数据库连接池迅速耗尽瓶颈只是从线程池移动到了连接池。此时要根据数据库能力和业务优先级调整并发与背压不能无限扩大连接数。若延迟反而增加检查请求排队、锁范围、下游限流和对象分配情况。JDK 诊断工具可帮助查看虚拟线程状态。采集线程转储需要评估输出体积尤其在大量并发任务时。生产监控还应记录“等待许可数”和“等待连接数”它们往往比单纯的线程数量更接近故障原因。七、适用与不适用的场景请求处理、批量 I/O 查询和大量短生命周期阻塞任务是优先评估虚拟线程的场景。纯 CPU 密集计算仍受 CPU 核数约束长期常驻的后台循环则应考虑生命周期和调度成本。已经使用高质量异步客户端且性能达标的服务也没有必要为了追逐语法而立即重写。八、限流参数怎么定假设数据库连接池最多有 40 个连接当前服务还承担管理任务和其他接口不能简单把某一条查询链路的信号量也设成 40。应为关键链路预留容量再结合连接占用时间、并发高峰和数据库 CPU 测试设定初值。一次请求可能同时调用两个数据库操作两个操作可能分别占用连接如果它们还涉及其他下游就应按资源分别度量和限制而不是用一个“全局线程数”代替所有容量规划。监控时同时画出入口请求数、正在执行数、等待许可数、连接池活跃连接和等待连接数。若等待许可数先升高说明业务限流开始生效若连接池等待先升高可能是限制设得太宽、其他业务抢占连接或单次查询过慢。只看平均延迟会掩盖尾部排队应观察 P95/P99 和超时比例。针对高峰流量还要设定队列长度上限超过时快速返回可识别的繁忙响应避免请求把服务器内存耗尽。并发下的超时预算要贯穿调用链。例如接口总预算 800 毫秒商品服务已经用了 500 毫秒就不能再给库存服务一个独立的 800 毫秒等待时间。外部客户端的连接、读取和整体请求超时都需要配置取消调用后要验证驱动是否真正停止工作。写入类请求在超时后可能已经成功调用方重试必须提供幂等标识。九、迁移前后的行为测试先做基线测试保持数据集、数据库连接池、远端配额与机器规格一致记录平台线程方案的吞吐和尾延迟随后只替换执行模型比较差异。通过人为注入慢下游、连接拒绝和超时确认虚拟线程版本没有把失败放大成无限排队。尤其要测试服务停止时仍有在途请求的情况关闭执行器是否等待等待多久超过截止时间后如何处理未完成任务。应用使用线程本地变量保存日志追踪信息时要验证每个请求的写入和清理是否对称。虚拟线程数量远高于传统固定线程池错误地为每个线程缓存大型对象可能带来新的内存压力。使用 JFR 观察长时间固定承载线程的事件再定位具体锁和阻塞调用不要因为看到一个同步块就不经测量地改写整个锁体系。单次压测成功不等于生产可用迁移策略还包括回滚开关、逐步放量与故障后恢复演练。归根结底虚拟线程让“一任务一线程”的代码模型重新可行却不提供无限的数据库连接、无限的远端配额或免费的错误恢复。先识别等待再限定稀缺资源最后基于真实负载验证收益才能把新机制变成可靠的工程能力。参考资料Oracle 虚拟线程指南、Executors API、Thread API。