核心是“控量+及时归还+主动监控”：合理设连接池大小（初值≈CPU核数×2+1）、最小空闲连接（30%～50%），压测验证；确保连接释放（检查try-with-resources、事务、异步、异常路径）；启用泄漏检测（如HikariCP leak-detection-threshold）、Actuator监控及DB侧排查；按场景隔离（批处理/报表单独数据源）、限流（Sentinel）、读写分离。
核心是“控量 + 及时归还 + 主动监控”，不是盲目加大连接数。
合理设置连接池大小
最大连接数（maximum-pool-size）不能拍脑袋定。它要匹配数据库承受能力、应用线程模型和典型事务耗时：
- 初值可参考 (CPU核心数 × 2) + 1，比如 4 核机器设为 9～10
- 最小空闲连接（minimum-idle）建议设为最大值的 30%～50%，避免频繁创建连接
- 务必压测验证：用 JMeter 或 wrk 模拟真实并发，观察连接使用率、获取等待时间、超时失败率
确保连接及时释放
连接不归还是耗尽的直接原因，重点检查：
- 所有 try-with-resources 是否覆盖了 Connection/Statement/ResultSet
- Spring 事务中，是否在非事务方法里手动调用了 getConnection() 却忘了 close()
- 异步任务（如 @Async、线程池提交的任务）是否跨线程持有连接未释放
- 异常路径下是否遗漏了 connection.close() 或 transaction.rollback()
开启泄漏检测与主动监控
靠日志和经验排查太慢，要用工具提前预警：
立即学习“Java免费学习笔记（深入）”；
- HikariCP 开启 leak-detection-threshold=60000（毫秒），超时未归还会打印堆栈
- 集成 Druid 或暴露 HikariCP 的 Actuator 端点（如 /actuator/metrics/hikaricp.connections.active），实时看活跃连接数、等待数、超时次数
- 数据库侧查
show processlist或 pg_stat_activity，确认是否存在长事务或空闲但未断开的连接
区分场景做隔离与限流
不是所有操作都该抢同一池子的连接：
- 批处理、定时任务、报表导出等重IO操作，单独配一个数据源和连接池，避免冲击主业务
- 对 DAO 层测试或数据迁移类高并发场景，加请求级限流（如 Sentinel 或 @RateLimiter），控制单位时间建连请求数
- 读多写少的服务，可考虑读写分离，把查询流量引向只读从库，减轻主库连接压力
