Java 記憶體洩露的理解與解決過程

可能光說概念太抽象了，大家可以看一下這樣的例子：

Vector v = new  Vector( 10 );  
for  ( int  i = 1 ;i < 100 ; i ++ ){  
Object o = new  Object();  
v.add(o);  
o = null ;  
}

在這個例子中，程式碼棧中存在Vector 物件的引用 v 和 Object 物件的引用 o 。在 For 迴圈中，我們不斷的生成新的物件，然後將其新增到 Vector 物件中，之後將 o 引用置空。問題是當 o 引用被置空後，如果發生 GC ，我們建立的 Object 物件是否能夠被 GC 回收呢？答案是否定的。因為， GC 在跟蹤程式碼棧中的引用時，會發現 v 引用，而繼續往下跟蹤，就會發現 v 引用指向的記憶體空間中又存在指向 Object 物件的引用。也就是說盡管 o 引用已經被置空，但是 Object 物件仍然存在其他的引用，是可以被訪問到的，所以 GC 無法將其釋放掉。如果在此迴圈之後， Object 物件對程式已經沒有任何作用，那麼我們就認為此 Java 程式發生了記憶體洩漏。

儘管對於C/C++ 中的記憶體洩露情況來說， Java 記憶體洩露導致的破壞性小，除了少數情況會出現程式崩潰的情況外，大多數情況下程式仍然能正常執行。但是，在移動裝置對於記憶體和 CPU都有較嚴格的限制的情況下， Java 的記憶體溢位會導致程式效率低下、佔用大量不需要的記憶體等問題。這將導致整個機器效能變差，嚴重的也會引起丟擲 OutOfMemoryError ，導致程式崩潰。

一般情況下記憶體洩漏的避免

在不涉及複雜資料結構的一般情況下，Java 的記憶體洩露表現為一個記憶體物件的生命週期超出了程式需要它的時間長度。我們有時也將其稱為“物件遊離”。

例如：

public class FileSearch{  
      private byte [] content;  
      private File mFile;  
     public FileSearch(File file){  
      mFile = file;  
      }  
     public boolean hasString(String str){  
         int size = getFileSize(mFile);  
        content =  new  byte [size];  
         loadFile(mFile, content);  
         String s =  new String(content);  
         return s.contains(str);  
     }  
}

在這段程式碼中，FileSearch 類中有一個函式 hasString ，用來判斷文件中是否含有指定的字串。流程是先將mFile 載入到記憶體中，然後進行判斷。但是，這裡的問題是，將 content 宣告為了例項變數，而不是本地變數。於是，在此函式返回之後，記憶體中仍然存在整個檔案的資料。而很明顯，這些資料我們後續是不再需要的，這就造成了記憶體的無故浪費。

要避免這種情況下的記憶體洩露，要求我們以C/C++ 的記憶體管理思維來管理自己分配的記憶體。第一，是在宣告物件引用之前，明確記憶體物件的有效作用域。在一個函式內有效的記憶體物件，應該宣告為 local 變數，與類例項生命週期相同的要宣告為例項變數……以此類推。第二，在記憶體物件不再需要時，記得手動將其引用置空。

複雜資料結構中的記憶體洩露問題

在實際的專案中，我們經常用到一些較為複雜的資料結構用於快取程式執行過程中需要的資料資訊。有時，由於資料結構過於複雜，或者我們存在一些特殊的需求（例如，在記憶體允許的情況下，儘可能多的快取資訊來提高程式的執行速度等情況），我們很難對資料結構中資料的生命週期作出明確的界定。這個時候，我們可以使用Java 中一種特殊的機制來達到防止記憶體洩露的目的。

之前我們介紹過，Java 的 GC 機制是建立在跟蹤記憶體的引用機制上的。而在此之前，我們所使用的引用都只是定義一個“ Object o; ”這樣形式的。事實上，這只是 Java 引用機制中的一種預設情況，除此之外，還有其他的一些引用方式。通過使用這些特殊的引用機制，配合 GC 機制，就可以達到一些我們需要的效果。

Java中的幾種引用方式

Java中有幾種不同的引用方式，它們分別是：強引用、軟引用、弱引用和虛引用。下面，我們首先詳細地瞭解下這幾種引用方式的意義。

強引用

在此之前我們介紹的內容中所使用的引用 都是強引用，這是使用最普遍的引用。如果一個物件具有強引用，那就類似於必不可少的生活用品，垃圾回收器絕不會回收它。當記憶體空 間不足，Java 虛擬機器寧願丟擲 OutOfMemoryError 錯誤，使程式異常終止，也不會靠隨意回收具有強引用的物件來解決記憶體不足問題。

軟引用（SoftReference ）

SoftReference 類的一個典型用途就是用於記憶體敏感的快取記憶體。 SoftReference  的原理是：在保持對物件的引用時保證在  JVM  報告記憶體不足情況之前將清除所有的軟引用。關鍵之處在於，垃圾收集器在執行時可能會（也可能不會）釋放軟可及物件。物件是否被釋放取決於垃圾收集器的演算法 以及垃圾收集器執行時可用的記憶體數量。

弱引用（WeakReference ）

WeakReference 類的一個典型用途就是規範化對映（ canonicalized mapping ）。另外，對於那些生存期相對較長而且重新建立的開銷也不高的物件來說，弱引用也比較有用。關鍵之處在於，垃圾收集器執行時如果碰到了弱可及物件，將釋放  WeakReference  引用的物件。然而，請注意，垃圾收集器可能要執行多次才能找到並釋放弱可及物件。

虛引用（PhantomReference ）

PhantomReference 類只能用於跟蹤對被引用物件即將進行的收集。同樣，它還能用於執行  pre-mortem  清除操作。 PhantomReference  必須與  ReferenceQueue  類一起使用。需要  ReferenceQueue  是因為它能夠充當通知機制。當垃圾收集器確定了某個物件是虛可及物件時， PhantomReference  物件就被放在它的  ReferenceQueue  上。將  PhantomReference  物件放在  ReferenceQueue  上也就是一個通知，表明  PhantomReference  物件引用的物件已經結束，可供收集了。這使您能夠剛好在物件佔用的記憶體被回收之前採取行動。 Reference與 ReferenceQueue 的配合使用。

GC、 Reference 與 ReferenceQueue 的互動

String str  =   new  String( " hello " );  // ①   
ReferenceQueue < String >  rq  =   new  ReferenceQueue < String > ();  // ②   
WeakReference < String >  wf  =   new  WeakReference < String > (str, rq);  // ③   
str = null ;  // ④取消"hello"物件的強引用   
String str1 = wf.get();  // ⑤假如"hello"物件沒有被回收，str1引用"hello"物件  
// 假如"hello"物件沒有被回收，rq.poll()返回null   
Reference <?   extends  String >  ref = rq.poll();  // ⑥

在以上程式碼中，注意⑤⑥兩處地方。假如“hello ”物件沒有被回收 wf.get() 將返回“ hello ”字串物件， rq.poll() 返回 null ；而加入“ hello ”物件已經被回收了，那麼 wf.get() 返回 null ， rq.poll() 返回 Reference 物件，但是此 Reference 物件中已經沒有 str 物件的引用了 ( PhantomReference 則與WeakReference 、 SoftReference 不同 )。

引用機制與複雜資料結構的聯合應用

瞭解了GC 機制、引用機制，並配合上 ReferenceQueue ，我們就可以實現一些防止記憶體溢位的複雜資料型別。

例如，SoftReference 具有構建 Cache 系統的特質，因此我們可以結合雜湊表實現一個簡單的快取系統。這樣既能保證能夠儘可能多的快取資訊，又可以保證 Java 虛擬機器不會因為記憶體洩露而丟擲 OutOfMemoryError 。這種快取機制特別適合於記憶體物件生命週期長，且生成記憶體物件的耗時比較長的情況，例如快取列表封面圖片等。對於一些生命週期較長，但是生成記憶體物件開銷不大的情況，使用WeakReference 能夠達到更好的記憶體管理的效果。

package  com. *** .widget;  
    // : SoftHashMap.java    
    import  java.util. * ;   
    import  java.lang.ref. * ;   
    import  android.util.Log;  

    public   class  SoftHashMap  extends  AbstractMap  {   
      /**  The internal HashMap that will hold the SoftReference.  */    
      private   final  Map hash  =   new  HashMap();   
      /**  The number of "hard" references to hold internally.  */    
      private   final   int  HARD_SIZE;   
      /**  The FIFO list of hard references, order of last access.  */    
      private   final  LinkedList hardCache  =   new  LinkedList();   
      /**  Reference queue for cleared SoftReference objects.  */    
      private  ReferenceQueue queue  =   new  ReferenceQueue();   
      // Strong Reference number   
      public  SoftHashMap()  {  this ( 100 ); }    
      public  SoftHashMap( int  hardSize)  { HARD_SIZE  =  hardSize; }    

      public  Object get(Object key)  {   
       Object result  =   null ;   
        //  We get the SoftReference represented by that key    
       SoftReference soft_ref  =  (SoftReference)hash.get(key);   
        if  (soft_ref  !=   null )  {   
          //  From the SoftReference we get the value, which can be   
          //  null if it was not in the map, or it was removed in   
          //  the processQueue() method defined below    
        result  =  soft_ref.get();   
          if  (result  ==   null )  {   
            //  If the value has been garbage collected, remove the   
            //  entry from the HashMap.    
           hash.remove(key);   
         }   else   {   
            //  We now add this object to the beginning of the hard   
            //  reference queue.  One reference can occur more than   
            //  once, because lookups of the FIFO queue are slow, so   
            //  we don't want to search through it each time to remove   
            //  duplicates.   
              // keep recent use object in memory   
           hardCache.addFirst(result);   
            if  (hardCache.size()  >  HARD_SIZE)  {   
              //  Remove the last entry if list longer than HARD_SIZE    
             hardCache.removeLast();   
           }    
         }    
       }    
        return  result;   
     }    

      /**  We define our own subclass of SoftReference which contains   
      not only the value but also the key to make it easier to find   
      the entry in the HashMap after it's been garbage collected.  */    
      private   static   class  SoftValue  extends  SoftReference  {   
        private   final  Object key;  //  always make data member final    
        /**  Did you know that an outer class can access private data   
        members and methods of an inner class?  I didn't know that!   
        I thought it was only the inner class who could access the   
        outer class's private information.  An outer class can also   
        access private members of an inner class inside its inner   
        class.  */    
        private  SoftValue(Object k, Object key, ReferenceQueue q)  {   
          super (k, q);   
          this .key  =  key;   
       }    
     }    

      /**  Here we go through the ReferenceQueue and remove garbage   
      collected SoftValue objects from the HashMap by looking them   
      up using the SoftValue.key data member.  */    
      public   void  processQueue()  {   
       SoftValue sv;   
        while  ((sv  =  (SoftValue)queue.poll())  !=   null )  {   
            if (sv.get() ==   null ) {  
               Log.e( " processQueue " ,  " null " );  
           } else {  
               Log.e( " processQueue " ,  " Not null " );  
           }   
         hash.remove(sv.key);  //  we can access private data!   
         Log.e( " SoftHashMap " ,  " release  "   +  sv.key);  
       }    
     }    
      /**  Here we put the key, value pair into the HashMap using   
      a SoftValue object.  */    
      public  Object put(Object key, Object value)  {   
       processQueue();  //  throw out garbage collected values first    
       Log.e( " SoftHashMap " ,  " put into  "   +  key);  
        return  hash.put(key,  new  SoftValue(value, key, queue));   
     }    
      public  Object remove(Object key)  {   
       processQueue();  //  throw out garbage collected values first    
        return  hash.remove(key);   
     }    
      public   void  clear()  {   
       hardCache.clear();   
       processQueue();  //  throw out garbage collected values    
      hash.clear();   
    }    
     public   int  size()  {   
      processQueue();  //  throw out garbage collected values first    
       return  hash.size();   
    }    
     public  Set entrySet()  {   
       //  no, no, you may NOT do that!!! GRRR    
       throw   new  UnsupportedOperationException();   
    }   
  }