HikariCP连接池爆满的核心是连接被卡住或未归还，需三步排查：先通过Actuator指标确认active=maximumPoolSize且idle=0、pending持续增长；再启用leak-detection-threshold（30–60秒）结合DEBUG日志定位泄漏代码；最后用SHOW FULL PROCESSLIST和慢查询分析数据库侧阻塞。
连接池爆满不是配置调小了，而是连接被卡住或没还回来。核心思路是：先看池子是不是真满了，再查谁占着不放，最后确认数据库有没有拖后腿。
看连接池实时状态，确认是否真耗尽
别只盯着报错日志，直接读取 HikariCP 的运行时指标：
- active == maximumPoolSize 且 idle == 0：池子确实被占光了
- pending_threads 持续增长：说明线程在排队等连接，不是瞬时高峰，是连接释放出了问题
- 用 Actuator 端点
/actuator/metrics/hikaricp.connections.active或 JMX 查值，比猜更准
抓连接泄漏，定位没归还的代码
HikariCP 自带泄漏检测，关键要配对、看得见：
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- 启用泄漏检测：
leak-detection-threshold: 60000（单位毫秒，建议 30–60 秒） - 打开 DEBUG 日志，一旦触发会打印持有连接的完整堆栈，例如：
at com.example.service.UserService.getUser(UserService.java:42) - 常见漏点：原生 JDBC 手动 getConnection() 后没 close；@Async 方法里访问数据库；try-catch 中遗漏 finally 关闭；事务内调外部 HTTP/RPC 导致连接长期 hold
查数据库侧瓶颈，排除慢 SQL 和锁等待
连接池满，有时是数据库端“堵车”导致连接迟迟不能释放：
立即学习“Java免费学习笔记（深入）”；
- 登录 MySQL 执行
SHOW FULL PROCESSLIST;，重点关注 Sleep（连接空闲但未关闭）和长时间 Query/Update 状态 - 查慢查询：
SELECT * FROM information_schema.PROCESSLIST WHERE TIME > 5; - 看锁情况：
SHOW ENGINE INNODB STATUS\G，关注 TRANSACTIONS 和 LOCK WAIT 部分 - 确认当前连接数：
SHOW STATUS LIKE 'Threads_connected';，对比max_connections是否接近上限
核对关键配置，避免参数失衡
配置不合理会放大问题，不是越大越好，也不是越小越安全：
-
maximum-pool-size 要匹配数据库
max_connections，一般设为 DB 总连接数的 70%～80% - connection-timeout 建议 10–30 秒，太短容易误报，太长会让故障持续更久
- max-lifetime 避免设得太短（如
- 开启
keepalive-time（如 60 秒）并配合validation-timeout，可减少无效连接堆积
