今天咱们来聊聊一个让很多DBA和开发同学都头疼的问题：数据库连接泄漏。尤其是在使用像KingbaseES这样的国产优秀数据库时，应用跑着跑着，突然就报“连接池耗尽”、“无法获取数据库连接”的错，服务跟着就“挂”了。这感觉，就像家里的水管到处是看不见的小裂缝，水压越来越低，最后直接停水，让人措手不及。
这个问题本质上，是应用从连接池中借走了数据库连接，用完之后却忘了还回去。连接池里的连接是有限的宝贵资源，借而不还，池子很快就空了。后续的请求自然就拿不到连接，导致应用部分或全部功能不可用。排查这类问题，就像当侦探，需要耐心和正确的工具。
一、什么是连接泄漏，它如何“耗尽”资源？
想象一下，公司的公用车队有10辆车（连接池最大连接数）。每个团队（应用线程）出差时都可以申请一辆。正常情况是，团队用车完毕，归还车辆，供其他团队使用。连接泄漏，就是某个团队用车后，由于各种原因（比如忘了、流程出错、中途抛锚没处理），没有把车还回车库。一次两次可能没事，但当越来越多的车有借无还，车库就空了。其他要出差的团队只能干等着，业务也就停滞了。
在技术层面，这通常是因为程序代码中打开了数据库连接（Connection），但在执行完毕后，尤其是在发生异常时，没有正确地在 finally 块中关闭连接，或者关闭连接的逻辑存在缺陷。这些未关闭的连接会一直占用着数据库端的会话资源和客户端连接池的资源。
二、如何定位连接泄漏的“蛛丝马迹”？
排查需要从数据库端和应用端双管齐下。
1. 数据库端侦查： 登录KingbaseES数据库，查询当前活跃的连接，看哪些连接长时间空闲或处于异常状态。
-- 查询当前所有会话的详细信息，重点关注“state”和“query”
SELECT pid, usename, application_name, client_addr, state, query, now() - state_change as idle_duration
FROM sys_stat_activity
WHERE datname = 'your_database_name' -- 替换为你的数据库名
AND state != 'idle'; -- 先看非空闲的，长时间执行的可能有问题
-- 查询所有会话（包括空闲的），按连接时间排序，找出“老”连接
SELECT pid, usename, application_name, client_addr, state, backend_start, now() - backend_start as connection_age
FROM sys_stat_activity
WHERE datname = 'your_database_name'
ORDER BY backend_start ASC;
如果发现大量来自同一应用IP、状态长期为 idle in transaction（事务中空闲）或 active 但执行时间超长的连接，这些就是重点怀疑对象。它们的“query”字段可能显示为最后执行的一条SQL。
2. 应用端监控与分析：
- 监控连接池指标： 如果使用Druid、HikariCP等连接池，它们都提供了丰富的监控端点（如Druid的
/druid/sql.html）或JMX指标。重点关注ActiveCount（活跃连接数）是否持续走高且不下降，PoolingCount（池中空闲连接数）是否逐渐减少直至为0。 - 审查代码： 这是最根本的。检查所有涉及数据库操作的地方，特别是那些复杂的业务逻辑、循环操作、以及在异常处理路径中，是否确保了连接的关闭。
三、实战演练：修复Java应用中的典型泄漏场景
让我们用一个基于 Java + JDBC + HikariCP连接池 的典型场景来演示。假设我们有一个用户服务，需要批量处理用户状态。
泄漏的代码示例：
// 泄漏示例：在循环中获取连接，但异常时未正确关闭
public class UserServiceLeak {
private DataSource dataSource; // 假设已注入HikariCP数据源
public void batchUpdateUserStatus(List<Integer> userIds, String status) {
for (Integer userId : userIds) {
Connection conn = null;
try {
// 问题点：每次循环都从数据源获取新连接
conn = dataSource.getConnection();
String sql = "UPDATE sys_user SET status = ? WHERE id = ?";
PreparedStatement pstmt = conn.prepareStatement(sql);
pstmt.setString(1, status);
pstmt.setInt(2, userId);
pstmt.executeUpdate();
pstmt.close();
// 假设这里没有 conn.close()，或者下面有异常抛出...
} catch (SQLException e) {
// 仅打印日志，连接未在finally中关闭，发生异常时连接泄漏！
System.err.println("更新用户状态失败: " + e.getMessage());
// 注意：此处直接捕获异常并继续循环，conn 未被关闭！
}
// 如果一切正常，conn 应该在这里关闭，但代码遗漏了。
// 更糟糕的是，如果上面的 pstmt.close() 抛出异常，也会跳过后面的关闭。
}
}
}
代码分析： 这段代码在循环内获取连接。如果在创建PreparedStatement或执行executeUpdate时抛出SQLException，程序会跳转到catch块，打印日志后继续下一个循环。而连接conn根本没有被关闭的机会！每次循环泄漏一个连接，用户ID列表稍大，连接池就会迅速耗尽。
修复后的代码示例：
// 修复后：使用try-with-resources确保资源关闭，并将连接获取移至循环外（视事务需求）
public class UserServiceFixed {
private DataSource dataSource;
public void batchUpdateUserStatus(List<Integer> userIds, String status) {
// 方案A：如果每次更新是独立事务，仍在循环内获取，但用try-with-resources确保关闭
for (Integer userId : userIds) {
// try-with-resources 语句会自动关闭实现了AutoCloseable接口的资源（Connection, Statement, ResultSet）
try (Connection conn = dataSource.getConnection();
PreparedStatement pstmt = conn.prepareStatement(
"UPDATE sys_user SET status = ? WHERE id = ?")) {
pstmt.setString(1, status);
pstmt.setInt(2, userId);
pstmt.executeUpdate();
} catch (SQLException e) {
// 处理异常，此时连接等资源已被自动关闭
System.err.println("更新用户状态失败，用户ID: " + userId + ", 错误: " + e.getMessage());
// 根据业务决定：是记录后继续，还是抛出运行时异常回滚外层事务？
// throw new RuntimeException(e);
}
}
// 方案B：如果需要整体作为一个事务，则在循环外获取一个连接，手动管理事务
/*
try (Connection conn = dataSource.getConnection()) {
conn.setAutoCommit(false); // 关闭自动提交
try (PreparedStatement pstmt = conn.prepareStatement(...)) {
for (Integer userId : userIds) {
pstmt.setString(1, status);
pstmt.setInt(2, userId);
pstmt.addBatch(); // 加入批处理
}
pstmt.executeBatch(); // 执行批处理
conn.commit(); // 提交事务
} catch (SQLException e) {
conn.rollback(); // 回滚事务
throw new RuntimeException("批量更新失败，事务已回滚", e);
}
} catch (SQLException e) {
throw new RuntimeException("获取数据库连接失败", e);
}
*/
}
}
修复要点：
- 使用 try-with-resources： 这是Java 7+的最佳实践，能确保在代码块执行完毕后，无论是否发生异常，
Connection和PreparedStatement都会被自动调用close()方法。 - 合理的资源作用域： 方案A将连接的作用域限制在单次循环内，更新之间互不影响。方案B则使用一个连接和批处理，将整个操作作为一个原子事务，性能更高，但需要手动管理事务提交与回滚。
- 异常处理： 在
catch块中处理异常后，是继续执行还是抛出，需根据业务逻辑决定。关键是，无论怎么决定，资源都已由try-with-resources自动清理。
关联技术：HikariCP配置与监控 除了代码修复，配置好连接池本身也是一道防线。HikariCP可以通过设置超时参数来强制回收疑似泄漏的连接。
# application.yml 示例配置
spring:
datasource:
hikari:
maximum-pool-size: 20
minimum-idle: 5
connection-timeout: 30000 # 获取连接超时时间(ms)
idle-timeout: 600000 # 连接空闲超时时间(ms)，超过此时间且连接数大于minimum-idle时会被释放
max-lifetime: 1800000 # 连接最大存活时间(ms)，强制周期性刷新连接
leak-detection-threshold: 60000 # 连接泄漏检测阈值(ms)，如果连接从池中借出超过此时间未归还，会打印错误日志。生产环境慎用或设长，仅调试用。
leak-detection-threshold 是一个强大的调试工具。设置后，HikariCP会跟踪每个连接被借出的时间。如果超过阈值仍未归还，就会在日志中标记一个疑似泄漏的警告，并附上当时借出连接的堆栈跟踪信息，这能直接帮你定位到泄漏的代码位置！
四、进阶排查与预防之道
对于更复杂的场景，比如使用MyBatis等ORM框架，或者是在异步、多线程环境下，连接泄漏可能更隐蔽。
1. MyBatis框架下的注意事项：
MyBatis的 SqlSession 需要被正确关闭。通常我们结合Spring，使用 @Transactional 注解管理事务和会话生命周期。但如果在方法内部手动创建了 SqlSession，必须确保关闭。
// 正确使用示例
try (SqlSession session = sqlSessionFactory.openSession()) {
UserMapper mapper = session.getMapper(UserMapper.class);
// ... 执行操作
session.commit(); // 如果需要
} // 自动关闭session，其内部的连接会还给连接池
2. 异步编程中的连接传递：
绝对不要将JDBC Connection 对象跨线程传递或存储在ThreadLocal中而不清理。在异步回调或线程池任务中，务必在任务的最外层获取和关闭连接（或会话），确保资源释放与任务生命周期绑定。
3. 建立预防体系：
- 代码规范： 强制规定所有数据库操作必须使用
try-with-resources或显式地在finally块中关闭资源。 - 代码审查： 将资源关闭作为Code Review的重点检查项。
- 监控告警： 在生产环境监控连接池的活跃连接数、等待线程数等关键指标，并设置阈值告警。例如，当活跃连接数持续超过最大池大小的80%并超过5分钟，就触发告警。
- 定期“体检”： 在低峰期，可以执行数据库端的查询，检查是否存在超长生命周期或异常状态的连接。
应用场景与总结 连接泄漏问题普遍存在于任何使用数据库连接池的Web应用、后台服务或批处理程序中。尤其在并发量高、业务逻辑复杂、异常分支多的系统中，风险更高。
技术优缺点：
- 手动管理连接： 优点是最直观，控制力强；缺点是非常容易因疏忽导致泄漏，代码冗长。
- 连接池+框架管理（如Spring
@Transactional）： 优点是开发效率高，大部分情况下自动管理，降低了泄漏风险；缺点是需要深入理解框架行为，配置不当或错误使用API（如在事务内开启新线程操作数据库）仍会导致泄漏。 - try-with-resources： 是Java语言层面提供的优秀方案，能有效防止绝大多数泄漏，代码简洁。
注意事项：
- 关闭
Connection时，其衍生出的Statement和ResultSet通常会自动关闭，但显式关闭它们仍是好习惯。 - 连接池的
max-lifetime和idle-timeout是回收“僵尸”连接的最后保障，应根据数据库和服务器的承受能力合理设置。 - 连接泄漏检测工具（如HikariCP的
leak-detection-threshold）对性能有影响，仅推荐在测试或临时排查生产问题时开启。
总而言之，解决KingbaseES乃至任何数据库的连接泄漏问题，是一场“防”大于“治”的战役。核心在于培养良好的编程习惯，善用现代语言特性和框架机制，并构建从代码开发到线上监控的全链路防御体系。当出现资源耗尽警报时，保持冷静，按照“数据库端查询 -> 连接池监控 -> 代码定位”的路径，结合有效的工具，一定能找到那个“有借无还”的漏洞，让系统的“水流”重新畅通无阻。
评论