【java】手动释放资源问题

转载请注明出处：http://blog.csdn.net/u012250875/article/details/78365112

前言：

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方法便可