如果关闭基础流，是否真的存在资源泄漏？

Question

我在其中一个程序上运行了动态代码分析工具，并且此模式被标识为资源泄漏：

...
FileInputStream fileInputStream = new FileInputStream(file);
try {
    data = someMethod(new BufferedInputStream(fileInputStream));
    // Assume that someMethod(InputStream) internally reads the stream
    // until BufferedInputStream.read() returns -1.
    ...
}
finally {
    ...
    try {
        fileInputStream.close();
    } catch (IOException e) {
        ...
    }
}

具体来说，分析工具将new BufferedInputStream(...)调用标记为资源泄漏，因为它永远不会关闭。 但是，在此模式下，基础流fileInputStream关闭，并且BufferedInputStream超出范围。

注意：最初发布问题时，我没有明确说明，但我意识到这不是“最佳”实施。 但是，如果这里不存在实际的资源泄漏，那么我们不太可能会为该模式的所有实例搜寻我们的旧代码库并关闭外部流，或用更新的结构（例如try-with-resources）替换它们-即，“如果它没有损坏，请不要修复它。”

在这种情况下，这实际上是资源泄漏吗？

Answer 1

这不太可能是实际的资源泄漏，但是编写这样的代码绝对不是最佳实践。

通常，您应该始终在最外部的流上调用close ，这会波动到内部的流。

如果您使用的是Java 7，则可以使用新的try-with-resources语法，完全避免使用finally块。

相关： try-with-resources语句

Answer 2

在这种情况下，没有资源泄漏。 但是，关闭（或同样）关闭BufferedInputStream的成本很小，因此添加（严格）不必要的关闭以使分析工具满意是最简单的。

典型的静态分析工具正在代码中寻找指示错误的结构模式。 在这种情况下，模式匹配方法会导致资源泄漏的误报。

Answer 3

因为Java没有解构函数，所以超出范围的对象不一定会关闭流。 Java确实有终结器，但是不能保证会调用它们。 BufferedInputStream不一定会关闭。 但是，因为底层流是封闭的，所以我并不认为这很重要。

最好确保关闭流，但这可能并不重要。