Java连接池获取连接超时本质是connection-timeout触发，因池中无空闲连接且无法新建，抛出SQLTimeoutException；核心需排查连接泄漏、参数不合理及数据库端瓶颈。
Java 连接池获取连接超时，本质是应用在调用 dataSource.getConnection() 时，等待可用连接的时间超过了配置的阈值（如 HikariCP 的 connection-timeout），最终抛出类似 java.sql.SQLTimeoutException: Timeout after 30000ms of waiting for a connection 的异常。核心原因不是数据库连不上，而是连接池里**没有空闲连接可分配**，且无法及时新建连接。排查需围绕“为什么没连接”展开。
检查连接池实际使用与泄漏情况
这是最常见原因：连接未被正确归还，导致连接被长期占用甚至泄漏。
- 确认所有
Connection、Statement、ResultSet是否都在try-with-resources或finally块中显式关闭；尤其注意异常分支下是否遗漏close() - 开启连接池的泄漏检测（如 HikariCP 设置
leak-detection-threshold=60000），运行一段时间后观察日志中是否有 “Connection leak detection triggered” 提示 - 通过 JMX（如 HikariCP 暴露的
HikariPool-1:totalConnections、idleConnections、activeConnections）或 Actuator 端点实时观察连接数变化趋势：若active持续高位、idle长期为 0，大概率存在未释放
核对连接池核心参数是否合理
参数配置不当会直接限制连接供给能力，尤其在流量突增或慢 SQL 场景下暴露明显。
-
最大连接数（
maximumPoolSize）是否过小？ 比如设为 10，但并发请求峰值达 50，必然排队超时。应结合 QPS、平均响应时间、事务耗时估算：理论最小需求 ≈ QPS × 平均处理耗时（秒） -
连接超时时间（
connection-timeout）是否过短？ 默认 30 秒可能不够——若数据库负载高、网络抖动或连接建立需握手/认证，建议先调大到 45–60 秒用于定位，再根据真实建连耗时收敛 -
连接存活与校验配置是否拖慢获取速度？ 如启用
connection-test-before-use且测试 SQL 较重，或validation-timeout过短导致频繁验证失败重试，可临时禁用验证观察是否改善
排查数据库端瓶颈与资源限制
即使连接池参数宽松，若数据库无法及时响应建连请求，也会导致获取超时。
立即学习“Java免费学习笔记（深入）”；
- 检查数据库当前最大连接数（如 MySQL 的
max_connections）是否已打满，执行show processlist观察是否存在大量 Sleep 或长时间运行的会话 - 确认数据库服务器 CPU、内存、IO 负载是否过高（
top、iostat），慢查询是否堆积（查看 slow log 或 performance_schema） - 网络层面验证：从应用服务器
telnet db-host port或nc -zv测试基础连通性；用tcpdump抓包看三次握手是否延迟、是否存在 RST 包
补充建议：快速定位与防御措施
避免问题反复发生，需建立可观测性和兜底机制。
- 在获取连接前后打日志（如
log.debug("Try get conn at {}", System.currentTimeMillis())），配合 APM 工具（SkyWalking、Pinpoint）追踪完整链路耗时 - 对非核心业务操作（如日志写入、通知发送）使用独立数据源或降级为本地缓存，避免挤占主库连接
- 上线前做连接池压测：模拟并发请求，监控
activeConnections峰值、等待队列长度、超时比例，验证参数水位 - 考虑引入熔断机制（如 Resilience4j），当连接获取失败率持续超标时自动拒绝部分请求，保护数据库不被拖垮
