HikariCP连接池调优核心是5个参数：maximumPoolSize按CPU计算、connectionTimeout设5秒、maxLifetime小于数据库wait_timeout、minimumIdle依流量特征设定、leak-detection-threshold开启定位泄漏。
直接看日志里有没有“无法获取连接”“connection timeout”“abandoned”这类关键词，再结合时间戳和请求路径交叉比对，就能快速锁定是哪类代码或哪个接口拖垮了连接池。
盯紧应用日志里的关键报错
数据库连接池耗尽时，应用层通常会抛出明确异常：
-
Java 应用常见报错：如
org.apache.tomcat.jdbc.pool.PoolExhaustedException: Unable to acquire a connection或java.sql.SQLTimeoutException: Timeout after 30000ms -
Spring Boot 场景：日志中出现
HikariPool-1 - Connection is not available, request timed out（HikariCP）或Timeout waiting for idle object（DBCP2） -
Tomcat JDBC Pool：搜
removeAbandonedOnBorrow或logAbandoned相关行，说明连接长期未归还，大概率存在泄漏
用 Nginx 日志反向验证阻塞点
504 错误不是根源，但它是连接池被占满后的典型外显症状。别只看状态码，重点比对三组字段：
- request_time ≈ proxy_read_timeout（比如都是 60.000），说明 Nginx 等到超时都没收到响应
- upstream_response_time 是 "-" 或极小值（如 0.001），表明后端压根没返回完整响应，卡在处理中
-
同一 path 短时间内密集出现 504（比如
/api/v1/order/submit在 10 秒内报 12 次），基本可断定该接口触发了长事务或连接泄漏
下钻数据库查实时连接与事务
确认可疑接口和时间后，立刻登录数据库查活态：
-
MySQL：执行
SHOW PROCESSLIST;找Time值高、State为Sending data/Locked的线程；再跑SELECT * FROM information_schema.INNODB_TRX WHERE TIME_TO_SEC(TIMEDIFF(NOW(), trx_started)) > 60;查超 1 分钟的未提交事务 -
PostgreSQL：用
SELECT pid, now() - pg_stat_activity.backend_start AS duration, state, query FROM pg_stat_activity WHERE state = 'active' ORDER BY duration DESC LIMIT 10;找长时间运行的查询 -
通用技巧：把应用日志里记录的
x-request-id或精确时间点，和数据库INFORMATION_SCHEMA.PROCESSLIST或pg_stat_activity中的backend_start对齐，能直接关联到具体 SQL
检查 Tomcat 连接池配置与运行状态
连接池本身配置不当或资源不足也会加速耗尽：
- 查
catalina.out或localhost.<date>.log</date>，搜索Connection refused（连不上 DB）、Connection timed out（网络或 DB 响应慢）、PoolableConnectionFactory（驱动加载失败） - 启用细粒度日志：在
conf/logging.properties中设org.apache.tomcat.jdbc.pool.level = FINE，可看到每次 getConnection / returnConnection 的耗时与堆栈 - 通过 JMX 或 Spring Boot Actuator 的
/actuator/metrics/datasource.hikaricp.connections.active实时监控活跃连接数是否持续接近max-active阈值
