Java JDBC 怎样让 ResultSet 随语句自动关闭

把创建 ResultSet 的 Statement 或 PreparedStatement 放进 try-with-resources，语句关闭时会关闭它当前的结果集。日常查询中，我更倾向于再给 ResultSet 一个内层 try-with-resources：读取范围清楚，结果集先关闭，语句随后关闭，异常路径也不必手写一串 finally。

官方 JDBC 结果集说明：https://docs.oracle.com/en/java/javase/25/docs/api/java.sql/java/sql/ResultSet.html。这里讨论普通查询的资源作用域，不把自动关闭解释为自动提交或回滚事务。

看到 return ResultSet，我会先找语句在哪里结束

假设正在阅读一个查询辅助方法：它在 try 内创建语句，执行查询后直接返回 ResultSet。调用方以为拿到的是独立结果，随后才开始 next。让我警惕的不是 SQL 写得复杂，而是结果集的生产者已经离开资源作用域。

// 反例片段：返回表达式求值后，try 仍会先关闭语句
static java.sql.ResultSet unsafe(java.sql.Connection connection)
        throws java.sql.SQLException {
    try (var statement = connection.createStatement()) {
        return statement.executeQuery("SELECT id FROM job_queue");
    }
}

这个方法的问题是返回游标并没有转移底层资源生命周期。语句一关闭，当前 ResultSet 就随之关闭，调用方不能再把它当作可读取的活动结果。上面的例子是教学反例，不是从实际线上事故复制的代码。

自动联动关闭是真的，但我仍会显式声明读取范围

Statement.close 对当前结果集的联动关闭是 JDBC 契约，不是某个连接池的特殊功能。不过，只依赖语句作用域，也可能让已经读完的结果集继续存活到较大的代码块结束。我通常选择小范围内层 try，让“数据读取到哪里结束”直接出现在结构里。

还有一类容易误判的问题：在同一个 Statement 上再次执行查询，当前 ResultSet 也可能因该语句的执行方法而被隐式关闭。需要交错读取两份普通查询结果时，不能把一个 Statement 当成多个独立游标的容器。相关契约：https://docs.oracle.com/en/java/javase/25/docs/api/java.sql/java/sql/Statement.html。

按三条路径推演，而不是只看循环末尾

正常读完时，先离开结果集作用域，再离开语句作用域；读取中途提前 return 时，仍会先完成资源关闭，然后方法才把返回值交给调用者。读取字段或构造业务对象时抛异常，也不会跳过已成功初始化资源的关闭尝试。

如果 executeQuery 本身失败，内层结果集尚未成功初始化，但外层语句已经被纳入管理，仍需关闭。这个差别让我更愿意把参数绑定留在外层语句块中，查询和遍历留在内层结果集块中：每个失败位置对应哪个资源已经存在，一眼就能看出来。

返回普通值，别让活动游标逃出作用域

下面是可加入数据访问类的方法。前提是调用方提供有效 Connection，数据库已有 job_queue 表和 id、status 字段；此文不创建数据库、不执行查询，也不假定任何真实记录存在。

import java.sql.Connection;
import java.sql.PreparedStatement;
import java.sql.ResultSet;
import java.sql.SQLException;
import java.util.ArrayList;
import java.util.List;

public final class JobLookup {
    public static List findIds(Connection connection, String status)
            throws SQLException {
        var ids = new ArrayList();

        // 连接由调用方拥有，本方法只关闭自己创建的语句
        try (PreparedStatement statement = connection.prepareStatement(
                "SELECT id FROM job_queue WHERE status = ? ORDER BY id")) {
            statement.setString(1, status);

            // 结果集限定在读取块中，先于外层语句关闭
            try (ResultSet result = statement.executeQuery()) {
                while (result.next()) {
                    ids.add(result.getLong("id"));
                }
            }
        }
        // 返回脱离 JDBC 游标的值；关闭失败会抛出异常而不是正常返回
        return ids;
    }
}

该例假定 id 是非 NULL 的整数字段。若查询没有匹配记录，预期返回空列表；若存在三条匹配记录，预期列表含三项。这里不给出虚构 ID 或执行日志。大量结果不适合无上限全部装入内存，分页或流式消费需要另行约定，但无论选哪种，都要有明确的关闭责任。

我不会在这个方法里顺手关闭 connection，因为调用方可能还在同一个事务中执行后续操作。谁获取并拥有连接，谁管理其边界；如果框架托管连接或事务，还应遵守框架契约，不机械套一个更大的资源块。

业务异常与 close 异常，哪个会传出去

try-with-resources 按初始化的逆序关闭资源。已经有主体异常时，后续关闭异常通常作为 suppressed 附加到原异常，不应为了打印关闭失败而覆盖最初原因。主体正常而关闭失败时，关闭异常会让方法异常退出；不能把“循环跑完”当作方法必然成功返回。

我排查这类问题时会保留完整异常对象，而不是只记录 getMessage。下面的片段放在有合适日志对象的调用边界；方法本身仍直接抛 SQLException，让上层决定记录与重试策略。

// 调用边界片段：logger 为已有的 java.util.logging.Logger
try {
    List ids = JobLookup.findIds(connection, "READY");
} catch (SQLException error) {
    // 传入完整异常，保留堆栈、cause 与 suppressed 诊断信息
    logger.log(java.util.logging.Level.WARNING, "读取任务编号失败", error);
    throw error;
}

语言规范说明：https://docs.oracle.com/javase/specs/jls/se25/html/jls-14.html。即使一个 close 抛错，其他应关闭资源仍会被尝试关闭。这表示语言层面的关闭调用会继续，不表示驱动或网络故障下所有外部资源都已成功释放。

复查时我只盯住所有权与逃逸

我会先看 ResultSet 有没有被返回、保存到字段或交给异步任务；再看每个创建的语句有没有明确作用域；最后确认没有关闭借用连接、没有吞掉异常。若团队要补测试，可以覆盖正常结果、空结果、读取失败和关闭失败，并观察关闭调用及异常关联；这些是建议用例，本文没有实际运行测试。

读到最后一行会自动 close 吗？不要把结果耗尽当作资源作用域，仍使用显式管理。关闭 ResultSet 会顺便关闭语句吗？不要反向推断标题里的联动关系，本文方案明确管理两者。关闭资源等于提交事务吗？不是，事务成功与否必须另行处理。

对普通数据访问方法，我的取舍是返回普通值，把游标留在方法内部消费，用嵌套资源块清楚表达“结果集先结束、语句后结束”。需要向外提供流式读取时，则应设计专门的拥有者接口，不能只把一个 ResultSet 返回去就认为责任已经交接。