前言：

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