前言：

java语言中由于有垃圾回收机制，因此大大解放了程序员的工作量，不再需要担心自己忘记释放不用的内存而导致内存泄露这样尴尬的事情了，当我们高呼gc万岁的时候，还是会发现在很多场景需要我们做一些手动close，或recycler。下面就这个问题进行总结。

1.有gc为什么还需要手动释放资源？

1)gc只能释放内存资源，而不能释放与内存无关资源。

2)gc回收具有不确定性，你根本不知道它什么时候会回收，而对于需要程序员手动回收的资源往往具有这样的特点：资源开销大，不用需要立即释放；或者资源是系统唯一的，不释放会导致别的程序也无法使用该资源。那对于具有这些特点的资源就必须保证不使用后能够立即释放出这部分资源，而不能把这件事情交给一个具有不确定性的gc来完成。

3)有人可能会说java IO流资源虽然不能被gc直接释放，但可以利用finalizer机制来释放非java资源，事实上java也确实在IO流的一些类中这么做了，如下：

/** * 该段代码摘自FileInputStream源码，jdk版本1.8 */

protected void finalize() throws IOException {

if ((fd != null) && (fd != FileDescriptor.in)) {

/* if fd is shared, the references in FileDescriptor * will ensure that finalizer is only called when * safe to do so. All references using the fd have * become unreachable. We can call close() */

close();

}

}

但是请注意，这仅仅是api程序员的严谨，防止由于我们这些程序员的大意忘记手动close资源，这依旧不是我们不手动调用close方法释放资源的借口。因为第一finalize的执行时机是在gc前，而gc具有时间不确定性，所以finalize执行时间也不具有确定性，对于需要及时回收的资源finalize无法保证及时。第二，finalize不是析构函数，jvm也根本就不能保证finalize一定会执行，那么就更不能依赖finalizer机制释放资源了。

2.需手动释放的常见资源

1)java IO流资源

2)jdbc资源(Connection，PrepareStatement，ResultSet)

3)android中的bitmap资源

3.资源关闭顺序问题

单个资源关闭往往没什么可说的，直接关闭即可，但在java很多类体系中往往存在依赖关系和资源装饰关系，这个时候就有关闭先后问题，否则还会引发异常

1)先开后关原则(燃气灶原则，恕我取了一个这么难听的名字)

这个原则很像生活中的一件事情，那就是使用燃气灶。使用燃气灶的时候我们都是先开气阀，再打开燃气灶的开关，做晚饭我们则先关闭燃气灶开关，最后再关上气阀。(电脑主机和显示器的开关顺序也满足这个原则，开机先开显示器后开主机，关机先关主机后关显示器，别问我为什么，问你们微机老师去)

jdbc资源的开关顺序如下：

先打开Connection资源，再打开PrepareStatement资源，最后打开ResultSet资源。使用完毕后先调用ResultSet的close方法，再调用PrepareStatement的close方法，最后调用Connection的close方法。

java IO流资源的开关顺序如下：

我们一般先打开一个输入流进行读取操作，然后将读取的数据写入输出流中，关闭时按照上面的原则，则应该先关输出流，然后关闭输入流。但是，我们发现在java io流关闭操作中，即使顺序反了也不会出现异常。因为我们关闭流的时机是在读写完成之后，并且输出流和输入流一般用一个中间buff数组做数据传递关联，并不像jdbc中资源之间的强依赖关联，所以即使关闭一个，另一个并不受影响。

2)由外到内原则(洋葱原则，又一个难听的名字，%>_

如果资源存在包装嵌套关系，则先关闭外层，后关闭内层的。

java io流中，处理流装饰节点流，我们应该先关闭装饰流，再关闭节点流。原则上是这样，但是我们发现这样反而会出现程序异常，因为java api上已经帮我们做了这样的事情。就是在处理流的close方法中调用了节点流的close方法。因此对java io流资源，如果是处理流，我们只需要调用处理流的close方法即可