Java virtual thread 阻塞调用的线程池迁移

Java 阻塞调用迁移到 virtual thread，通常可以保留同步式业务代码，将任务交给每任务一个虚拟线程的执行器。但线程变轻并不意味着数据库、远程服务或内存容量同步扩大；原来由固定线程池间接限制的并发，需要重新明确。

官方文档：https://docs.oracle.com/en/java/javase/25/core/virtual-threads.html

我会先看等待时间，而不是先换所有线程池

以一个读取远程资料的服务为设计场景：任务大多等待 I/O，固定线程池排队较多，这类负载值得评估虚拟线程。本文是迁移方案说明，没有声称完成生产压测。我的判断是先区分等待型任务和长期占用 CPU 的计算任务，不把线程数增加当作算力增加。

虚拟线程正式 API 可用于 Java 21 及以后版本。本文引用 Java 25 文档，目标运行时、框架和驱动仍应按实际版本确认。迁移收益主要在并发承载，不是保证单次调用更快。

执行器按任务创建线程，调用方式仍可同步

newVirtualThreadPerTaskExecutor 为每个任务启动虚拟线程，不是固定大小的工作线程复用池。我不建议为了延续旧配置，就再把虚拟线程装进固定数量的池。应直接表达业务任务，并单独表达受限资源。

下面是供读者接入的原创类片段。执行器与资源许可由调用方在服务生命周期管理；下游 Callable 需要自行配置连接和读取等超时。16 是示例并发上限，不能直接当成生产建议。

import java.util.concurrent.*;

final class BlockingTasks {
    private final ExecutorService executor;
    private final Semaphore permits = new Semaphore(16);

    BlockingTasks(ExecutorService executor) {
        this.executor = executor;
    }

     Future submit(Callable downstream) {
        // 入站另设总量限制，避免无限积累等待许可的任务。
        return executor.submit(() -> {
            permits.acquire();
            try {
                // 只限制当前实例的下游调用并发。
                return downstream.call();
            } finally {
                // 仅在成功获取许可后进入此finally。
                permits.release();
            }
        });
    }
}

调用方以 Executors.newVirtualThreadPerTaskExecutor() 创建并共享执行器，初始化 BlockingTasks 一次，在服务停止时关闭执行器。不要每次请求重新构造这个类，否则每个实例都有自己的16份许可，无法形成服务级限制。多个服务实例的总并发还需要另行考虑。

把旧线程池承担的限制逐项找出来

Semaphore 约束正在访问下游的任务数，但不约束已经提交、正在等待许可的任务总数。我的取舍是同时保留入口准入、下游超时及合理的请求规模限制，而不是只加一个信号量就认为系统不会过载。

调用方用 Future.get 观察结果；任务抛出的异常通过 ExecutionException 暴露，不能提交后丢弃 Future。取消时需检查下游是否响应中断，不能把 cancel(true) 当成外部操作已回滚的证明。请求超时与执行器关闭也不是同一件事。

兼容、上下文与关闭值得单独安排

我会检查代码是否依赖线程池里的 ThreadLocal 来缓存昂贵资源。每任务线程模式下，这种缓存的数量可能随任务数增长，应该重新评估资源归属。事务、日志上下文以及框架执行模型也需要保留原有语义。

停止服务时先停止接收新任务，再按停机策略等待或取消已提交任务。执行器 close 的等待语义不等于一个固定时限；不能在每次请求里创建执行器，再以为请求超时后关闭操作一定立即返回。

评估时可以对照吞吐、尾延迟、等待任务量、连接池占用与堆内存。这里列的是读者可采用的观察项，不是本文已经测得的指标。若主要瓶颈是 CPU 或下游配额，换执行器可能不会解决它。

常见问题

能直接删除连接池吗？不能。线程轻量化不改变连接资源约束。

旧代码使用 synchronized 就一定要改吗？不能脱离 JDK 版本和实际阻塞行为一概而论，应查目标运行时资料并观察热点，本文不把旧版限制套到所有版本。

什么时候更适合小步迁移？已有大量线程上下文依赖、第三方驱动行为不清楚时，先选择一个清晰的阻塞调用边界，更容易解释问题和恢复旧配置。接口语义见Executors 官方 API。