SpringBoot 2.0.2切换HikariCP后，10次请求后连接超时求助

从你的错误日志和配置来看，核心问题是HikariCP连接池的10个连接被全部占用且未释放，导致后续请求无法获取连接超时。结合你从Spring Boot 1.5.x升级到2.0.x的背景，以及异步方法的调用场景，下面是具体的排查方向和解决方案：

一、优先排查异步方法的事务管理问题 #

从错误栈可以看到，错误发生在异步方法processCommunicationRequest中，这个方法调用了CrudRepository的findById方法。Spring中@Async方法会在独立线程中执行，默认不会继承主线程的事务上下文，如果事务处理不当，很容易导致连接无法正常释放：

• 如果你的异步方法本身需要事务，必须直接在异步方法上添加@Transactional注解（不能依赖调用方的事务），确保事务在异步线程中正确提交或回滚。
• 检查异步方法内的事务传播行为：如果调用的Repository方法使用默认的REQUIRED传播，而异步方法没有开启事务，Repository会开启新事务，但如果事务没有被正确关闭（比如异常未被捕获导致事务未回滚），连接会被一直占用。

二、补充HikariCP的关键配置 #

你的现有配置已经覆盖了基础参数，但针对Oracle数据库，还有几个关键配置需要补充：

1. 添加连接有效性检测语句
   Oracle数据库需要显式配置连接测试语句，HikariCP才能正确验证连接是否可用。添加以下配置：

   spring.datasource.hikari.connectionTestQuery=SELECT 1 FROM DUAL
   

2. 开启连接泄漏检测
   为了定位具体哪个代码块导致连接泄漏，开启Hikari的泄漏检测：

   spring.datasource.hikari.leakDetectionThreshold=30000
   

   当连接被占用超过30秒时，Hikari会打印详细的栈信息，帮你找到未释放连接的代码位置。

三、检查是否存在连接泄漏代码 #

虽然使用了CrudRepository，但如果代码中存在直接操作JDBC连接的场景（比如通过DataSource.getConnection()手动获取连接），一定要确保在finally块中关闭连接、Statement、ResultSet等资源：

// 正确示例：确保关闭资源
Connection conn = null;
Statement stmt = null;
try {
    conn = dataSource.getConnection();
    stmt = conn.createStatement();
    // 执行操作...
} catch (SQLException e) {
    // 异常处理
} finally {
    if (stmt != null) try { stmt.close(); } catch (SQLException ignore) {}
    if (conn != null) try { conn.close(); } catch (SQLException ignore) {}
}

四、验证Spring Boot 2.x的事务配置变化 #

Spring Boot 2.x对JPA事务管理器的默认行为有调整，你可以检查以下几点：

• 确保JpaTransactionManager被正确配置，并且关联了HikariDataSource。Spring Boot默认会自动配置，但如果自定义了事务管理器，需要确认数据源关联正确。
• 确认spring.jpa.open-in-view=false生效：这个配置已经添加，能避免Open Session In View模式导致的长期连接占用，确保请求结束后连接及时归还池。

快速验证步骤 #

1. 先添加leakDetectionThreshold和connectionTestQuery配置，重启服务后复现问题，查看日志中的连接泄漏栈信息。
2. 检查异步方法的事务注解是否正确，确保异步线程中的事务能正常结束。
3. 排查所有手动操作JDBC连接的代码，确保资源被正确关闭。

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