Hikari CP连接突发失效，请求技术排查建议

1. 优先排查PostgreSQL实例的资源瓶颈（db.t3.micro的先天局限） #

• db.t3.micro是AWS突发性能实例，CPU积分耗尽后会强制降频，直接导致查询卡顿、数据库主动断开连接。去CloudWatch查看CPUUtilization和BurstBalance指标，若故障时段BurstBalance跌到0，就是CPU资源不足导致的问题。
• 1GB内存的PostgreSQL默认配置下，shared_buffers仅占256MB，加上work_mem、事务内存等开销，极易出现内存不足，引发大量磁盘IO拖垮所有查询，甚至数据库会主动回收连接释放资源。去RDS的CloudWatch Logs中搜索PostgreSQL日志，查看是否存在out of memory、connection terminated due to resource exhaustion这类报错。

2. 优化Hikari连接池配置，适配数据库能力 #

• 当前配置缺少关键参数，导致连接池与数据库的超时规则不匹配：
  • maxLifetime：默认30分钟，若数据库端的idle_in_transaction_session_timeout或connection_timeout比这个值短，数据库会先断开连接，Hikari验证时就会报连接已关闭。建议将maxLifetime设为比数据库超时短30秒（比如数据库超时10分钟，Hikari设为9分30秒），同时显式配置validationTimeout和connectionTimeout。
  • minimumIdle：默认与最大池大小一致，会让Hikari一直维持40个连接，对1G内存的PostgreSQL负担过重。改成5-10，让连接池根据负载动态调整。
  • connectionTestQuery：虽然Hikari默认使用JDBC4的isValid()，但网络波动时可靠性不足，显式设置SELECT 1来验证连接有效性更稳妥。
• 调整后的参考配置：

hikari:
  data-source-properties: stringtype=unspecified
  maximum-pool-size: 20  # 先调回20，40个连接对小内存数据库压力过大
  minimumIdle: 5
  maxLifetime: 570000  # 9分30秒，适配数据库10分钟的空闲超时
  connectionTimeout: 5000  # 缩短连接获取超时，减少请求排队
  validationTimeout: 1000
  leak-detection-threshold: 30000

3. 定位并修复连接泄漏 #

• 即便未手动获取连接，框架使用不当也会导致泄漏：
  • 根据leak日志中的线程栈（如http-nio-8080-exec-482），定位到对应的Controller/Service方法，检查是否存在慢查询、外部调用阻塞导致事务挂起，或是自定义DAO中未正确关闭ResultSet/Statement的情况。
  • 排查是否有未正确处理的事务：比如try-catch块中未回滚异常，导致连接一直被占用。

4. 排查AWS网络与环境问题 #

• 应用与RDS之间的网络波动会导致TCP连接重置，Hikari检测到连接失效。查看应用实例的NetworkErrors、TCPResetCount，以及RDS的NetworkThroughput指标，确认故障时段是否存在网络异常。
• 检查RDS安全组、NACLs是否有临时规则变更，或是维护窗口是否在故障时段附近，是否发生过自动重启或补丁安装。

5. 数据库端连接状态排查 #

• 故障发生时，查询PostgreSQL的pg_stat_activity视图，查看是否存在大量idle in transaction的连接，这类连接会持续占用资源，导致新连接无法建立，甚至被数据库主动断开。
• 查看应用日志中是否有事务超时、锁等待的报错，这类问题会导致连接长时间被占用，进而引发连接池耗尽。

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