Java virtual thread 访问连接池时并发上限怎么设

如果一批请求都由 Java virtual thread 承载，数据库并发上限仍然不应按虚拟线程数量设置。更稳妥的做法是：让虚拟线程按任务创建，把连接池的 maximumPoolSize 当作数据库连接的第一道硬边界；只有还要保护其他共享资源，或需要给某类请求单独配额时，再增加 Semaphore。

先分清虚拟线程上限和连接池上限

最容易混淆的是把“可以创建很多虚拟线程”理解成“数据库也可以同时处理很多请求”。虚拟线程在阻塞 I/O 时可以让出底层载体线程，因此适合一请求一线程的同步写法；但 JDBC 查询仍要等待一个真实的数据库连接。

例如，应用可以用 Executors.newVirtualThreadPerTaskExecutor() 为每个任务创建虚拟线程。这个执行器的任务数不是数据库配额，连接资源仍由 DataSource 和连接池决定。不要再创建一个固定大小的平台线程池，把它误当成虚拟线程限流器。

用连接池的 maximumPoolSize 作为第一道边界

如果问题只有“数据库连接不能超过多少”，先不要叠加信号量。以 HikariCP 为例，maximumPoolSize 包含空闲和使用中的连接，池达到上限且没有空闲连接时，getConnection() 会等待到 connectionTimeout。这已经是一个资源闸门。

HikariConfig config = new HikariConfig();
config.setJdbcUrl(jdbcUrl);
config.setUsername(username);
config.setPassword(password);
// 这个值是单个应用实例的连接上限，不是虚拟线程数量。
config.setMaximumPoolSize(16);
// 连接池排队过久就失败，避免请求无限等待。
config.setConnectionTimeout(2000);
HikariDataSource dataSource = new HikariDataSource(config);

示例里的 16 只是演示配置，不是通用答案。实际预算至少要拆成：数据库允许给该服务的连接数、应用实例数量、其他服务共享的连接数，以及一个事务同时持有的连接数。多实例部署时，不能每台都照抄同一个池大小后再把总连接数相加。

需要更早限流时再加 Semaphore

当数据库池已经是唯一稀缺资源时，额外的 Semaphore 往往只是制造第二个排队点。它有价值的场景是：报表查询不能占满在线请求的连接，或者一次业务还要同时消耗外部 API 配额、文件句柄等资源。

private final Semaphore reportSlots = new Semaphore(8, true);

public Report loadReport() throws InterruptedException {
    // 只限制报表这类昂贵任务，在线查询仍可使用池中其他连接。
    if (!reportSlots.tryAcquire(1500, TimeUnit.MILLISECONDS)) {
        throw new RejectedExecutionException("报表并发配额已用尽");
    }
    try {
        // 进入许可范围后再借连接，避免拿着连接等待应用配额。
        try (Connection connection = dataSource.getConnection()) {
            return queryReport(connection);
        }
    } finally {
        // 无论查询成功、异常还是中断，都必须归还许可。
        reportSlots.release();
    }
}

这里的 8 应小于或等于你愿意给报表使用的配额，并且要留意“先获取什么、后获取什么”。如果先拿了连接再等信号量，连接会被闲置占用；如果多个资源存在不同获取顺序，还要检查是否可能互相等待。只限制数据库连接时，让连接池自己排队通常更简单。

把连接等待和业务耗时分开观察

调参时不要只盯着虚拟线程数量。至少区分三段时间：等待 Semaphore 的时间、从 getConnection() 开始到拿到连接的时间、真正执行 SQL 的时间。第一段持续变长，说明应用配额可能太小；第二段变长且 active connections 接近池上限，说明池或数据库是瓶颈；第三段变长，则应回到 SQL、锁和数据库负载排查。

HikariCP 的观测项可以帮助确认这个判断：active connections、idle connections、total connections 和 threads awaiting connection 分别说明正在使用、空闲、总量和等待借连接的线程。不要把“等待连接线程多”直接解释成虚拟线程不够。

用小步压测确认最终值

先固定查询类型、事务边界和每个应用实例数量，再逐步改变 maximumPoolSize。记录吞吐、P95/P99 延迟、连接获取超时、事务持有时长以及数据库 CPU/锁等待；如果池从 16 调到 32 后吞吐不再提升而等待和数据库负载上升，就没有继续放大的理由。

只有当某个请求类别会挤占其他请求，或者外部资源也有独立配额时，才逐步加入 Semaphore 并比较它的等待时间。最终配置应该表达资源预算，而不是表达虚拟线程的总数。先把连接池作为第一道边界，再用指标决定是否需要第二道边界，通常是最容易解释和回滚的方案。

常见问题

虚拟线程数量是不是应该等于 maximumPoolSize？

不是。虚拟线程可以多于连接池，超出的任务在借连接处等待；两者只有在单任务都必须立即占用一个连接且没有其他等待资源时才会表现出相近的活跃数量。

连接池已经限制连接数，还需要 Semaphore 吗？

只控制数据库连接时通常不需要。若要给报表、批处理或某个租户单独配额，或者还要保护其他资源，才考虑增加独立信号量。

connectionTimeout 越小越好吗？

不一定。它应覆盖正常的短暂排队和网络抖动，同时避免请求无界等待。要结合业务超时、重试策略和数据库执行时间一起设定。