天天看點
傳回

深入了解JVM虛拟機11：Java記憶體異常原理與實踐JVM系列之實戰記憶體溢出異常

JVM系列之實戰記憶體溢出異常

實戰記憶體溢出異常

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

文章結構
  1. 對象的建立過程
  2. 對象的記憶體布局
  3. 對象的通路定位
  4. 實戰記憶體異常

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對象，進行了兩次指針尋找。具體講解圖如下:

深入了解JVM虛拟機11：Java記憶體異常原理與實踐JVM系列之實戰記憶體溢出異常

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檔案(如何使用請讀者自行查閱相關資料)，相應的說明見圖:

深入了解JVM虛拟機11：Java記憶體異常原理與實踐JVM系列之實戰記憶體溢出異常

"類标簽"

切換到"執行個體數"标簽頁

深入了解JVM虛拟機11：Java記憶體異常原理與實踐JVM系列之實戰記憶體溢出異常

"執行個體數标簽"

分析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());
    }
  }
}

運作結果如下

[[email protected] 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);
    }
  }
}

運作結果如下：

[[email protected] 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

 也将被忽略，如下

[[email protected] 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 的大小模拟上述情況

[[email protected] 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而導緻直接記憶體溢出。

好了，"JVM系列之實戰記憶體溢出異常"到這裡就給大家介紹完了,Have a good day .歡迎留言指錯。

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行的示意圖。

深入了解JVM虛拟機11：Java記憶體異常原理與實踐JVM系列之實戰記憶體溢出異常

Java使用有向圖的方式進行記憶體管理，可以消除引用循環的問題，例如有三個對象，互相引用，隻要它們和根程序不可達的，那麼GC也是可以回收它們的。這種方式的優點是管理記憶體的精度很高，但是效率較低。另外一種常用的記憶體管理技術是使用計數器，例如COM模型采用計數器方式管理構件，它與有向圖相比，精度行低(很難處理循環引用的問題)，但執行效率很高。

什麼是Java中的記憶體洩露

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

在C++中，記憶體洩漏的範圍更大一些。有些對象被配置設定了記憶體空間，然後卻不可達，由于C++中沒有GC，這些記憶體将永遠收不回來。在Java中，這些不可達的對象都由GC負責回收，是以程式員不需要考慮這部分的記憶體洩露。

通過分析，我們得知，對于C++，程式員需要自己管理邊和頂點，而對于Java程式員隻需要管理邊就可以了(不需要管理頂點的釋放)。通過這種方式，Java提高了程式設計的效率。

深入了解JVM虛拟機11：Java記憶體異常原理與實踐JVM系列之實戰記憶體溢出異常

是以，通過以上分析，我們知道在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。

1 2 3 4 5 6 7

Vector v=new Vector(10);

for (int i=1;i<100; i++)

{

Object o=new Object();

v.add(o);

o=null;

}

//此時，所有的Object對象都沒有被釋放，因為變量v引用這些對象。

其他常見記憶體洩漏

<span style="color:#333333">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是個比較複雜的對象或者集合類型會發生什麼情況</span>

如何檢測記憶體洩漏

最後一個重要的問題，就是如何檢測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進行記憶體回收。通過記憶體使用曲線，我們可以整體了解程式使用記憶體的情況。這種監測對于長期運作的應用程式非常有必要，也很容易發現記憶體洩露。

深入了解JVM虛拟機11：Java記憶體異常原理與實踐JVM系列之實戰記憶體溢出異常

在運作過程中，我們還可以從不同視角觀查記憶體的使用情況，Optimizeit提供了四種方式：

  • 堆視角。 這是一個全面的視角，我們可以了解堆中的所有的對象資訊(數量和種類)，并進行統計、排序，過濾。了解相關對象的變化情況。
  • 方法視角。通過方法視角，我們可以得知每一種類的對象，都配置設定在哪些方法中，以及它們的數量。
  • 對象視角。給定一個對象，通過對象視角，我們可以顯示它的所有出引用和入引用對象，我們可以了解這個對象的所有引用關系。
  • 引用圖。 給定一個根，通過引用圖，我們可以顯示從該頂點出發的所有出引用。

在運作過程中，我們可以随時觀察記憶體的使用情況，通過這種方式，我們可以很快找到那些長期不被釋放，并且不再使用的對象。我們通過檢查這些對象的生存周期，确認其是否為記憶體洩露。在實踐當中，尋找記憶體洩露是一件非常麻煩的事情，它需要程式員對整個程式的代碼比較清楚，并且需要豐富的調試經驗，但是這個過程對于很多關鍵的Java程式都是十分重要的。

綜上所述，Java也存在記憶體洩露問題，其原因主要是一些對象雖然不再被使用，但它們仍然被引用。為了解決這些問題，我們可以通過軟體工具來檢查記憶體洩露，檢查的主要原理就是暴露出所有堆中的對象，讓程式員尋找那些無用但仍被引用的對象。

微信公衆号

個人公衆号：程式員黃小斜

微信公衆号【程式員黃小斜】新生代青年聚集地，程式員成長充電站。作者黃小斜，職業是阿裡程式員，身份是斜杠青年，希望和更多的程式員交朋友，一起進步和成長！專注于分享技術、面試、職場等成長幹貨，這一次，我們一起出發。

關注公衆号後回複“2019”領取我這兩年整理的學習資料，涵蓋自學程式設計、求職面試、算法刷題、Java技術學習、計算機基礎和考研等8000G資料合集。

深入了解JVM虛拟機11：Java記憶體異常原理與實踐JVM系列之實戰記憶體溢出異常

技術公衆号：Java技術江湖

微信公衆号【Java技術江湖】一位阿裡 Java 工程師的技術小站，專注于 Java 相關技術：SSM、SpringBoot、MySQL、分布式、中間件、叢集、Linux、網絡、多線程，偶爾講點Docker、ELK，同時也分享技術幹貨和學習經驗，緻力于Java全棧開發！

關注公衆号後回複“PDF”即可領取200+頁的《Java工程師面試指南》強烈推薦，幾乎涵蓋所有Java工程師必知必會的知識點。

深入了解JVM虛拟機11：Java記憶體異常原理與實踐JVM系列之實戰記憶體溢出異常
深入了解JVM虛拟機 jvm 記憶體異常
上一篇: CPU的主頻、超頻和記憶體異步(一)
下一篇: linux共享記憶體異常,Linux共享記憶體分段故障

繼續閱讀