Java 虚拟线程怎样避免阻塞同步池化资源

把 Java 平台线程池换成虚拟线程，并不会让数据库连接、文件句柄或下游服务的容量一起变大。比较稳妥的做法是：用每任务虚拟线程承载请求，把连接池当成真正的有限资源；连接拿不到时，让虚拟线程等待，而不是继续扩大平台线程池。这样既保留同步 JDBC 代码的可读性，也不会把“线程数量”和“连接数量”混成一个上限。

一句话判断：虚拟线程负责承载任务，连接池负责限制连接；不要把虚拟线程再放入固定大小的平台线程池，也不要仅因为使用了虚拟线程就盲目放大连接池。

本文按一个常见运行手册来拆解：先分清三类资源，再调整执行器，接着收紧连接生命周期，最后用 JFR 区分载体线程被固定和连接池耗尽。

先把线程和池化资源分成两层

虚拟线程是轻量的任务载体。JDK 调度器会把它挂载到平台线程上运行；当它在 Java API 中等待阻塞 I/O 时，通常可以暂时卸载，让载体线程继续承载其他虚拟线程。这个模型解决的是“很多任务同时等待”的线程成本，不是数据库可以同时处理多少条 SQL。

因此，排障时至少要分开看四个数量：请求任务数、载体线程数、连接池中的可用连接数，以及数据库服务端能接受的并发。任务数很大而连接池较小，表现可能只是虚拟线程在等待连接；连接池被放大到超过数据库承受能力，则会变成服务端排队、锁等待或超时。

这个边界也解释了为什么“再套一层固定线程池”通常是错误修复：它把本来可以停放的虚拟线程重新压缩成有限的平台线程槽位，连接池仍然可能是原来的瓶颈。

使用每任务虚拟线程执行器，不要池化虚拟线程

JDK 21 提供了每任务虚拟线程执行器。迁移同步代码时，可以把它理解成“每个请求有自己的轻量线程”，而不是把虚拟线程当成需要复用的工作线程。执行器只负责创建和关闭任务，真正的并发上限应该由数据库、远程 API 或其他受限资源决定。

import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;

try (ExecutorService executor = Executors.newVirtualThreadPerTaskExecutor()) {
    for (long orderId : orderIds) {
        executor.submit(() -> orderService.load(orderId));
    }
    // try-with-resources 会等待任务结束并关闭执行器，避免遗留任务。
}

代码中的固定循环只是表达执行器边界，不代表生产系统可以无限提交任务。入口仍应有请求限流、队列长度、超时和取消策略；这些限制保护的是业务和下游容量，而不是为了模拟旧式线程池。

让连接池限制连接，不要限制虚拟线程数量

同步 JDBC 的关键是缩短连接借用区间：取得连接、执行必要的 SQL、读取结果、立即归还。连接池等待发生时，等待者可以是虚拟线程；连接归还后，另一个虚拟线程再获得它。不要把连接缓存到虚拟线程的长期上下文里，也不要让一个连接跨越不相关的请求。

import java.sql.Connection;
import java.sql.PreparedStatement;
import javax.sql.DataSource;

final class OrderRepository {
    private final DataSource dataSource;

    OrderRepository(DataSource dataSource) {
        this.dataSource = dataSource;
    }

    String findStatus(long orderId) throws Exception {
        String sql = "select status from orders where id = ?";
        // 连接只覆盖本次查询，离开 try 块后归还连接池。
        try (Connection connection = dataSource.getConnection();
             PreparedStatement statement = connection.prepareStatement(sql)) {
            statement.setLong(1, orderId); // 参数化查询，避免拼接输入。
            try (var result = statement.executeQuery()) {
                return result.next() ? result.getString("status") : "NOT_FOUND";
            }
        }
    }
}

如果连接池已经限制了数据库连接数，就不要再为同一件事机械增加一个 Semaphore；额外的许可器只会制造第二个排队点。只有当任务还受另一个独立配额限制，例如第三方 API 的租约数，才有理由增加独立的 Semaphore，并明确它保护的不是数据库连接。

处理同步锁与阻塞调用的组合

在 JDK 21 的维护环境里，如果连接借用或网络 I/O 被包在频繁执行的 synchronized 方法/代码块中，虚拟线程可能 pin 住载体线程，导致大量等待任务挤压在少数平台线程上。可以把外部 I/O 移到锁外；确实需要跨阻塞区间保护共享状态时，评估 ReentrantLock、更短的临界区或拆分状态更新。

JDK 24 的 JEP 491 已改善 synchronized 造成的多数 pinning，但这不等于池化资源自动扩容，也不覆盖所有 native 或外部调用。升级后仍要保留连接池耗尽、数据库慢查询和调用超时的指标，不能只看线程数下降就判定问题消失。

import java.util.concurrent.locks.ReentrantLock;

final class CacheBackedCounter {
    private final ReentrantLock lock = new ReentrantLock();
    private long value;

    void add(long delta) {
        // 只保护内存状态，不在锁内执行数据库或网络 I/O。
        lock.lock();
        try {
            value += delta;
        } finally {
            lock.unlock(); // 无论更新是否抛错都释放锁。
        }
    }
}

这里的重点不是把所有 synchronized 机械替换掉，而是识别“锁持有期间是否可能等待外部资源”。只保护内存字段的短锁通常不需要为了虚拟线程重写；长时间持锁又调用数据库，才是优先整改对象。

用 JFR 区分载体线程与连接池瓶颈

线上出现“虚拟线程很多但吞吐不升”时，按下面的顺序判断：

1. 先看连接池 active、idle、pending、借用耗时和超时数：pending 上升而数据库响应正常，优先检查连接借用区间和池大小。
2. 再看数据库端的锁等待、执行时间和连接上限：如果服务端已经排队，继续扩大虚拟线程或连接池只会放大压力。
3. 最后看 JFR 的 jdk.VirtualThreadPinned 以及载体线程栈：如果大量任务停在锁或 native 调用，才处理 pinning。

回滚也要按资源层次进行：先撤回连接池放大和额外并发，再保留每任务虚拟线程；如果问题来自特定驱动或 native 调用，临时把该路径放到受控的平台线程执行器中，并记录恢复条件，不要把整个服务退回一个巨大的固定线程池。

常见问题

虚拟线程数量是不是应该等于连接池大小？

不是。虚拟线程是任务承载，连接池是数据库资源上限。前者可以明显多于后者，关键是设置请求超时、队列和取消，避免任务无限堆积。

已经用了 JDK 24，还需要关注 pinning 吗？

需要，但关注点从普通 synchronized 阻塞转向 native、外部库和资源耗尽。JFR、连接池指标和数据库指标要一起看。

什么时候才需要 Semaphore？

当它保护的是连接池之外的独立配额，例如第三方服务租约、硬件通道或业务许可证。若只是重复限制同一个连接池，通常只会增加等待层次。

最后可以把原则记成三句：虚拟线程不池化，连接必须短借短还，有限资源只设置一个清晰的主上限。这样同步代码仍然直观，阻塞等待也不会被错误地转化成平台线程耗尽。