FileSystems.getDefault().getPath()与Paths.get()和资源泄漏

Question

如果我使用FileSystems.getDefault().getPath()，它在FileSystems.getDefault()上保存资源。很少有像声纳、coverity这样的工具会产生高影响的资源泄漏问题。

如果我用Paths.get()替换它，那么所有这样的工具都会悄然接受，并且不会出现任何错误或资源泄漏的警告。

如果我们看到Paths.get()的实现，它实际上是在执行FileSystems.getDefault().getPath()。

我在这里的问题是，java如何处理Paths.get()的资源泄漏，因为代码完全相同，但是我们没有引用FileSystems.getDefault()显式关闭它？

Answer 1

你的工具报告的是假阳性。这是因为FileSystems.getDefault() ( FileSystem )返回的声明类型实现了Closeable。这意味着，理想情况下，您应该关闭它。但是，默认的文件系统是一个异常(它甚至抛出一个UnsupportedOperationException)。你是工具不能做出这种区分。

这种情况比你想象的要频繁。一些我经常看到的例子：

• 是Objects.requireNonNull的结果。输入按原样返回，但如果输入为AutoCloseable，则我的IDE将其视为新资源。
• 来自servlet请求的输入流或读取器，以及来自servet .

的输出流或写入器。

在某些情况下，工具和IDE可以是智能的。例如，如果我将一个变量声明为ByteArrayInputStream、ByteArrayOutputStream、StringReader或StringWriter，那么我的IDE就知道它们不需要关闭。但是，当我分别从InputStream、OutputStream、Reader或Writer等方法返回它们时，如果不关闭它们，IDE就会开始抱怨。

如果您知道这是一个假阳性，您可以使用@SuppressWarnings("resource")来忽略一些工具的警告。这通常适用于单变量：

@SuppressWarnings("resource") FileSystem defaultFS = FileSystems.getDefault();
Path path = defaultFS.getPath("foo");

然而，即使这样，有时您的工具也会抱怨，并且您必须抑制整个方法的资源警告。如果是这样的话，尽量保持您的方法(因此也就是警告抑制的范围)尽可能小；如果需要，将代码拆分到一个新的方法中。