Java 虚拟线程会把数据库连接池打满吗？并发边界这样设

问题：项目换成Java虚拟线程之后，接口的并发是不是可以随便开得很高？数据库连接池会不会先被直接打满？

结论：虚拟线程虽然让「每个阻塞任务配一个线程」的写法并发伸缩能力提升了一大截，但数据库连接、外部服务配额、CPU这些资源本身还是有明确上限。别把虚拟线程重新塞进固定线程池来做限流，直接让连接池或者专门的并发控制器负责稀缺资源的访问边界就好。

先说误区：虚拟线程多，不等于数据库连接多

虚拟线程遇到标准Java I/O操作等待时会自动挂起，让出底层的平台线程去处理其他处于就绪状态的虚拟线程，天生适配高并发阻塞场景。但数据库连接是实打实的稀缺硬资源：连接池的可用连接总数是提前配置好的，超出容量的请求还是得排队等连接归还。

所以线上碰到「总线程数很高、CPU占用率不高、获取数据库连接变慢」的情况，优先排查连接池等待队列积压、慢查询和事务执行时长，不要盲目往大调虚拟线程的总数量。

正确做法：每个任务一个虚拟线程，不要给它再套线程池

OpenJDK 的 JEP 444 和 Oracle 的虚拟线程指南都明确提过：虚拟线程本身创建成本极低，完全没必要像之前用平台线程那样，塞进可复用的固定线程池里。要是你直接把原来的固定大小平台线程池，原封不动替换成同容量的虚拟线程池，根本发挥不出虚拟线程的核心优势。

// 为每个订单查询任务创建一个虚拟线程。
// 任务结束后关闭对应的任务管理对象，等待已提交任务收尾。

这个模式的本质就是「一个并发任务对应一个虚拟线程」。它从来没有承诺过下游的数据库、HTTP服务或者文件存储系统能扛住任意并发，这些资源的访问还是要单独配置访问配额。

数据库场景：先相信连接池的限制

连接池的本职工作就是复用开销极高的物理连接，在连接被全部占用的时候，让后续请求自动排队等待。Oracle 的 JDK 26 指南明确指出，配置了最大连接数的数据库连接池本身就相当于一个 Semaphore；要是你在连接池外面再加一层重复的限流逻辑，反而会出现两套独立的排队队列，后续排查超时、排队相关的异常时，链路梳理起来会麻烦很多。

日常排查可以按这个顺序走：

1. 确认连接池最大连接数、当前活跃连接数和连接获取等待时间这几个核心指标。
2. 检查事务是否执行时间过长、有没有慢查询、连接用完之后有没有正确归还。
3. 为获取连接和数据库调用设置合理的超时时间。
4. 根据数据库实际承载能力和压测结果调整池大小，不要照着虚拟线程总数量反向推算配置值。

什么时候用 Semaphore

当你要保护的资源不在连接池覆盖范围内，比如只能扛少量并发的第三方接口、有调用限额的文件转换服务或是开销很高的批处理能力，用 Semaphore 做限流，比拿线程池当限流器的写法要清晰很多。

private final Semaphore vendorBudget = new Semaphore(20);

String callVendor(Request request) throws Exception {
    vendorBudget.acquire();
    try {
        return client.call(request);
    } finally {
        vendorBudget.release();
    }
}

配额数值要以对方服务的公开限制、压测结果或历史运行指标为依据，不要直接照搬示例数值。还要配套做好超时、异常处理和监控埋点，不然只是把拥堵从线程池转移到信号量的等待队列里，问题还是没解决。

常见问题

虚拟线程能解决慢 SQL 吗？

不能。它只能降低I/O等待阶段的线程资源消耗，慢SQL、锁等待和连接泄漏还是会让请求大量堆积，该按常规数据库问题排查流程处理就怎么处理，靠虚拟线程绕不开这些问题。

连接池已经限制并发，还要加 Semaphore 吗？

通常没必要为同一个数据库的连接池再加一层同维度的限流逻辑。只有你要保护其他不同的外部资源，或者要在请求进入更早的环节就做快速失败、排队缓冲、流量降级时，才考虑单独加一层并发控制。

虚拟线程适合 CPU 密集计算吗？

它主要优化的是阻塞等待型任务。长时间占用CPU的密集计算操作，性能上限还是受物理核心数约束，还是要使用传统成熟的并行计算策略处理。

最后提醒

把虚拟线程当成普通的任务执行写法，把数据库连接池和外部资源配额当成独立的资源预算，职责边界就非常清晰：虚拟线程的总数量可以放开配置，但所有稀缺资源的访问必须提前设好上限。上线之前用贴近真实流量的模型做压测，验证连接等待和尾延迟表现，就能避免出现「线程很轻、系统响应反而变慢」的反效果。