垃圾收集几乎是每个开发人员都喜爱的一个 Java 平台特性，它简化了开发，消除了所有种类的潜在代码错误。可尽管垃圾收集一般来说可以让您无需进行资源管理，有时候您还是必须自己进行一些内务处理。在本文中，Brian Goetz 讨论了垃圾收集的局限性，并指出了您必须自己做内务处理的场景。
小时候，父母总是叮嘱我们玩了玩具之后要收好。如果您仔细想想，其实这种唠叨并不过分，要保持整洁是因为存在实际的限制，房间里没有太多的空间，如果到处堆满了玩具，那么连走路都无处下脚了。
如果有了足够的空间，保持整洁就不是那么必要了。空间越多，就越不必要保持整洁。Arlo Guthrie 著名的民谣 Alice's Restaurant Massacre 说明了这一点：
他们住在教堂楼下的大厅，里面的椅子全都搬走了，剩下一个空荡荡的大房间，所以他们想，很长时间都不用把垃圾扔出去，有的是地方装垃圾……
无论如何，垃圾收集可以帮我们减轻内务整理方面的工作。
显式地释放资源
Java 程序中使用的绝大多数资源都是对象，垃圾收集在清理对象方面做得很好。因此，您可以使用任意多的 String。垃圾收集器最终无需您的干预就会算出它们何时失效，并收回它们使用的内存。
另一方面，像文件句柄和套接字句柄这类非内存资源必须由程序显式地释放，比如使用 close()、destroy()、shutdown() 或 release() 这样的方法来释放。有些类，比如平台类库中的文件句柄流实现，提供终结器（finalizer）作为安全保证，以便当垃圾收集器确定程序不再使用资源而程序却忘了释放资源时，终结器还可以来做这个释放工作。但是尽管文件句柄提供了终结器来在您忘记了时为您释放资源，最好还是在使用完之后显式地释放资源。这样做可以更早地释放资源，降低了资源耗尽的可能。
对于有些资源来说，一直等到终结（finalization）释放它们是不可取的。对于重要的资源，比如锁获取和信号量许可证，Lock 或 Semaphore 直到很晚都可能不会被垃圾收集掉。对于数据库连接这样的资源，如果您等待终结，那么肯定会消耗完资源。许多数据库服务器根据许可的容量，只接受一定数量的连接。如果服务器应用程序为每个请求都打开一个新的数据库连接，然后用完之后就不管了，那么数据库远远未到终结器关闭不再需要的连接，就会到达它的最高容量。
只限于一个方法的资源
多数资源都不会持续整个应用程序的生命周期，相反，它们只被用于一个活动的生命周期。当应用程序打开一个文件句柄读取文件以处理文档时，它通常读取文件后就不再需要文件句柄了。
在最简单的情况下，资源在同一个方法调用中被获取、使用和释放，比如清单 1 中的 loadPropertiesBadly() 方法：
清单 1. 不正确地在一个方法中获取、使用和释放资源 —— 不要这样做
public static Properties loadPropertiesBadly(String fileName)
throws IOException {
FileInputStream stream = new FileInputStream(fileName);
Properties props = new Properties();
props.load(stream);
stream.close();
return props;
}
不幸的是，这个例子存在潜在的资源泄漏。如果一切进展顺利，流将会在方法返回之前被关闭。但是如果 props.load() 方法抛出一个 IOException，那么流则不会被关闭（直到垃圾收集器运行其终结器）。解决方案是使用 try...finally 机制来确保流被关闭，而不管是否发生错误，如清单 2 所示：
清单 2. 正确地在一个方法中获取、使用和释放资源
public static Properties loadProperties(String fileName)
throws IOException {
FileInputStream stream = new FileInputStream(fileName);
try {
Properties props = new Properties();
props.load(stream);
return props;
}
finally {
stream.close();
}
}
注意，资源获取（打开文件）是在 try 块外面进行的；如果把它放在 try 块中，那么即使资源获取抛出异常，finally 块也会运行。不仅该方法会不适当（您无法释放您没有获取的资源），finally 块中的代码也可能抛出其自己的异常，比如 NullPointerException。从 finally 块抛出的异常取代导致块退出的异常，这意味着原来的异常丢失了，不能用于帮助进行调试。 并不总像看起来那么容易
使用 finally 来释放在方法中获取的资源是可靠的，但是当涉及多个资源时，很容易变得难以处理。下面考虑这样一个方法，它使用一个 JDBC Connection 来执行查询和迭代 ResultSet。该方法获得一个 Connection，使用它来创建一个 Statement，并执行 Statement 以得到一个 ResultSet。但是中间 JDBC 对象 Statement 和 ResultSet 具有它们自己的 close() 方法，并且当您使用完之后，应该释放这些中间对象。然而，进行资源释放的 “明显的” 方式并不起作用，如清单 3 所示：
清单 3. 不成功的释放多个资源的企图 —— 不要这样做
public void enumerateFoo() throws SQLException {
Statement statement = null;
ResultSet resultSet = null;
Connection connection = getConnection();
try {
statement = connection.createStatement();
resultSet = statement.executeQuery("SELECT * FROM Foo");
// Use resultSet
}
finally {
if (resultSet != null)
resultSet.close();
if (statement != null)
statement.close();
connection.close();
}
}
这个 “解决方案” 不成功的原因在于，ResultSet 和 Statement 的 close() 方法自己可以抛出 SQLException，这会导致后面 finally 块中的 close() 语句不执行。您在这里有几种选择，每一种都很烦人：用一个 try..catch 块封装每一个 close()，像清单 4 那样嵌套 try...finally 块，或者编写某种小型框架用于管理资源获取和释放。
清单 4. 可靠的释放多个资源的方法
public void enumerateBar() throws SQLException {
Statement statement = null;
ResultSet resultSet = null;
Connection connection = getConnection();
try {
statement = connection.createStatement();
resultSet = statement.executeQuery("SELECT * FROM Bar");
// Use resultSet
}
finally {
try {
if (resultSet != null)
resultSet.close();
}
finally {
try {
if (statement != null)
statement.close();
}
finally {
connection.close();
}
}
}
}
private Connection getConnection() {
return null;
}
几乎每一样东西都可以抛出异常
我们都知道应该使用 finally 来释放像数据库连接这样的重量级对象，但是我们并不总是这样细心，能够记得使用它来关闭流（毕竟，终结器会为我们做这件事，是不是？）。很容易忘记在使用资源的代码不抛出已检查的异常时使用 finally。清单 5 展示了针对绑定连接的 add() 方法的实现，它使用 Semaphore 来实施绑定，并有效地允许客户机等待空间可用：
清单 5. 绑定连接的脆弱实现 —— 不要这样做
public class LeakyBoundedSet<T> {
private final Set<T> set = ...
private final Semaphore sem;
public LeakyBoundedSet(int bound) {
sem = new Semaphore(bound);
}
public boolean add(T o) throws InterruptedException {
sem.acquire();
boolean wasAdded = set.add(o);
if (!wasAdded)
sem.release();
return wasAdded;
}
}
LeakyBoundedSet 首先等待一个许可证成为可用的（表示连接中有空间了），然后试图将元素添加到连接中。添加操作如果由于该元素已经在连接中了而失败，那么它会释放许可证（因为它不实际使用它所保留的空间）。
与 LeakyBoundedSet 有关的问题没有必要马上跳出：如果 Set.add() 抛出一个异常呢？如果 Set 实现中有缺陷，或者 equals() 或 hashCode() 实现（在 SortedSet 的情况下是 compareTo() 实现）中有缺陷，原因在于添加元素时元素已经在 Set 中了。当然，解决方案是使用 finally 来释放信号量许可证，这是一个很简单却容易被遗忘的方法。这些类型的错误很少会在测试期间暴露出来，因而成了定时炸弹，随时可能爆炸。清单 6 展示了 BoundedSet 的一个更加可靠的实现：
清单 6. 使用一个 Semaphore 来可靠地绑定 Set
public class BoundedSet<T> {
private final Set<T> set = ...
private final Semaphore sem;
public BoundedHashSet(int bound) {
sem = new Semaphore(bound);
}
public boolean add(T o) throws InterruptedException {
sem.acquire();
boolean wasAdded = false;
try {
wasAdded = set.add(o);
return wasAdded;
}
finally {
if (!wasAdded)
sem.release();
}
}
}
像 FindBugs这样的代码审查工具可以检测出不适当的资源释放的一些实例，比如在一个方法中打开一个流却不关闭它。
具有任意生命周期的资源
对于具有任意生命周期的资源，我们要回到 C 语言的时代，即手动地管理资源生命周期。在一个服务器应用程序中，客户机到服务器的一个持久网络连接存在于一个会话期间（比如一个多人参与的游戏服务器），每个用户的资源（包括套接字连接）在用户退出时必须被释放。好的组织是有帮助的；如果对每个用户资源的角色引用保存在一个 ActiveUser 对象中，那么它们就可以在 ActiveUser 被释放时（无论是显式地释放，还是通过垃圾收集而释放）而被释放。
具有任意生命周期的资源几乎总是存储在一个全局集合中（或者从这里可达）。要避免资源泄漏，因此非常重要的是，要识别出资源何时不再需要了并可以从这个全局集合中删除了。（以前的一篇文章 “用弱引用堵住内存泄漏” 给出了一些有用的技巧。）此时，因为您知道资源将要被释放，任何与该资源关联的非内存资源也可以同时被释放。
资源所有权
确保及时的资源释放的一个关键技巧是维护所有权的一个严格层次结构，其中的所有权具有释放资源的职责。如果应用程序创建一个线程池，而线程池创建线程，线程是程序可以退出之前必须被释放的资源。但是应用程序不拥有线程，而是由线程池拥有线程，因此线程池必须负责释放线程。当然，直到它本身被应用程序释放之后，线程池才能释放线程。
维护一个所有权层次结构有助于不至于失去控制，其中每个资源拥有它获得的资源并负责释放它们。这个规则的结果是，每个不能由垃圾收集单独收集的资源（即这样的资源，它直接或间接拥有不能由垃圾收集释放的资源）必须提供某种生命周期支持，比如 close() 方法。
终结器
如果说平台库提供终结器来清除打开的文件句柄，这大大降低了忘记显式地关闭这些句柄的风险，为什么不更多地使用终结器呢？原因有很多，最重要的一个原因是，终结器很难正确编写（并且很容易编写错）。终结器不仅难以编写正确，终结的定时也是不确定的，并且不能保证终结器最终会运行。并且终结还为可终结对象的实例化和垃圾收集带来了开销。不要依赖于终结器作为释放资源的主要方式。
结束语
垃圾收集为我们做了大量可怕的资源清除工作，但是有些资源仍然需要显式的释放，比如文件句柄、套接字句柄、线程、数据库连接和信号量许可证。当资源的生命周期被绑定到特定调用帧的生命周期时，我们通常可以使用 finally 块来释放该资源，但是长期存活的资源需要一种策略来确保它们最终被释放。对于任何一个这样的对象，即它直接或间接拥有一个需要显式释放的对象，您必须提供生命周期方法 —— 比如 close()、release()、destroy() 等 —— 来确保可靠的清除。