连接池获取连接超时本质是应用在规定时间内未获取到可用连接，常见于高并发、连接泄漏、配置过小或数据库异常；应优先排查连接耗尽、未释放及配置不合理问题。
连接池获取连接超时，本质是应用在规定时间内没拿到可用连接，常见于高并发、连接泄漏、配置不合理或数据库侧异常。重点先看连接是否被耗尽、是否没释放、配置是否过小，再查数据库负载和网络状况。
检查连接是否被占满或泄漏
这是最常见原因。连接未正确关闭（比如没在 finally 或 try-with-resources 中释放），会导致连接一直被占用，池中可用连接数逐渐归零。
- 开启连接池的监控功能（如 HikariCP 的 metricRegistry 或 JMX），观察 active、idle、total 连接数变化趋势；
- 启用 HikariCP 的 leakDetectionThreshold（单位毫秒），例如设为 60000，运行中若连接未在 60 秒内关闭，会打印泄漏堆栈；
- 检查代码中所有 Connection/Statement/ResultSet 是否都确保关闭，尤其注意异常分支是否遗漏 close()；
- 使用 AOP 或字节码工具（如 ByteBuddy）在测试环境拦截未关闭连接的调用点，辅助定位问题位置。
核对连接池核心参数是否合理
参数设置脱离实际负载，会直接导致获取失败。不能只看文档默认值，要结合 QPS、平均响应时间、事务持续时间估算。
- maximumPoolSize：建议按公式粗略估算：并发请求数 × 平均每个请求持有连接时间（秒） ÷ 平均响应时间（秒），再留 20% 余量；
- connectionTimeout：默认 30 秒偏长，业务接口超时若为 1 秒，这里设成 800~1200ms 更合适，避免线程长时间阻塞；
- idleTimeout 和 maxLifetime：避免连接因数据库主动断连（如 MySQL wait_timeout）变成无效连接，建议 idleTimeout ，maxLifetime 略小于数据库最大连接生命周期；
- 开启 keepaliveTime（HikariCP 4.0+）并设为 30~60 秒，定期清理空闲连接，降低“假死连接”风险。
排查数据库与网络层问题
即使连接池配置正常，后端不可用也会表现为获取超时。需区分是“拿不到新连接”还是“已有连接执行慢”。
- 查数据库当前连接数：show status like 'Threads_connected';，对比 max_connections，确认是否已达上限；
- 查慢查询和锁等待：show processlist; 或 select * from information_schema.INNODB_TRX;，看是否有长事务或锁表阻塞；
- 用 telnet host port 或 nc -zv host port 验证网络可达性；
- 开启连接池的 initializationFailTimeout 和 connectionTestQuery（或 useServerPrepStmts=true 时的 validateQuery），确保新建连接能通过基础校验。
添加可观测性与快速响应机制
线上出问题时，光靠日志很难快速定界。需要把关键指标暴露出来，并设置告警。
- 将 HikariCP 的 MBean 注册到 Prometheus（通过 Micrometer），采集 hikaricp_connections_active、hikaricp_connection_acquire_seconds 等指标；
- 当 connection acquire timeout 异常频次突增，或 active / maximum > 0.9 持续 1 分钟，触发企业微信/钉钉告警；
- 在全局异常处理器中捕获 SQLException，对 SQLState='08001'（拒绝连接）、'08S01'（通信异常）等做特殊日志标记，方便 ELK 聚合分析；
- 压测时用 Arthas 动态 watch 获取连接的方法（如 HikariPool.getConnection()），查看实际耗时分布和阻塞线程栈。
不复杂但容易忽略。多数情况是连接没关、池子太小、数据库卡住这三类，按顺序排查通常能快速定位。关键是把“连接生命周期”可视化，而不是等报错才去翻日志。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
