未存变量的AutoCloseable资源是否需用try-with-resource？ResultSet需处理吗？

问题1：未存储到变量的AutoCloseable资源，是否必须用try-with-resources处理？ #

• 结论：不是强制要求，但从资源安全角度，强烈建议这么做。
• 解释：AutoCloseable接口的核心是确保资源能被正确释放，但如果不把它放到try-with-resources里，也不手动调用close()方法，资源大概率会发生泄漏——尤其是代码抛出异常时，手动的close()可能根本没机会执行。
  举个危险的反例：

  // 风险：这个AutoCloseable资源的close()不会被自动调用
  new MyAutoCloseableResource().doSomething();
  

  哪怕手动调用close()，可靠性也远不如try-with-resources：

  // 比上面好，但仍有风险——如果doSomething()抛出异常，close()不会执行
  MyAutoCloseableResource res = new MyAutoCloseableResource();
  res.doSomething();
  res.close();
  

  只有try-with-resources能保证不管是否发生异常，close()都会被调用，哪怕你不把资源存到变量里也可以这么写：

  // 推荐：即使不存变量，也用try-with-resources包裹
  try (new MyAutoCloseableResource()) {
      // 执行相关操作
  }
  

  当然，如果某个AutoCloseable资源的生命周期完全由框架或其他代码接管（比如依赖注入容器管理的资源），那你可能不需要自己处理，但这种情况属于少数特例。

问题2：Sql.query返回的ResultSet是否必须存入变量并用try-with-resources处理？ #

• 结论：取决于JDBC驱动实现和Sql对象的封装逻辑，但为了最大程度避免资源泄漏，强烈建议这么做。

• 解释：根据JDBC规范，当创建ResultSet的Statement或Connection被关闭时，ResultSet会被自动关闭。在你的现有代码中，外层的try (final Sql sql = ...)会关闭sql对象（假设它是Connection或Statement的包装），理论上会连带关闭query返回的ResultSet。
  但实际场景里存在几个隐患：

  1. 不同JDBC驱动的实现有差异，有些驱动可能不会立即关闭ResultSet，或者在ResultSet被缓存的场景下占用额外资源；
  2. 如果sql.query()返回的是自定义封装的ResultSet，它的关闭逻辑可能不依赖外层的Sql对象；
  3. 执行SET @x := 1这类非查询语句时，返回的ResultSet可能是空的，但它依然是AutoCloseable资源，需要被关闭。

  所以，哪怕ResultSet看起来"没用"，把它放到嵌套的try-with-resources里是更稳妥的做法：

  try (final Sql sql = ...) {
      try (final ResultSet ignored = sql.query("SET @x := 1")) {
          // 这里不需要操作ResultSet，只是确保它被正确关闭
      }
  }
  

  当然，如果你的Sql框架在执行这类非查询语句时，内部已经自动处理了ResultSet的关闭（比如很多ORM框架会这么做），那可能不需要额外操作，但如果是原生JDBC或者不确定框架行为的话，手动处理能彻底避免资源泄漏风险。

内容的提问来源于stack exchange，提问作者Xenos