Spring Boot JPA事务未释放连接池致性能瓶颈，求配置级解决方案

核心原因 #

你的推测完全正确：Spring事务默认会将数据库连接绑定到当前线程（包括虚拟线程）的上下文，即使@Transactional方法执行完成、事务提交后，连接也不会立即归还连接池，而是要等到整个请求处理流程结束（即B的HTTP请求、C的事务都执行完）才会释放。当B点存在100ms延迟时，A占用的连接会被持续持有，30个并发请求会快速耗尽连接池，后续请求因等待连接阻塞，表现为A的调用耗时剧增（实际是等待连接的时间，而非数据库操作时间）。

而调换A、B顺序后，A和C是连续执行的独立事务，Spring会复用绑定在当前线程的同一个连接，仅占用1个连接/请求，不会因B的延迟导致连接长时间占用，因此吞吐量恢复正常。

配置级解决方案（无需改写为JDBC） #

1. 强制Hibernate事务结束后立即释放连接 #

在application.properties或application.yml中添加配置：

spring.jpa.properties.hibernate.connection.release_mode=AFTER_TRANSACTION

该配置会让Hibernate在事务提交/回滚后，立即将连接归还连接池，不再等待线程上下文清理，完全适配你A、B、C的独立事务场景，不会影响事务正确性。

2. 禁用Spring事务的线程上下文绑定（适合独立事务场景） #

如果你的业务中没有跨方法共享事务的需求，可以禁用Spring的事务同步机制：

spring.transaction.synchronization=SYNCHRONIZATION_NEVER

该配置会阻止Spring将事务资源（包括连接）绑定到线程上下文，每个@Transactional方法执行完成后，连接直接归还连接池。注意：如果存在嵌套事务或需要跨方法传递事务的场景，请勿使用此配置。

3. 辅助优化连接池参数（可选） #

配合上述核心配置，调整HikariCP参数进一步优化：

# 调整连接池最大容量，适配并发需求（建议略高于峰值并发数）
spring.datasource.hikari.maximum-pool-size=40
# 开启连接泄漏检测，超时2秒报警（用于验证连接是否及时释放）
spring.datasource.hikari.leak-detection-threshold=2000

验证效果 #

应用上述配置后，A点事务执行完成后连接会立即归还连接池，B点的HTTP延迟不会再占用数据库连接。并发30的场景下，连接池不会被快速耗尽，后续请求可以正常获取连接，A点的调用耗时会恢复到数据库实际操作的1ms左右，系统吞吐量回归正常。

内容的提问来源于stack exchange，提问作者SPIRiT_1984