是否需要关闭S3Object？未在finally中关闭的影响及代码资源泄漏检查

1. 是否需要关闭S3Object？ #

必须手动关闭S3Object。它不是普通的数据对象，持有底层HTTP连接、网络输入流等稀缺资源，这些资源无法被JVM垃圾回收自动释放，必须显式调用close()方法回收。

2. 未在finally中关闭S3Object的影响 #

如果不通过finally块确保S3Object被关闭，会引发以下问题：

• 连接池耗尽：AWS SDK的HTTP连接池容量有限，未关闭的S3Object会持续占用连接，后续请求可能因无法获取连接而阻塞或抛出超时异常。
• 内存泄漏：未关闭的输入流会长期占用内存，运行时间久了可能触发OutOfMemoryError。
• 服务端资源浪费：S3服务端会维持未关闭的连接，可能触发服务端的连接数限制，影响其他请求的正常处理。

3. 提供的代码是否存在资源泄漏？ #

这段代码存在潜在的资源泄漏问题，问题出在readFromS3(obj: S3Object)方法中：

• 方法内创建的BufferedReader和InputStreamReader没有被显式关闭。虽然S3Object的close()最终会关闭底层的ObjectContent流，但如果读取过程中出现异常，或者流的层级关系导致关闭不彻底，仍会造成资源泄漏。
• Java 8的Stream（由reader.lines()生成）若未正确关闭，也可能持有底层流资源。

优化后的代码示例 #

可以用Scala的Using工具类自动管理资源，确保流被正确关闭：

import scala.util.Using

class S3ClientClass {
  lazy val amazonS3Client = this.getS3Client()
  private def getS3Client() = {
    AmazonS3ClientBuilder
      .standard()
      .withRegion(Regions.AP_NORTHEAST_1)
      .build()
  }

  def readFromS3(s3Bucket: String, filepath: String): String = {
    var s3object: S3Object = null
    try {
      s3object = amazonS3Client.getObject(s3Bucket, filepath)
      readFromS3(s3object)
    }
    finally {
      if (s3object != null) {
        s3object.close()
      }
    }
  }
 
  def readFromS3(obj: S3Object): String = {
    Using.resource(new BufferedReader(new InputStreamReader(obj.getObjectContent))) { reader =>
      reader.lines().collect(Collectors.joining())
    }
  }
}

也可以在方法内部用try-finally手动关闭流，确保资源被回收。

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