這篇文章簡要概述了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}
}