Java中请优先使用try-with-resources而非try-finally
Java中请优先使用try-with-resources而非try-finally
Java库包含了很多需要手工调用close方法来关闭的资源。比如说InputStream、OutputStream及java.sql.Connection。关闭资源常常会被客户端所忽视，这会导致可怕的性能问题。虽然很多资源使用了终结器来作为安全网，不过终结器却并不那么尽如人意。
从历史上来看，try-finally语句是确保资源会被恰当关闭的最佳方式，即便在遇到异常或是返回语句时亦如此：
// try-finally - No longer the best way to close resources!
static String firstLineOfFile(String path) throws IOException { BufferedReader br = new BufferedReader(new FileReader(path)); try {
return br.readLine();
} finally {
br.close();
}
}
看起来还不错，不过当添加了第二个资源时情况就变得有些糟糕了：
// try-finally is ugly when used with more than one resource!
static void copy(String src, String dst) throws IOException {
InputStream in = new FileInputStream(src);
try {
OutputStream out = new FileOutputStream(dst);
try {
byte[] buf = new byte[BUFFER_SIZE];
int n;
while ((n = in.read(buf)) >= 0)
out.write(buf, 0, n);
} finally {
out.close();
}
} finally {
in.close();
}
}
虽然难以相信，但即便是优秀的程序员很多时候也会编写这样的代码。对于初学者来说，我在Java Puzzlers [Bloch05]的第88页指出了问题，但多年来没人注意到。事实上，2007年，在Java库中对close方法的使用有2/3是错误的。
甚至使用try-finally语句关闭资源的正确代码（如前面两个代码示例所示）也存在一些小问题。try块与finally块中的代码都可以抛出异常。比如说，在firstLineOfFile方法中，由于底层物理设备的失败，调用readLine可能会抛出异常，调用close也会因同样的原因而失败。在这些情况下，第二个异常完全会掩盖掉第一个。在异常堆栈中没有对第一个异常的记录信息，这会极大增加真实系统的调试复杂度——通常来说，第一个异常才是问题诊断的关键所在。虽然可以通过编写代码来压制第二个异常，从而保留第一个异常信息，但没人会这么做，因为太麻烦了。
所有这些问题都随着Java 7引入try-with-resources语句得到了解决[JLS, 14.20.3]。要想使用该结构，资源必须要实现AutoCloseable接口，该接口包含了唯一一个返回void类型的close方法。Java库与第三方库中的很多类和接口现在都实现或是继承了AutoCloseable。如果编写一个用于表示资源的类，它必须要关闭，那么这个类就应该实现AutoCloseable。
如下代码使用try-with-resources改写了上面第一个示例：
// try-with-resources - the the best way to close resources!
static String firstLineOfFile(String path) throws IOException {
try (BufferedReader br = new BufferedReader(
new FileReader(path))) {
return br.readLine();
}
}
如下代码使用try-with-resources改写了上面第二个示例：
// try-with-resources on multiple resources - short and sweet
static void copy(String src, String dst) throws IOException {
try (InputStream in = new FileInputStream(src);
OutputStream out = new FileOutputStream(dst)) {
byte[] buf = new byte[BUFFER_SIZE];
int n;
while ((n = in.read(buf)) >= 0)
out.write(buf, 0, n);
}
}
try-with-resources版本不仅代码更简洁，可读性比原来的要好，而且提供了更好的问题诊断能力。考虑firstLineOfFile方法。如果readLine调用与（不可见的）close方法都抛出了异常，那么后者的异常就会被前者压制住。事实上，多个异常都会被压制住，从而保留你实际想看的那个异常。这些被压制的异常并不是被丢弃掉；他们会在堆栈中打印出来，并且有相应的符号表示他们被压制了。你还可以通过编程的方式通过getSuppressed方法来访问这些异常，该方法是在Java 7中被添加到Throwable中的。
你可以将catch从句放到try-with-resources语句上，就像常规的try-finally语句一样。这样就可以在处理异常的同时又不会在另一个嵌套层次上搞乱代码了。举个例子，下面是不抛出异常的firstLineOfFile方法版本，不过如果无法打开文件或是无法读取文件，那么它会接收一个默认值来返回：
// try-with-resources with a catch clause
static String firstLineOfFile(String path, String defaultVal) {
try (BufferedReader br = new BufferedReader(
new FileReader(path))) {
return br.readLine();
} catch (IOException e) {
return defaultVal;
}
}
很显然，在处理需要关闭的资源时，请优先使用try-with-resources而非try-finally。结果代码更短、也更清晰，它所生成的异常也更加有用。try-with-resources语句使得编写使用了必须要关闭的资源的代码更加轻松，而这是try-finally所做不到的。
经过查询源码：InputStream / BufferReader等，这些类都已经实现了对AutoClosed类的实现。
大娃总结：
尽可能的使用这个语法，昨天自己写的程序里还有两个try finally 语句，今天就体验到了便捷性。
try-with-resource语法：
try (需要关闭的resource资源定义在这里) {
相关的操作写这里
}
