我在我们的一个程序上运行了动态代码分析工具,该模式被识别为资源泄漏:
...
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)替换它们——即,“如果它没有坏,就不要修理它。”
鉴于这种情况,这实际上是资源泄漏吗?
最佳答案
这不太可能是实际的资源泄漏,但像这样编写代码绝对不是最佳实践。
一般来说,您应该始终在最外层流上调用close
,这将波及到内部流。
如果您使用的是 Java 7,则可以使用新的 try-with-resources 语法并完全避免使用 finally block 。
关于java - 如果我关闭底层流,真的会发生资源泄漏吗?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/18746513/