摘要：自动化资源管理（即ARM）能力是Java 7特有的，目前使用Java 6的朋友在编译时很多库都需要重新编译以适应Java 6的需要。其目的在于当遇到错误或是成功执行完代码块后能够轻松处理好外部资源。
曾在《Java 7的最新特性更新、代码示例及性能测试》中为大家介绍过Project Coin的项目。Project Coin的一个突出特点就是具备了自动化资源管理（即ARM）能力，这个能力是Java 7特有的，目前使用Java 6的朋友在编译时很多库都需要重新编译以适应Java 6的需要。其目的在于当遇到错误或是成功执行完代码块后能够轻松处理好外部资源。其最初实现位于Open JDK中。考虑如下繁琐的文件拷贝操作，代码来自于Java Bytestream教程：
上面不仅有大量的样版代码，而且InputStream.close()的文档表明它会抛出IOException（OutputStream也存在类似的异常，无论何种情况，要想成功编译这些代码，要么在外面加上catch块，要么将异常继续往外抛）。
try-catch-finally块的语义范围还要求变量FileInputStream in与FileOutputStream out声明在块的外面（如果定义在try块内，那么catch块与finally块就访问不到了）。
为了减少上面这些样版代码并且收紧块中所用的资源范围，Java语言在try块中新增了一些内容。最初的try-with-resources块（或者叫做ARM块）规范已经拥有实现了，随后该规范被纳入到JDK 7 build 105中。
新的接口java.lang.AutoCloseable被加到了提案API中，它只定义了一个会抛出Exception的方法close()。该接口是java.io.Closeable的父接口，这意味着所有的InputStream与OutputStream都会自动享受到该行为所带来的好处。此外，FileLock与ImageInputStream也实现了AutoCloseable接口。
这样，上面的代码就可以这样来写：
在try块的末尾，无论是正常结束还是抛出了异常，out与in资源都会自动调用close()方法。此外，与之前示例不同的是out.close()与in.close()保证会执行（在之前的示例中，一旦in.close()方法抛出了异常，随后的out.close()方法就没有机会执行了）。
关于这种方式，还有一些微妙之处值得我们注意：
◆如上代码所示，在资源部分中，最后一个资源后面是不允许使用分号的。
◆资源块使用()分隔，而不是常见的{}，以此将其与现有的try块分隔开来。如果存在资源块，那么里面必须要包含一个或多个资源定义语句。
◆每个资源定义具有如下形式：type var = expression;在资源块中不能使用通常的语句。
◆资源都是隐式final的，也就是说即便没有使用final，这些资源也都是final的。如果尝试为资源变量赋值会得到一个编译期错误。
◆资源必须是AutoCloseable的子类型，如果不是的话会得到一个编译期错误。
◆资源关闭的顺序与定义的顺序正好相反。换句话说，在上面的代码示例中，out.close()要先于in.close()得到调用。这么做可以构建嵌套的流，然后从外向内关闭流，这要比按顺序关闭更好（也就是说，可以在底层的流关闭前先清空缓存）。
◆每个块可以生成n+1个异常，n是资源的数量。这出现在代码主体抛出了异常，然后每个资源关闭语句也都抛出异常的情况下。在这种情况下，代码主体的异常将被抛出，但其他的异常将会被添加到异常的抑制列表（suppressed exception list）中。可以通过getSuppressedExceptions()方法访问这些异常信息。
◆异常堆栈追踪信息可以带有Suppressed前缀：在这些情况下，序列化的Throwable格式也有所不同（如果Java 6客户端调用了远程Java 7运行时中的服务会出现这个问题，反之亦然）。
◆javax.swing与java.sql目前并不会加入到ARM中；类需要继承AutoCloseable才能为ARM所用。JDBC 4.1如果能够成为JDK 7的一部分，那么它也将支持ARM，但具体时间尚未确定。
能够移除Java开发者每天都要编写的样版代码对生产力的提升是个促进，虽然JDK 7具备了这种能力，但有时需要在编写代码前利用这种能力。很多库都需要重新编译以适应Java 6的需要，无论何时，只要使用了自动化资源管理，那么它就只能用于使用-target 7编译的代码。等到Java 6寿终正寝，并且Java 8发布后，使用ARM就会成为自然而然的事情了。
相关链接：
