数据库连接资源释放不当的后果与正确做法

你有没有遇到过这样的情况：公司内部的管理系统突然变慢，甚至打不开？重启服务后一切正常，可没过多久又卡住了。排查来排查去，最后发现罪魁祸首竟是一段没正确释放数据库连接的代码。

数据库连接不是用完就没了

很多人以为，只要从数据库查到数据，任务就完成了。但实际上，每次建立数据库连接，操作系统和数据库服务器都会分配一定的资源——内存、端口、会话信息。这些资源不会自动回收，必须由程序主动释放。

想象一下，餐厅里每桌客人吃完饭都不起身，新客人源源不断进来，很快整个餐厅就会挤得动弹不得。数据库连接也是这样。如果不释放，连接数迅速堆积，达到上限后，新的请求只能排队等待，系统响应越来越慢，最终“假死”。

常见的错误写法

下面这段 Java 代码看起来没问题，但隐患很大：

Connection conn = DriverManager.getConnection(url, user, password);
Statement stmt = conn.createStatement();
ResultSet rs = stmt.executeQuery("SELECT * FROM users");
while (rs.next()) {
    System.out.println(rs.getString("name"));
}

这段代码执行完查询就结束了，但连接、语句、结果集都没有关闭。一旦这段代码在循环或高并发场景下运行，数据库连接池很快就被耗尽。

正确的做法是确保释放

使用 try-with-resources 是最稳妥的方式，它能自动关闭实现了 AutoCloseable 接口的资源：

try (Connection conn = DriverManager.getConnection(url, user, password);
     Statement stmt = conn.createStatement();
     ResultSet rs = stmt.executeQuery("SELECT * FROM users")) {
    while (rs.next()) {
        System.out.println(rs.getString("name"));
    }
} catch (SQLException e) {
    e.printStackTrace();
}

这样即使中间发生异常，JVM 也会确保资源被释放。类似的，在 Python 的 pymysql 或 MySQLdb 中，也应该用 with 语句管理连接；在 C# 中使用 using 块；在 Node.js 中确保调用 connection.release() 或使用连接池的 destroy 方法。

连接池不是万能保险

有些人觉得：“我们用了 HikariCP 连接池，应该没问题吧？” 其实不然。连接池只是管理连接的“调度员”，它能复用连接、限制总数，但如果你借了连接不还，池子照样会被占满。就像共享单车，平台有很多车，但如果大家都骑完不锁车，别人还是没车可用。

更危险的是，长时间占用连接还可能导致数据库侧的连接超时、锁表、事务未提交等问题，进而影响数据一致性。

真实案例：一次促销活动引发的故障

某电商网站在做限时秒杀时，首页加载越来越慢，订单系统几乎瘫痪。运维紧急排查，发现数据库连接数一直维持在最大值 100，无法创建新连接。最终定位到一段商品查询代码，由于缺少 finally 块中的 close() 调用，在异常情况下连接未能释放。高峰期请求暴增，大量连接堆积，系统崩溃。

修复后，加上自动资源管理机制，问题再也没有出现。其实改动很小，但影响巨大。

养成好习惯比补救更重要

写代码时，凡是打开了数据库连接、文件流、网络套接字这类资源，就要问自己一句：它会不会被关掉？别依赖“反正没人同时用”“测试时没问题”这种侥幸心理。生产环境的压力远超想象。