这篇文章简要概述了Java 7中引入的称为自动资源管理或ARM的新功能。 文章探讨了ARM如何减少开发人员为有效释放分配的资源的JVM堆而必须编写的代码。

Java编程语言中编程的最甜蜜之处之一是对象取消分配的自动处理。 在Java世界中，这通常被称为垃圾收集。 基本上，这意味着开发人员不必担心取消分配其代码分配的对象。 开发人员使用完该对象后，他便可以使对该对象的所有引用无效，然后该对象就有资格进行垃圾回收。

但是，垃圾收集有其另一面。 与C / C ++中的编码器完全控制内存分配和取消分配（malloc，free，new，delete等）不同，在Java中，开发人员对对象的取消分配过程没有明显的控制。 JVM管理未使用对象的垃圾回收过程，而运行一个垃圾回收周期实际上取决于JVM的想法。 确实，有诸如System.gc（）或Runtime.getRuntime（）。gc（）之类的方法调用，它们指示将运行垃圾回收，但是这些方法仅用于提醒JVM：“也许您需要运行垃圾现在收集，只是一个建议，没有压力！”。 JVM被完全授权忽略这些请求，并且被编码为仅在真正合适时运行垃圾回收。 因此，在实践中，始终建议开发人员不要相信System.gc（）或Runtime.getRuntime（）。gc（）将触发完整的垃圾回收，从而不要构建其程序逻辑。

无可否认，自动垃圾收集为提高开发人员的生产力做了多少工作。 但是，在某些极端情况下，垃圾回收不足以保持“干净”堆，其中没有未使用的对象。 尤其是当对象处理由底层操作系统提供服务的某种形式的本机资源时。 这些对象包括但不限于IO流，数据库连接等。对于此类对象，开发人员必须明确释放资源。 通常，这些是通过try-catch块完成的。

让我们看一个小示例，该示例在完成流处理之后关闭InputStream：

InputStream in = null;try
{in = new FileInputStream(new File("test.txt");//do stuff with in
}
catch(IOException ie)
{//SOPs
}
finally
{//do cleanup
}

以上看起来不错，干净； 但是，一旦我们尝试通过finally块中的in.close（）关闭输入流，就需要用try-catch块将其包围，该块捕获已检查的异常IOException。 因此，代码示例将转换为：

InputStream in = null;try
{in = new FileInputStream(new File("test.txt"));//do stuff with in
}
catch(IOException ie)
{//SOPs
}
finally
{try{in.close();}catch(IOException ioe){//can't do anything about it}
}