在Java应用程序中，正确地关闭数据库连接及相关资源是至关重要的一个环节，这不仅关系到应用程序的性能和稳定性，也直接影响服务器的资源利用效率，所谓“关闭数据库”，在Java的语境下，主要指的是关闭与数据库交互过程中创建的JDBC（Java Database Connectivity）核心对象，释放它们占用的数据库和系统资源，如果处理不当，极易导致资源泄漏、连接池耗尽,甚至最终导致应用崩溃。
核心资源与关闭顺序
在使用JDBC进行数据库操作时，通常会涉及三个核心资源对象,它们都需要被妥善关闭：
Connection：代表与数据库的物理连接，这是最宝贵的资源,创建和销毁的成本都很高。Statement（或其子类PreparedStatement、CallableStatement）：用于执行SQL语句的对象,它封装了向数据库发送SQL命令的过程。ResultSet：当执行查询语句（SELECT）后，返回的结果集对象,它包含了从数据库中检索出的数据。
关闭这些资源时，必须遵循“后创建的先关闭”原则，即按照 ResultSet -> Statement -> Connection 的顺序进行，这是因为 Statement 是依赖于 Connection 创建的，而 ResultSet 又是依赖于 Statement 创建的，如果先关闭了 Connection，那么其上的 Statement 和 ResultSet 会变为无效状态，虽然部分JDBC驱动会自动处理,但依赖这种自动行为是不安全的编程习惯。
传统的 try-catch-finally 方式
在Java 7之前，最经典和可靠的关闭资源方式是使用 try-catch-finally 代码块，将资源的关闭逻辑放在 finally 块中，可以确保无论 try 块中是否发生异常,资源都一定会被尝试关闭。
Connection connection = null;
PreparedStatement statement = null;
ResultSet resultSet = null;
try {
// 1. 获取连接
connection = DriverManager.getConnection("jdbc:mysql://localhost:3306/mydb", "user", "password");
// 2. 创建PreparedStatement
statement = connection.prepareStatement("SELECT id, name FROM users WHERE id = ?");
statement.setInt(1, 101);
// 3. 执行查询
resultSet = statement.executeQuery();
// 处理结果集...
while (resultSet.next()) {
// ...
}
} catch (SQLException e) {
// 处理异常
e.printStackTrace();
} finally {
// 4. 按顺序关闭资源
// 关闭 ResultSet
if (resultSet != null) {
try {
resultSet.close();
} catch (SQLException e) {
e.printStackTrace();
}
}
// 关闭 Statement
if (statement != null) {
try {
statement.close();
} catch (SQLException e) {
e.printStackTrace();
}
}
// 关闭 Connection
if (connection != null) {
try {
connection.close();
} catch (SQLException e) {
e.printStackTrace();
}
}
} 这种方式虽然可靠，但代码显得非常冗长和臃肿，大量的 try-catch 嵌套在 finally 块中,降低了代码的可读性。
现代的 try-with-resources 方式（推荐）
从Java 7开始，引入了 try-with-resources 语句，极大地简化了资源管理，任何实现了 AutoCloseable 或 Closeable 接口的类都可以在 try 语句中声明，Java会保证在 try 语句块执行完毕后（无论是正常结束还是因异常退出），自动调用这些资源的 close() 方法。
// 使用 try-with-resources 自动关闭资源
String sql = "SELECT id, name FROM users WHERE id = ?";
try (Connection connection = DriverManager.getConnection("jdbc:mysql://localhost:3306/mydb", "user", "password");
PreparedStatement statement = connection.prepareStatement(sql)) {
statement.setInt(1, 101);
try (ResultSet resultSet = statement.executeQuery()) {
// 处理结果集...
while (resultSet.next()) {
// ...
}
}
} catch (SQLException e) {
// 处理异常
e.printStackTrace();
} 可以看到，代码变得异常简洁和清晰，所有的关闭逻辑都由JVM自动处理，不仅减少了代码量，也从根本上避免了因忘记关闭资源而导致的泄漏问题,这是目前Java中关闭JDBC资源的最佳实践。
两种方式的对比
| 特性 | try-catch-finally | try-with-resources |
|---|---|---|
| 代码简洁性 | 冗长，需要大量嵌套的try-catch | 简洁，资源声明在try括号内 |
| 异常处理 | 关闭资源时可能抛出异常，需额外处理 | 自动处理关闭时的异常（可被主异常抑制） |
| 资源泄漏风险 | 较高，容易因编码疏忽忘记关闭 | 极低，由JVM保证自动关闭 |
| 推荐度 | 仅适用于维护旧项目或Java 6及以下环境 | 强烈推荐，Java 7+项目的标准做法 |
连接池环境下的“关闭”
在现代企业级应用中，通常不会直接使用 DriverManager 获取连接，而是使用数据库连接池（如HikariCP、Druid、C3P0等），在连接池的管理下，connection.close() 的行为发生了微妙的变化。
此时调用 connection.close() 并不会真正地关闭物理数据库连接，而是将这个“连接”对象归还给连接池，连接池会将其标记为空闲，以便后续的其他请求可以复用这个物理连接,从而避免了频繁创建和销毁连接带来的巨大性能开销。
尽管如此，Statement 和 ResultSet 的关闭原则依然不变，它们不是池化的资源，每次使用后都必须被显式或通过 try-with-resources 自动关闭,以释放数据库服务器上的游标等资源。
相关问答 (FAQs)
问题1：如果我只关闭 Connection，而不关闭 Statement 和 ResultSet，会有什么问题？
解答： 尽管大多数JDBC驱动在连接关闭时会尝试自动释放其上创建的所有Statement和ResultSet，但依赖这种行为是不良的编程习惯，这并非JDBC规范强制要求，不同驱动的实现可能存在差异，在连接池环境下，connection.close() 只是归还连接，物理连接并未关闭，未关闭的Statement和ResultSet占用的数据库端资源（如游标）不会被释放，长期累积会导致数据库资源耗尽，最终引发新的数据库操作失败，无论在何种情况下，都应遵循“按顺序、显式关闭”的原则。
问题2：在使用连接池（如HikariCP）时，调用 connection.close() 会真的关闭数据库连接吗？
解答： 不会，在连接池的机制中，connection.close() 的语义被“重载”了，它不再是销毁一个物理TCP连接，而是将这个连接对象的使用权交还给连接池，连接池会回收这个连接，进行必要的重置（如回滚未提交的事务、清除会话状态等），然后将其放入空闲队列，等待下一次的借用，这正是连接池提升性能的核心所在——通过复用物理连接，避免了频繁建立和断开连接的高昂成本，物理连接的真正关闭由连接池自身根据配置策略（如最大空闲时间、连接生命周期等）来管理。
【版权声明】：本站所有内容均来自网络，若无意侵犯到您的权利，请及时与我们联系将尽快删除相关内容!
发表回复