本文轉自網際網路，侵刪

本系列文章將整理到我在GitHub上的《Java面試指南》倉庫，更多精彩內容請到我的倉庫裡檢視

https://github.com/h2pl/Java-Tutorial

喜歡的話麻煩點下Star哈

文章將同步到我的個人部落格：

www.how2playlife.com

本文是微信公眾號【Java技術江湖】的《深入理解JVM虛擬機器》其中一篇，本文部分內容來源於網路，為了把本文主題講得清晰透徹，也整合了很多我認為不錯的技術部落格內容，引用其中了一些比較好的部落格文章，如有侵權，請聯絡作者。

該系列博文會告訴你如何從入門到進階，一步步地學習JVM基礎知識，並上手進行JVM調優實戰，JVM是每一個Java工程師必須要學習和理解的知識點，你必須要掌握其實現原理，才能更完整地瞭解整個Java技術體系，形成自己的知識框架。

為了更好地總結和檢驗你的學習成果，本系列文章也會提供每個知識點對應的面試題以及參考答案。

如果對本系列文章有什麼建議，或者是有什麼疑問的話，也可以關注公眾號【Java技術江湖】聯絡作者，歡迎你參與本系列博文的創作和修訂。

實戰記憶體溢位異常

大家好，相信大部分Javaer在code時經常會遇到原生程式碼執行正常，但在生產環境偶爾會莫名其妙的報一些關於記憶體的異常，StackOverFlowError,OutOfMemoryError異常是最常見的。今天就基於上篇文章JVM系列之Java記憶體結構詳解講解的各個記憶體區域重點實戰分析下記憶體溢位的情況。在此之前，我還是想多餘累贅一些其他關於物件的問題，具體內容如下:

文章結構：
物件的建立過程
物件的記憶體佈局
物件的訪問定位
實戰記憶體異常

1 . 物件的建立過程

關於物件的建立，第一反應是new關鍵字，那麼本文就主要講解new關鍵字建立物件的過程。

Student stu =new Student("張三"，"18");

就拿上面這句程式碼來說，虛擬機器首先會去檢查Student這個類有沒有被載入，如果沒有，首先去載入這個類到方法區，然後根據載入的Class類物件建立stu例項物件，需要注意的是，stu物件所需的記憶體大小在Student類載入完成後便可完全確定。記憶體分配完成後，虛擬機器需要將分配到的記憶體空間的例項資料部分初始化為零值,這也就是為什麼我們在編寫Java程式碼時建立一個變數不需要初始化。緊接著，虛擬機器會對物件的物件頭進行必要的設定，如這個物件屬於哪個類，如何找到類的後設資料(Class物件),物件的鎖資訊，GC分代年齡等。設定完物件頭資訊後，呼叫類的建構函式。
其實講實話，虛擬機器建立物件的過程遠不止這麼簡單，我這裡只是把大致的脈絡講解了一下，方便大家理解。

2 . 物件的記憶體佈局

剛剛提到的例項資料，物件頭，有些小夥伴也許有點陌生，這一小節就詳細講解一下物件的記憶體佈局,物件建立完成後大致可以分為以下幾個部分:

物件頭
例項資料
對齊填充

物件頭: 物件頭中包含了物件執行時一些必要的資訊，如GC分代資訊，鎖資訊，雜湊碼，指向Class類元資訊的指標等，其中對Javaer比較有用的是 鎖資訊與指向Class物件的指標，關於鎖資訊，後期有機會講解併發程式設計JUC時再擴充套件，關於指向Class物件的指標其實很好理解。比如上面那個Student的例子，當我們拿到stu物件時，呼叫Class stuClass=stu.getClass();的時候，其實就是根據這個指標去拿到了stu物件所屬的Student類在方法區存放的Class類物件。雖然說的有點拗口，但這句話我反覆琢磨了好幾遍，應該是說清楚了。

例項資料: 例項資料部分是物件真正儲存的有效資訊，就是程式程式碼中所定義的各種型別的欄位內容。

對齊填充: 虛擬機器規範要求物件大小必須是8位元組的整數倍。對齊填充其實就是來補全物件大小的。

3 . 物件的訪問定位

談到物件的訪問，還拿上面學生的例子來說，當我們拿到stu物件時，直接呼叫stu.getName();時，其實就完成了對物件的訪問。但這裡要累贅說一下的是，stu雖然通常被認為是一個物件，其實準確來說是不準確的，stu只是一個變數，變數裡儲存的是指向物件的指標，(如果幹過C或者C++的小夥伴應該比較清楚指標這個概念)，當我們呼叫stu.getName()時，虛擬機器會根據指標找到堆裡面的物件然後拿到例項資料name.需要注意的是，當我們呼叫stu.getClass()時，虛擬機器會首先根據stu指標定位到堆裡面的物件，然後根據物件頭裡面儲存的指向Class類元資訊的指標再次到方法區拿到Class物件，進行了兩次指標尋找。具體講解圖如下:
在這裡插入圖片描述

4 .實戰記憶體異常

記憶體異常是我們工作當中經常會遇到問題，但如果僅僅會通過加大記憶體引數來解決問題顯然是不夠的，應該通過一定的手段定位問題，到底是因為引數問題，還是程式問題(無限建立，記憶體洩露)。定位問題後才能採取合適的解決方案，而不是一記憶體溢位就查詢相關引數加大。

概念
記憶體洩露:程式碼中的某個物件本應該被虛擬機器回收，但因為擁有GCRoot引用而沒有被回收。關於GCRoot概念，下一篇文章講解。
記憶體溢位: 虛擬機器由於堆中擁有太多不可回收物件沒有回收，導致無法繼續建立新物件。

在分析問題之前先給大家講一講排查記憶體溢位問題的方法，記憶體溢位時JVM虛擬機器會退出，那麼我們怎麼知道JVM執行時的各種資訊呢，Dump機制會幫助我們，可以通過加上VM引數-XX:+HeapDumpOnOutOfMemoryError讓虛擬機器在出現記憶體溢位異常時生成dump檔案，然後通過外部工具(作者使用的是VisualVM)來具體分析異常的原因。

下面從以下幾個方面來配合程式碼實戰演示記憶體溢位及如何定位:

Java堆記憶體異常
Java棧記憶體異常
方法區記憶體異常

Java堆記憶體異常

/**
    VM Args:
    //這兩個引數保證了堆中的可分配記憶體固定為20M
    -Xms20m
    -Xmx20m  
    //檔案生成的位置，作則生成在桌面的一個目錄
    -XX:+HeapDumpOnOutOfMemoryError //檔案生成的位置，作則生成在桌面的一個目錄
    //檔案生成的位置，作則生成在桌面的一個目錄
    -XX:HeapDumpPath=/Users/zdy/Desktop/dump/ 
 */
public class HeapOOM {
    //建立一個內部類用於建立物件使用
    static class OOMObject {
    }
    public static void main(String[] args) {
        List<OOMObject> list = new ArrayList<OOMObject>();
        //無限建立物件，在堆中
        while (true) {
            list.add(new OOMObject());
        }
    }
}

Run起來程式碼後爆出異常如下:

java.lang.OutOfMemoryError: Java heap space
Dumping heap to /Users/zdy/Desktop/dump/java_pid1099.hprof …

可以看到生成了dump檔案到指定目錄。並且爆出了OutOfMemoryError，還告訴了你是哪一片區域出的問題:heap space

開啟VisualVM工具匯入對應的heapDump檔案(如何使用請讀者自行查閱相關資料)，相應的說明見圖:
在這裡插入圖片描述

分析dump檔案後，我們可以知道，OOMObject這個類建立了810326個例項。所以它能不溢位嗎？接下來就在程式碼裡找這個類在哪new的。排查問題。(我們的樣例程式碼就不用排查了，While迴圈太凶猛了)分析dump檔案後，我們可以知道，OOMObject這個類建立了810326個例項。所以它能不溢位嗎？接下來就在程式碼裡找這個類在哪new的。排查問題。(我們的樣例程式碼就不用排查了，While迴圈太凶猛了)

Java棧記憶體異常

老實說，在棧中出現異常(StackOverFlowError)的概率小到和去蘋果專賣店買手機，買回來後發現是Android系統的概率是一樣的。因為作者確實沒有在生產環境中遇到過，除了自己作死寫樣例程式碼測試。先說一下異常出現的情況，前面講到過，方法呼叫的過程就是方法幀進虛擬機器棧和出虛擬機器棧的過程，那麼有兩種情況可以導致StackOverFlowError,當一個方法幀(比如需要2M記憶體)進入到虛擬機器棧(比如還剩下1M記憶體)的時候，就會報出StackOverFlow.這裡先說一個概念，棧深度:指目前虛擬機器棧中沒有出棧的方法幀。虛擬機器棧容量通過引數-Xss來控制,下面通過一段程式碼，把棧容量人為的調小一點，然後通過遞迴呼叫觸發異常。

/**
 * VM Args：
    //設定棧容量為160K，預設1M
   -Xss160k
 */
public class JavaVMStackSOF {
    private int stackLength = 1;
    public void stackLeak() {
        stackLength++;
        //遞迴呼叫，觸發異常
        stackLeak();
    }
    public static void main(String[] args) throws Throwable {
        JavaVMStackSOF oom = new JavaVMStackSOF();
        try {
            oom.stackLeak();
        } catch (Throwable e) {
            System.out.println("stack length:" + oom.stackLength);
            throw e;
        }
    }
}

結果如下:
stack length:751 Exception in thread “main”
java.lang.StackOverflowError

可以看到，遞迴呼叫了751次，棧容量不夠用了。
預設的棧容量在正常的方法呼叫時，棧深度可以達到1000-2000深度，所以，一般的遞迴是可以承受的住的。如果你的程式碼出現了StackOverflowError，首先檢查程式碼，而不是改引數。

這裡順帶提一下，很多人在做多執行緒開發時，當建立很多執行緒時， 容易出現OOM(OutOfMemoryError), 這時可以通過具體情況，減少最大堆容量，或者棧容量來解決問題，這是為什麼呢。請看下面的公式:

執行緒數*(最大棧容量)+最大堆值+其他記憶體(忽略不計或者一般不改動)=機器最大記憶體

當執行緒數比較多時，且無法通過業務上削減執行緒數，那麼再不換機器的情況下， 你只能把最大棧容量設定小一點，或者把最大堆值設定小一點。

方法區記憶體異常

寫到這裡時，作者本來想寫一個無限建立動態代理物件的例子來演示方法區溢位，避開談論JDK7與JDK8的記憶體區域變更的過渡，但細想一想，還是把這一塊從始致終的說清楚。在上一篇文章中JVM系列之Java記憶體結構詳解講到方法區時提到，JDK7環境下方法區包括了(執行時常量池),其實這麼說是不準確的。因為從JDK7開始，HotSpot團隊就想到開始去”永久代”,大家首先明確一個概念，方法區和”永久代”(PermGen space)是兩個概念，方法區是JVM虛擬機器規範，任何虛擬機器實現(J9等)都不能少這個區間，而”永久代”只是HotSpot對方法區的一個實現。為了把知識點列清楚，我還是才用列表的形式:

JDK7之前(包括JDK7)擁有”永久代”(PermGen space),用來實現方法區。但在JDK7中已經逐漸在實現中把永久代中把很多東西移了出來，比如:符號引用(Symbols)轉移到了native heap,執行時常量池(interned strings)轉移到了java heap；類的靜態變數(class statics)轉移到了java heap.
所以這就是為什麼我說上一篇文章中說方法區中包含執行時常量池是不正確的，因為已經移動到了java heap;
在JDK7之前(包括7)可以通過-XX:PermSize -XX:MaxPermSize來控制永久代的大小.
JDK8正式去除”永久代”,換成Metaspace(元空間)作為JVM虛擬機器規範中方法區的實現。
元空間與永久代之間最大的區別在於：元空間並不在虛擬機器中，而是使用本地記憶體。因此，預設情況下，元空間的大小僅受本地記憶體限制，但仍可以通過引數控制:-XX:MetaspaceSize與-XX:MaxMetaspaceSize來控制大小。

方法區與執行時常量池OOM

Java 永久代是非堆記憶體的組成部分，用來存放類名、訪問修飾符、常量池、欄位描述、方法描述等，因執行時常量池是方法區的一部分，所以這裡也包含執行時常量池。我們可以通過 jvm 引數 -XX：PermSize=10M -XX：MaxPermSize=10M 來指定該區域的記憶體大小，-XX：PermSize 預設為實體記憶體的 1/64 ,-XX：MaxPermSize 預設為實體記憶體的 1/4 。String.intern() 方法是一個 Native 方法，它的作用是：如果字串常量池中已經包含一個等於此 String 物件的字串，則返回代表池中這個字串的 String 物件；否則，將此 String 物件包含的字串新增到常量池中，並且返回此 String 物件的引用。在 JDK 1.6 及之前的版本中，由於常量池分配在永久代內，我們可以通過 -XX：PermSize 和 -XX：MaxPermSize 限制方法區大小，從而間接限制其中常量池的容量,通過執行 java -XX：PermSize=8M -XX：MaxPermSize=8M RuntimeConstantPoolOom 下面的程式碼我們可以模仿一個執行時常量池記憶體溢位的情況：

import java.util.ArrayList;
import java.util.List;
public class RuntimeConstantPoolOom {
  public static void main(String[] args) {
    List<String> list = new ArrayList<String>();
    int i = 0;
    while (true) {
      list.add(String.valueOf(i++).intern());
    }
  }
}

執行結果如下：

[root@9683817ada51 oom]# ../jdk1.6.0_45/bin/java -XX:PermSize=8m -XX:MaxPermSize=8m RuntimeConstantPoolOom
Exception in thread "main" java.lang.OutOfMemoryError: PermGen space
    at java.lang.String.intern(Native Method)
    at RuntimeConstantPoolOom.main(RuntimeConstantPoolOom.java:9)

還有一種情況就是我們可以通過不停的載入class來模擬方法區記憶體溢位，《深入理解java虛擬機器》中藉助 CGLIB 這類位元組碼技術模擬了這個異常，我們這裡使用不同的 classloader 來實現（同一個類在不同的 classloader 中是不同的），程式碼如下

import java.io.File;
import java.net.MalformedURLException;
import java.net.URL;
import java.net.URLClassLoader;
import java.util.HashSet;
import java.util.Set;
public class MethodAreaOom {
  public static void main(String[] args) throws MalformedURLException, ClassNotFoundException {
    Set<Class<?>> classes = new HashSet<Class<?>>();
    URL url = new File("").toURI().toURL();
    URL[] urls = new URL[]{url};
    while (true) {
      ClassLoader loader = new URLClassLoader(urls);
      Class<?> loadClass = loader.loadClass(Object.class.getName());
      classes.add(loadClass);
    }
  }
}

[root@9683817ada51 oom]# ../jdk1.6.0_45/bin/java -XX:PermSize=2m -XX:MaxPermSize=2m MethodAreaOom
Error occurred during initialization of VM
java.lang.OutOfMemoryError: PermGen space
    at sun.net.www.ParseUtil.<clinit>(ParseUtil.java:31)
    at sun.misc.Launcher.getFileURL(Launcher.java:476)
    at sun.misc.Launcher$ExtClassLoader.getExtURLs(Launcher.java:187)
    at sun.misc.Launcher$ExtClassLoader.<init>(Launcher.java:158)
    at sun.misc.Launcher$ExtClassLoader$1.run(Launcher.java:142)
    at java.security.AccessController.doPrivileged(Native Method)
    at sun.misc.Launcher$ExtClassLoader.getExtClassLoader(Launcher.java:135)
    at sun.misc.Launcher.<init>(Launcher.java:55)
    at sun.misc.Launcher.<clinit>(Launcher.java:43)
    at java.lang.ClassLoader.initSystemClassLoader(ClassLoader.java:1337)
    at java.lang.ClassLoader.getSystemClassLoader(ClassLoader.java:1319)

在 jdk1.8 上執行上面的程式碼將不會出現異常，因為 jdk1.8 已結去掉了永久代，當然 -XX:PermSize=2m -XX:MaxPermSize=2m 也將被忽略，如下

[root@9683817ada51 oom]# java -XX:PermSize=2m -XX:MaxPermSize=2m MethodAreaOom
Java HotSpot(TM) 64-Bit Server VM warning: ignoring option PermSize=2m; support was removed in 8.0
Java HotSpot(TM) 64-Bit Server VM warning: ignoring option MaxPermSize=2m; support was removed in 8.0

jdk1.8 使用元空間（ Metaspace ）替代了永久代（ PermSize ），因此我們可以在 1.8 中指定 Metaspace 的大小模擬上述情況

[root@9683817ada51 oom]# java -XX:MetaspaceSize=2m -XX:MaxMetaspaceSize=2m RuntimeConstantPoolOom
Error occurred during initialization of VM
java.lang.OutOfMemoryError: Metaspace
    <<no stack trace available>>

在JDK8的環境下將報出異常:
Exception in thread “main” java.lang.OutOfMemoryError: Metaspace
這是因為在呼叫CGLib的建立代理時會生成動態代理類，即Class物件到Metaspace,所以While一下就出異常了。
提醒一下:雖然我們日常叫”堆Dump”,但是dump技術不僅僅是對於”堆”區域才有效，而是針對OOM的，也就是說不管什麼區域，凡是能夠報出OOM錯誤的，都可以使用dump技術生成dump檔案來分析。

在經常動態生成大量Class的應用中，需要特別注意類的回收狀況，這類場景除了例子中的CGLib技術，常見的還有，大量JSP，反射，OSGI等。需要特別注意，當出現此類異常，應該知道是哪裡出了問題，然後看是調整引數，還是在程式碼層面優化。

附加-直接記憶體異常

直接記憶體異常非常少見，而且機制很特殊，因為直接記憶體不是直接向作業系統分配記憶體，而且通過計算得到的記憶體不夠而手動丟擲異常，所以當你發現你的dump檔案很小，而且沒有明顯異常，只是告訴你OOM，你就可以考慮下你程式碼裡面是不是直接或者間接使用了NIO而導致直接記憶體溢位。

Java記憶體洩漏

Java的一個重要優點就是通過垃圾收集器(Garbage Collection，GC)自動管理記憶體的回收，程式設計師不需要通過呼叫函式來釋放記憶體。因此，很多程式設計師認為Java不存在記憶體洩漏問題，或者認為即使有記憶體洩漏也不是程式的責任，而是GC或JVM的問題。其實，這種想法是不正確的，因為Java也存在記憶體洩露，但它的表現與C++不同。

隨著越來越多的伺服器程式採用Java技術，例如JSP，Servlet， EJB等，伺服器程式往往長期執行。另外，在很多嵌入式系統中，記憶體的總量非常有限。記憶體洩露問題也就變得十分關鍵，即使每次執行少量洩漏，長期執行之後，系統也是面臨崩潰的危險。

Java是如何管理記憶體？

為了判斷Java中是否有記憶體洩露，我們首先必須瞭解Java是如何管理記憶體的。Java的記憶體管理就是物件的分配和釋放問題。在Java中，程式設計師需要通過關鍵字new為每個物件申請記憶體空間 (基本型別除外)，所有的物件都在堆 (Heap)中分配空間。另外，物件的釋放是由GC決定和執行的。在Java中，記憶體的分配是由程式完成的，而記憶體的釋放是有GC完成的，這種收支兩條線的方法確實簡化了程式設計師的工作。但同時，它也加重了JVM的工作。這也是Java程式執行速度較慢的原因之一。因為，GC為了能夠正確釋放物件，GC必須監控每一個物件的執行狀態，包括物件的申請、引用、被引用、賦值等，GC都需要進行監控。

監視物件狀態是為了更加準確地、及時地釋放物件，而釋放物件的根本原則就是該物件不再被引用。

為了更好理解GC的工作原理，我們可以將物件考慮為有向圖的頂點，將引用關係考慮為圖的有向邊，有向邊從引用者指向被引物件。另外，每個執行緒物件可以作為一個圖的起始頂點，例如大多程式從main程式開始執行，那麼該圖就是以main程式頂點開始的一棵根樹。在這個有向圖中，根頂點可達的物件都是有效物件，GC將不回收這些物件。如果某個物件 (連通子圖)與這個根頂點不可達(注意，該圖為有向圖)，那麼我們認為這個(這些)物件不再被引用，可以被GC回收。

以下，我們舉一個例子說明如何用有向圖表示記憶體管理。對於程式的每一個時刻，我們都有一個有向圖表示JVM的記憶體分配情況。以下右圖，就是左邊程式執行到第6行的示意圖。
在這裡插入圖片描述
Java使用有向圖的方式進行記憶體管理，可以消除引用迴圈的問題，例如有三個物件，相互引用，只要它們和根程式不可達的，那麼GC也是可以回收它們的。這種方式的優點是管理記憶體的精度很高，但是效率較低。另外一種常用的記憶體管理技術是使用計數器，例如COM模型採用計數器方式管理構件，它與有向圖相比，精度行低(很難處理迴圈引用的問題)，但執行效率很高。

什麼是Java中的記憶體洩露？

下面，我們就可以描述什麼是記憶體洩漏。在Java中，記憶體洩漏就是存在一些被分配的物件，這些物件有下面兩個特點，首先，這些物件是可達的，即在有向圖中，存在通路可以與其相連；其次，這些物件是無用的，即程式以後不會再使用這些物件。如果物件滿足這兩個條件，這些物件就可以判定為Java中的記憶體洩漏，這些物件不會被GC所回收，然而它卻佔用記憶體。

在C++中，記憶體洩漏的範圍更大一些。有些物件被分配了記憶體空間，然後卻不可達，由於C++中沒有GC，這些記憶體將永遠收不回來。在Java中，這些不可達的物件都由GC負責回收，因此程式設計師不需要考慮這部分的記憶體洩露。

通過分析，我們得知，對於C++，程式設計師需要自己管理邊和頂點，而對於Java程式設計師只需要管理邊就可以了(不需要管理頂點的釋放)。通過這種方式，Java提高了程式設計的效率。
在這裡插入圖片描述
因此，通過以上分析，我們知道在Java中也有記憶體洩漏，但範圍比C++要小一些。因為Java從語言上保證，任何物件都是可達的，所有的不可達物件都由GC管理。

對於程式設計師來說，GC基本是透明的，不可見的。雖然，我們只有幾個函式可以訪問GC，例如執行GC的函式System.gc()，但是根據Java語言規範定義，該函式不保證JVM的垃圾收集器一定會執行。因為，不同的JVM實現者可能使用不同的演算法管理GC。通常，GC的執行緒的優先順序別較低。JVM呼叫GC的策略也有很多種，有的是記憶體使用到達一定程度時，GC才開始工作，也有定時執行的，有的是平緩執行GC，有的是中斷式執行GC。但通常來說，我們不需要關心這些。除非在一些特定的場合，GC的執行影響應用程式的效能，例如對於基於Web的實時系統，如網路遊戲等，使用者不希望GC突然中斷應用程式執行而進行垃圾回收，那麼我們需要調整GC的引數，讓GC能夠通過平緩的方式釋放記憶體，例如將垃圾回收分解為一系列的小步驟執行，Sun提供的HotSpot JVM就支援這一特性。

下面給出了一個簡單的記憶體洩露的例子。在這個例子中，我們迴圈申請Object物件，並將所申請的物件放入一個Vector中，如果我們僅僅釋放引用本身，那麼Vector仍然引用該物件，所以這個物件對GC來說是不可回收的。因此，如果物件加入到Vector後，還必須從Vector中刪除，最簡單的方法就是將Vector物件設定為null。

Vector v=new Vector(10);
for (int i=1;i<100; i++)
{
    Object o=new Object();
    v.add(o);
    o=null;
}
//此時，所有的Object物件都沒有被釋放，因為變數v引用這些物件

其他常見記憶體洩漏

1、靜態集合類引起記憶體洩露：

像HashMap、Vector等的使用最容易出現記憶體洩露，這些靜態變數的生命週期和應用程式一致，他們所引用的所有的物件Object也不能被釋放，因為他們也將一直被Vector等引用著。
例:

Static Vector v = new Vector(10); 
for (int i = 1; i<100; i++) { 
    Object o = new Object(); 
    v.add(o); 
    o = null; 
}// 
在這個例子中，迴圈申請Object 物件，並將所申請的物件放入一個Vector 中，如果僅僅釋放引用本身（o=null），那麼Vector 仍然引用該物件，所以這個物件對GC 來說是不可回收的。因此，如果物件加入到Vector 後，還必須從Vector 中刪除，最簡單的方法就是將Vector物件設定為null。

2、當集合裡面的物件屬性被修改後，再呼叫remove（）方法時不起作用。

例：

public static void main(String[] args) { 
    Set<Person> set = new HashSet<Person>(); 
    Person p1 = new Person("唐僧","pwd1",25); 
    Person p2 = new Person("孫悟空","pwd2",26); 
    Person p3 = new Person("豬八戒","pwd3",27); 
    set.add(p1); 
    set.add(p2); 
    set.add(p3); 
    System.out.println("總共有:"+set.size()+" 個元素!"); //結果：總共有:3 個元素! 
    p3.setAge(2); //修改p3的年齡,此時p3元素對應的hashcode值發生改變 
    set.remove(p3); //此時remove不掉，造成記憶體洩漏
    set.add(p3); //重新新增，居然新增成功 
    System.out.println("總共有:"+set.size()+" 個元素!"); //結果：總共有:4 個元素! 
    for (Person person : set) { 
        System.out.println(person); 
    } 
}

3、監聽器

在java 程式設計中，我們都需要和監聽器打交道，通常一個應用當中會用到很多監聽器，我們會呼叫一個控制元件的諸如addXXXListener()等方法來增加監聽器，但往往在釋放物件的時候卻沒有記住去刪除這些監聽器，從而增加了記憶體洩漏的機會。

4、各種連線

比如資料庫連線（dataSourse.getConnection()），網路連線(socket)和io連線，除非其顯式的呼叫了其close（）方法將其連線關閉，否則是不會自動被GC 回收的。對於Resultset 和Statement 物件可以不進行顯式回收，但Connection 一定要顯式回收，因為Connection 在任何時候都無法自動回收，而Connection一旦回收，Resultset 和Statement 物件就會立即為NULL。但是如果使用連線池，情況就不一樣了，除了要顯式地關閉連線，還必須顯式地關閉Resultset Statement 物件（關閉其中一個，另外一個也會關閉），否則就會造成大量的Statement 物件無法釋放，從而引起記憶體洩漏。這種情況下一般都會在try裡面去的連線，在finally裡面釋放連線。

5、內部類和外部模組等的引用

內部類的引用是比較容易遺忘的一種，而且一旦沒釋放可能導致一系列的後繼類物件沒有釋放。此外程式設計師還要小心外部模組不經意的引用，例如程式設計師A 負責A 模組，呼叫了B 模組的一個方法如：
public void registerMsg(Object b);
這種呼叫就要非常小心了，傳入了一個物件，很可能模組B就保持了對該物件的引用，這時候就需要注意模組B 是否提供相應的操作去除引用。

6、單例模式

不正確使用單例模式是引起記憶體洩露的一個常見問題，單例物件在被初始化後將在JVM的整個生命週期中存在（以靜態變數的方式），如果單例物件持有外部物件的引用，那麼這個外部物件將不能被jvm正常回收，導致記憶體洩露，考慮下面的例子：

class A{ 
    public A(){ 
        B.getInstance().setA(this); 
    } 
.... 
} 
//B類採用單例模式 
class B{ 
    private A a; 
    private static B instance=new B(); 
    public B(){} 
    public static B getInstance(){ 
        return instance; 
    } 
    public void setA(A a){ 
        this.a=a; 
    } 
    //getter... 
}

顯然B採用singleton模式，它持有一個A物件的引用，而這個A類的物件將不能被回收。想象下如果A是個比較複雜的物件或者集合型別會發生什麼情況。

如何檢測記憶體洩漏

最後一個重要的問題，就是如何檢測Java的記憶體洩漏。目前，我們通常使用一些工具來檢查Java程式的記憶體洩漏問題。市場上已有幾種專業檢查Java記憶體洩漏的工具，它們的基本工作原理大同小異，都是通過監測Java程式執行時，所有物件的申請、釋放等動作，將記憶體管理的所有資訊進行統計、分析、視覺化。開發人員將根據這些資訊判斷程式是否有記憶體洩漏問題。這些工具包括Optimizeit Profiler，JProbe Profiler，JinSight , Rational 公司的Purify等。

下面，我們將簡單介紹Optimizeit的基本功能和工作原理。

Optimizeit Profiler版本4.11支援Application，Applet，Servlet和Romote Application四類應用，並且可以支援大多數型別的JVM，包括SUN JDK系列，IBM的JDK系列，和Jbuilder的JVM等。並且，該軟體是由Java編寫，因此它支援多種作業系統。Optimizeit系列還包括Thread Debugger和Code Coverage兩個工具，分別用於監測執行時的執行緒狀態和程式碼覆蓋面。

當設定好所有的引數了，我們就可以在OptimizeIt環境下執行被測程式，在程式執行過程中，Optimizeit可以監視記憶體的使用曲線(如下圖)，包括JVM申請的堆(heap)的大小，和實際使用的記憶體大小。另外，在執行過程中，我們可以隨時暫停程式的執行，甚至強行呼叫GC，讓GC進行記憶體回收。通過記憶體使用曲線，我們可以整體瞭解程式使用記憶體的情況。這種監測對於長期執行的應用程式非常有必要，也很容易發現記憶體洩露。