Spring Boot 4.1 默认启用虚拟线程后，系统可能同时接收更多等待数据库的请求；但连接池若仍保持较小容量，接口超时反而会增多。我们真正关心的不是“并发翻了多少倍”，而是瓶颈是否已经从请求线程转移到了数据库连接。
这是什么
虚拟线程是 Java 21 引入的轻量级并发机制，线程等待 I/O 时不再长期占用操作系统线程，因此适合大量请求同时查库或调用外部服务。HikariCP 则是常用的数据库连接池，负责限制应用与数据库之间的并发连接数。
Spring Boot 4.1 在满足运行条件时默认启用虚拟线程，但 HikariCP 默认连接池规模仍按传统线程模型设计。结果可能是数千个请求同时排队等待约 10 个数据库连接，最终触发超时。连接池不是越大越好：全部服务使用的连接总数应控制在数据库承载能力以内；慢 SQL、缺失索引也可能让连接长期无法释放。
常见调整包括适度扩大连接池、缩短连接等待时间，以及启用延迟获取连接，让缓存命中等不必访问数据库的请求不提前占用连接。Java 21 中还存在锁钉死现象，即线程在 synchronized 锁内阻塞时无法释放载体线程；升级较新 JDK 或改用合适的锁机制，才能减少这类隐患。
行业怎么看
这件事说明，AI 应用之外的企业软件升级同样不能只看框架默认值。虚拟线程解决的是“能接收多少请求”，并没有解决“数据库能承受多少连接”。把接口并发能力直接等同于业务吞吐，容易把压力集中到成本更高、也更难横向扩展的数据库层。
风险也很明确：如果没有压测便直接放大连接池，数据库 CPU、锁竞争和会话数量可能先达到上限，反而拖垮整套系统。因此，扩大连接池不能替代 SQL 优化和容量治理；对于已经采用响应式编程的 WebFlux 项目，也没有必要再把虚拟线程当作并发方案叠加上去。
对普通人的影响
对企业 IT：升级框架后，团队应同时检查数据库连接池、慢查询和锁竞争，并用稳态压测确认等待数与超时数，而不是只看 CI 是否通过。
对个人职场：技术人员的价值正在从“完成代码编写”转向识别系统瓶颈、验证配置效果和解释业务影响，这会提高排障与架构判断的权重。
对消费市场：对多数终端用户而言，虚拟线程本身没有可见功能；它更可能影响电商、金融等高并发服务的响应速度与稳定性，但前提是后台资源同步扩容。