什么是关闭Java中嵌套流的最佳,最全面的方法?例如,考虑设置:
FileOutputStream fos = new FileOutputStream(...) BufferedOS bos = new BufferedOS(fos); ObjectOutputStream oos = new ObjectOutputStream(bos);
我知道需要对关闭操作进行保险(可能通过使用finally子句)。我想知道的是,是否有必要明确确保嵌套流已关闭,还是足以确保关闭外部流(oos)?
我注意到的一件事,至少在处理此特定示例时,是内部流似乎只抛出FileNotFoundExceptions。这似乎暗示着从技术上讲,如果它们失败了,就不必担心将其关闭。
这是一位同事写的:
从技术上讲,如果正确实施,关闭最外面的流(oos)应该就足够了。但是实现似乎有缺陷。
示例:BufferedOutputStream继承自FilterOutputStream的close(),后者将其定义为:
155 public void close() throws IOException { 156 try { 157 flush(); 158 } catch (IOException ignored) { 159 } 160 out.close(); 161 }
但是,如果flush()由于某种原因引发运行时异常,则永远不会调用out.close()。因此,大多数情况下担心关闭FOS(使文件保持打开状态)似乎是“最安全的”(但丑陋)。
当你绝对需要确保关闭嵌套流时,什么才是最好的选择?
是否有任何官方Java / Sun文档对此进行了详细介绍?
我通常会执行以下操作。首先,定义一个基于模板方法的类来处理try / catch混乱
import java.io.Closeable; import java.io.IOException; import java.util.LinkedList; import java.util.List; public abstract class AutoFileCloser { // the core action code that the implementer wants to run protected abstract void doWork() throws Throwable; // track a list of closeable thingies to close when finished private List<Closeable> closeables_ = new LinkedList<Closeable>(); // give the implementer a way to track things to close // assumes this is called in order for nested closeables, // inner-most to outer-most protected final <T extends Closeable> T autoClose(T closeable) { closeables_.add(0, closeable); return closeable; } public AutoFileCloser() { // a variable to track a "meaningful" exception, in case // a close() throws an exception Throwable pending = null; try { doWork(); // do the real work } catch (Throwable throwable) { pending = throwable; } finally { // close the watched streams for (Closeable closeable : closeables_) { if (closeable != null) { try { closeable.close(); } catch (Throwable throwable) { if (pending == null) { pending = throwable; } } } } // if we had a pending exception, rethrow it // this is necessary b/c the close can throw an // exception, which would remove the pending // status of any exception thrown in the try block if (pending != null) { if (pending instanceof RuntimeException) { throw (RuntimeException) pending; } else { throw new RuntimeException(pending); } } } } }
请注意“待处理”异常-处理关闭期间抛出的异常会掩盖我们可能真正关心的异常的情况。
最后尝试首先从任何装饰的流的外部关闭,因此,如果你有包裹FileWriter的BufferedWriter,我们将尝试先关闭BuffereredWriter,如果失败,仍然尝试关闭FileWriter本身。(请注意,Closeable的定义要求close()在流已关闭的情况下忽略该调用)
你可以按如下方式使用上述类:
try { // ... new AutoFileCloser() { @Override protected void doWork() throws Throwable { // declare variables for the readers and "watch" them FileReader fileReader = autoClose(fileReader = new FileReader("somefile")); BufferedReader bufferedReader = autoClose(bufferedReader = new BufferedReader(fileReader)); // ... do something with bufferedReader // if you need more than one reader or writer FileWriter fileWriter = autoClose(fileWriter = new FileWriter("someOtherFile")); BufferedWriter bufferedWriter = autoClose(bufferedWriter = new BufferedWriter(fileWriter)); // ... do something with bufferedWriter } }; // .. other logic, maybe more AutoFileClosers } catch (RuntimeException e) { // report or log the exception }
使用这种方法,你不必担心尝试/捕获/最终再次处理关闭文件的麻烦。
如果这对于你的使用来说太重了,至少要考虑遵循try / catch及其使用的“ pending”变量方法。
在Java 7时代,尝试资源是必经之路。如先前的几个答案中所述,关闭请求从最外面的流传播到最里面的流。因此,只需要一次关闭即可。
try (ObjectInputStream ois = new ObjectInputStream(new FileInputStream(f))) { // do something with ois }
但是,这种模式存在问题。try-with-resources无法识别内部的FileInputStream,因此,如果ObjectInputStream构造函数引发异常,则FileInputStream永远不会关闭(直到垃圾收集器到达它为止)。解决方法是…
try (FileInputStream fis = new FileInputStream(f); ObjectInputStream ois = new ObjectInputStream(fis)) { // do something with ois }
这不那么优雅,但是更强大。这是否实际上是一个问题,将取决于在构造外部对象期间可以引发哪些异常。ObjectInputStream会抛出IOException,它很可能由应用程序处理而不会终止。许多流类仅抛出未经检查的异常,这很可能导致应用程序终止。