服务器云平台下迁移

系统隔三差五会爆出无法获取数据库连接池的报错，相信这个问题，大多数开发同学都不陌生。

先上报错日志：

数据库连接池等待超时Errorqueryingdatabase.Cause:org.springframework.jdbc.CannotGetJdbcConnectionException:FailedtoobtainJDBCConnection;nestedexceptionisJava.SQL.SQLTransientConnectionException:HikariPool-1-Connectionisnotavailable,requesttimedoutafter30000ms.

看到报错的第一时间，我虽然心里有了一些猜测方向，但还是先把日志丢给 AI，让它给出排查思路。

山东专业服务器云主机

AI 给出的排查方向

重点考虑以下几点：

1.Hikari 连接池配置不合理

maxPoolSize 过小：连接池最大连接数低于应用并发请求量，高峰期无空闲连接。connectionTimeout 过短：当前超时时间 30 秒，若连接池长期无空闲连接，请求会触发超时。idleTimeout/keepaliveTime 设置不当：空闲连接回收不及时，或存活检测失效导致连接池存在无效连接。

2. 应用侧连接泄漏

应用获取连接后未正确释放（如未通过 try-with-resources 管理连接；MyBatis/Mapper 方法未在事务中正确执行，导致连接未归还；代码中手动获取连接但忘记关闭），造成连接池连接被占用且无法复用。

3. 数据库连接被长时间占用

存在慢 SQL：查询语句执行时间过长，连接被长时间占用，连接池无空闲连接。数据库端连接状态异常：部分连接处于 Sleep/Locked 状态（需通过 show processlist 查看），未被及时释放。

4. 并发请求量突增应用高峰期并发请求超过连接池最大承载能力，即使连接池配置合理也会出现无可用连接的情况。

第一轮排查过程

按照 AI 给出的框架，我逐一进行排查：

云服务器找回照片命令

排查 Hikari 连接池配置不合理数据库会话连接数平稳，历史趋势显示连接数未超限；连接池为默认公用配置，其他业务模块从未出现类似问题 →排除此项。排查应用侧连接泄漏事务完全交由框架自动管理，不存在手动获取连接后忘记关闭的情况 →排除此项。排查数据库连接被长时间占用故障发生时因紧急重启系统，无法查看当时数据库连接状态；事后核查，数据库连接多为正常 sleep 状态。 数据库无慢 SQL 记录，报错高频方法对应的 SQL 执行耗时极短 →暂时排除。排查并发请求量突增故障时间段内流量平稳无毛刺，无大并发请求涌入 →排除此项。

僵局突破：从高频方法里找答案

几轮排查下来毫无头绪，我只能把目光重新聚焦到报错日志指向的高频方法上。 当看到这段伪代码时，问题的突破口出现了：

@transactionmethod(){// 1. 查询 SQL// 2. HTTP 请求// 3. 修改 SQL}

这段代码里的2. HTTP 查询格外可疑，原因有两点：

这个 HTTP 调用是几个月前新增的逻辑，之前系统从未出现过类似故障；该 HTTP 查询的访问时间极不稳定，很容易出现超时情况。

进一步核查 HTTP 访问配置发现：这个请求没有设置超时时间，使用的是默认超时配置——足足 60 秒！

这一下，问题的根源就清晰了： 我们的连接池总共只有 30 个连接，而被@transaction 注解标记的方法，在执行过程中会一直占用数据库连接。 如果请求卡在2. HTTP 查询这一步，每个请求都会占用一个连接长达 60 秒。只要同时涌入 30 个请求，连接池就会被直接打满，后续请求自然会触发连接超时。

为了验证猜想，我核查了故障时间段的日志：

HTTP 请求超时错误数量明显增加；故障时间段的请求数，恰好超过了连接池的 30 个上限。

补充：为什么之前的数据库排查没发现问题？

很多同学可能会疑惑，既然连接被长时间占用，为什么数据库侧没检测到慢 SQL？ 原因很简单：

数据库记录的 SQL 耗时，只有1. 查询 SQL和3. 修改 SQL这两步，这两步的执行时间都在毫秒级；事务的 commit 操作是独立的，单看 SQL 语句的执行耗时完全看不出异常；但从数据库连接线程的维度看，会发现连接被占用了数十秒——如果当时能执行 show processlist，就能看到 30 个处于 active 状态的连接，只是这些连接都阻塞在外部 HTTP 请求上，而非数据库操作。

最终总结：3 个关键经验

用 AI 给排查的思考框架，而非直接要答案AI 可以快速梳理出故障的常见排查方向，帮我们搭建系统化的分析框架，但具体的问题根源，还需要结合业务代码和实际场景耐心深挖。排查问题的核心逻辑：排除法+三个优先优先排查错误发生的高频方法，优先排查应用侧问题，优先排查最近的代码修改部分——这三个优先能帮我们快速缩小排查范围，少走弯路。数据库事务中包含外部请求，一定要设置超时时间事务执行过程中会持续占用数据库连接，若其中包含 HTTP 调用/服务调用等符合二阶段事务的形态，必须设置合理的最大超时时间，避免因外部请求阻塞导致连接池被打满，变相造成连接泄漏。

阿里云服务器老被攻击