Java 虚拟线程连接池改造的资源边界

把 Java 服务从固定平台线程池迁移到虚拟线程时，最容易犯的错误，是把“能同时挂起更多任务”理解成“数据库也能同时处理更多请求”。我的结论是：虚拟线程可以替换承载请求的工作线程池，但不能替换数据库连接池。前者解决任务等待时的平台线程占用，后者约束真实、昂贵且数量有限的外部连接。

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

先把两种“池”拆开：任务调度与稀缺资源

传统服务常把固定线程池同时当成执行器和隐式限流器。线程数较小时，进入 JDBC 的任务自然不会太多；换成虚拟线程后，这个偶然形成的限制消失了。Oracle 的虚拟线程指南明确说明，虚拟线程适合大量主要等待阻塞 I/O 的任务，而且它们提供的是规模与吞吐能力，不是更低的单次延迟。

因此，改造前要把两个概念拆开：虚拟线程代表一个并发任务，数据库连接代表一个外部资源租约。任务可以很多，租约必须受控。Executors.newVirtualThreadPerTaskExecutor() 每提交一个任务就启动一个新的虚拟线程，它并不是一个复用虚拟线程的线程池。

模式：每任务一个虚拟线程，连接按需借用

迁移的主路径并不复杂：保留同步、阻塞、易读的业务代码，把任务执行器换成每任务一个虚拟线程；进入 DAO 时再从 DataSource 借连接，并在最小作用域内关闭。虚拟线程等待 JDBC I/O 时通常可以释放载体线程，但它仍然占着已经借到的数据库连接，所以连接生命周期越短越好。

public final class OrderQueries {
    private final DataSource dataSource;

    public OrderQueries(DataSource dataSource) {
        this.dataSource = dataSource;
    }

    public Optional findState(long orderId) throws SQLException {
        String sql = "select state from orders where id = ?";

        // 连接、语句和结果集都限制在一次查询的最小作用域内。
        try (Connection connection = dataSource.getConnection();
             PreparedStatement statement = connection.prepareStatement(sql)) {
            statement.setLong(1, orderId);
            try (ResultSet result = statement.executeQuery()) {
                return result.next()
                        ? Optional.of(result.getString("state"))
                        : Optional.empty();
            }
        }
    }
}

如果一个请求要并发查询多个彼此独立的数据源，可以在请求作用域内创建虚拟线程执行器。ExecutorService.close() 会等待已提交任务结束，因此应让这个作用域与业务扇出保持一致，不要把它当成全局固定大小的工作池。

public OrderView loadView(long orderId) throws Exception {
    // 执行器为每个子任务创建独立虚拟线程，不复用固定数量的工作线程。
    try (var executor = Executors.newVirtualThreadPerTaskExecutor()) {
        Future order = executor.submit(() -> orderDao.load(orderId));
        Future> items = executor.submit(() -> itemDao.list(orderId));
        return new OrderView(order.get(), items.get());
    }
}

压力：等待连接的任务会变多

固定平台线程池被移除后，应用可以快速创建大量虚拟线程。数据库连接池容量没有变化，多出的任务会在 getConnection() 附近等待。等待本身不一定是错误：虚拟线程正适合表达这种阻塞；真正的风险是等待没有上限、请求已超时但工作仍继续，或者连接一借出就被长事务和外部调用占住。

连接池大小不应照搬原工作线程数，也不应跟虚拟线程数量相等。它应由数据库可承受并发、查询特征、事务时长以及同库其他应用的配额共同决定。迁移时先保持经过验证的连接池上限，再观察连接获取等待时间、活跃连接、超时数量和数据库负载，逐步调整。

反模式：用小虚拟线程池恢复旧式限流

一个常见回退方案是创建“固定数量的虚拟线程池”，希望既使用虚拟线程又维持旧线程数。这个设计把任务身份和资源配额重新绑在一起，失去了每任务一个线程的简单模型。官方采用指南的建议是不要池化虚拟线程；若某个操作必须限制并发，应使用专门表达许可数量的机制。

另一个反模式是先借数据库连接，再等待远程 HTTP、消息队列或其他慢资源。这样即使虚拟线程挂起成本很低，连接仍被占用。更合理的边界是先完成不依赖数据库连接的外部调用，最后在短事务中读写数据库；必须跨资源协调时，则要明确事务和补偿策略，而不是靠长时间持有连接维持表面原子性。

把背压放在连接获取之前

数据库连接池已经是最后一道硬边界，但只依赖它会让大量请求堆在连接获取点。若业务需要更早拒绝、分级或隔离，可以在提交数据库操作前加 Semaphore。许可数量表达“允许多少个此类操作进入连接竞争”，而不是表达“系统只能有多少个虚拟线程”。

public final class BoundedOrderService {
    private final Semaphore databasePermits;
    private final OrderQueries queries;

    public BoundedOrderService(int maxInFlight, OrderQueries queries) {
        // 许可数来自下游容量预算，而不是虚拟线程数量。
        this.databasePermits = new Semaphore(maxInFlight);
        this.queries = queries;
    }

    public Optional findState(long orderId)
            throws SQLException, InterruptedException, TimeoutException {
        // 有界等待让过载能够向调用方显式反馈。
        if (!databasePermits.tryAcquire(200, TimeUnit.MILLISECONDS)) {
            throw new TimeoutException("database admission timeout");
        }
        try {
            return queries.findState(orderId);
        } finally {
            // 无论查询成功还是抛错，都必须归还许可。
            databasePermits.release();
        }
    }
}

示例中的 200 毫秒只是展示有界等待的代码形态，不是通用推荐值。生产值应从接口剩余超时预算倒推，并与连接池自己的获取超时协调。信号量许可通常不应大于真正想放行的下游并发预算；如果连接池本身已能提供理想的等待和拒绝行为，也不必重复加一层。

后果：吞吐上限从线程池转移到真实瓶颈

这个模式的收益是架构边界更诚实：虚拟线程不再充当资源配额，数据库连接池、外部服务许可和队列容量各自承担自己的限制。阻塞式调用链仍然保持顺序代码和普通异常处理，线程转储也更容易映射到业务任务。

代价同样明确。第一，应用能产生的等待任务更多，必须控制请求截止时间、取消传播和内存占用。第二，数据库连接成为更明显的排队点，慢 SQL 和长事务会更快暴露。第三，CPU 密集任务不会因为改成虚拟线程而运行更快，仍需单独的并行度策略。第四，原来依赖固定线程池队列长度的监控需要迁移到连接获取等待、信号量等待和端到端延迟。

迁移检查清单

• 请求执行器是否改为每任务一个虚拟线程，而不是固定大小虚拟线程池？
• 数据库连接池是否保留，并且容量没有盲目跟随并发请求数放大？
• 连接获取是否有界，接口超时后能否取消后续工作？
• 连接、语句和结果集是否全部使用 try-with-resources？
• 事务中是否夹杂与数据库无关的远程等待或长时间计算？
• 是否记录连接获取等待、活跃连接、超时、慢查询和虚拟线程诊断信息？
• 是否对 CPU 密集工作保留独立的并行度控制？

相关问题

用了虚拟线程后还需要数据库连接池吗？

需要。虚拟线程降低的是等待任务占用平台线程的成本，数据库连接仍是有限的网络、会话和数据库执行资源，需要池化、复用和限制。

连接池大小应该等于虚拟线程数吗？

不应该。虚拟线程数对应并发任务数，连接池大小对应数据库容量预算，两者没有一一映射关系。大量虚拟线程可以等待少量连接，只是等待必须有超时和过载策略。

虚拟线程能让单次 JDBC 查询更快吗？

不能直接做到。虚拟线程主要改善大量阻塞任务的并发承载和代码模型，不会缩短 SQL 执行、网络往返或锁等待本身。