本文轉自互聯(lián)網(wǎng)族阅，侵刪

本系列文章將整理到我在GitHub上的《Java面試指南》倉庫，更多精彩內(nèi)容請到我的倉庫里查看

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

喜歡的話麻煩點下Star哈

文章將同步到我的個人博客：

www.how2playlife.com

本文是微信公眾號【Java技術江湖】的《深入理解JVM虛擬機》其中一篇，本文部分內(nèi)容來源于網(wǎng)絡奏瞬，為了把本文主題講得清晰透徹侄刽，也整合了很多我認為不錯的技術博客內(nèi)容，引用其中了一些比較好的博客文章鹊汛，如有侵權蒲赂，請聯(lián)系作者。

該系列博文會告訴你如何從入門到進階刁憋，一步步地學習JVM基礎知識滥嘴，并上手進行JVM調(diào)優(yōu)實戰(zhàn)，JVM是每一個Java工程師必須要學習和理解的知識點至耻，你必須要掌握其實現(xiàn)原理若皱，才能更完整地了解整個Java技術體系，形成自己的知識框架尘颓。

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

如果對本系列文章有什么建議疤苹，或者是有什么疑問的話饺汹，也可以關注公眾號【Java技術江湖】聯(lián)系作者，歡迎你參與本系列博文的創(chuàng)作和修訂痰催。

實戰(zhàn)內(nèi)存溢出異常

大家好兜辞，相信大部分Javaer在code時經(jīng)常會遇到本地代碼運行正常，但在生產(chǎn)環(huán)境偶爾會莫名其妙的報一些關于內(nèi)存的異常夸溶，StackOverFlowError,OutOfMemoryError異常是最常見的逸吵。今天就基于上篇文章JVM系列之Java內(nèi)存結構詳解講解的各個內(nèi)存區(qū)域重點實戰(zhàn)分析下內(nèi)存溢出的情況。在此之前缝裁，我還是想多余累贅一些其他關于對象的問題扫皱，具體內(nèi)容如下:

文章結構：
對象的創(chuàng)建過程
對象的內(nèi)存布局
對象的訪問定位
實戰(zhàn)內(nèi)存異常

1 . 對象的創(chuàng)建過程

關于對象的創(chuàng)建，第一反應是new關鍵字捷绑，那么本文就主要講解new關鍵字創(chuàng)建對象的過程韩脑。

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

就拿上面這句代碼來說粹污，虛擬機首先會去檢查Student這個類有沒有被加載段多，如果沒有，首先去加載這個類到方法區(qū)壮吩，然后根據(jù)加載的Class類對象創(chuàng)建stu實例對象进苍，需要注意的是加缘，stu對象所需的內(nèi)存大小在Student類加載完成后便可完全確定。內(nèi)存分配完成后觉啊，虛擬機需要將分配到的內(nèi)存空間的實例數(shù)據(jù)部分初始化為零值,這也就是為什么我們在編寫Java代碼時創(chuàng)建一個變量不需要初始化拣宏。緊接著，虛擬機會對對象的對象頭進行必要的設置杠人，如這個對象屬于哪個類勋乾，如何找到類的元數(shù)據(jù)(Class對象),對象的鎖信息，GC分代年齡等嗡善。設置完對象頭信息后市俊，調(diào)用類的構造函數(shù)。
其實講實話滤奈，虛擬機創(chuàng)建對象的過程遠不止這么簡單，我這里只是把大致的脈絡講解了一下撩满，方便大家理解蜒程。

2 . 對象的內(nèi)存布局

剛剛提到的實例數(shù)據(jù)，對象頭伺帘，有些小伙伴也許有點陌生昭躺，這一小節(jié)就詳細講解一下對象的內(nèi)存布局,對象創(chuàng)建完成后大致可以分為以下幾個部分:

• 對象頭
• 實例數(shù)據(jù)
• 對齊填充

對象頭: 對象頭中包含了對象運行時一些必要的信息，如GC分代信息伪嫁，鎖信息领炫，哈希碼，指向Class類元信息的指針等张咳，其中對Javaer比較有用的是鎖信息與指向Class對象的指針帝洪，關于鎖信息，后期有機會講解并發(fā)編程JUC時再擴展，關于指向Class對象的指針其實很好理解。比如上面那個Student的例子砍聊，當我們拿到stu對象時徽缚，調(diào)用Class stuClass=stu.getClass();的時候，其實就是根據(jù)這個指針去拿到了stu對象所屬的Student類在方法區(qū)存放的Class類對象粱腻。雖然說的有點拗口，但這句話我反復琢磨了好幾遍，應該是說清楚了军援。

實例數(shù)據(jù): 實例數(shù)據(jù)部分是對象真正存儲的有效信息，就是程序代碼中所定義的各種類型的字段內(nèi)容称勋。

對齊填充: 虛擬機規(guī)范要求對象大小必須是8字節(jié)的整數(shù)倍胸哥。對齊填充其實就是來補全對象大小的。

3 . 對象的訪問定位

談到對象的訪問赡鲜，還拿上面學生的例子來說烘嘱，當我們拿到stu對象時昆禽，直接調(diào)用stu.getName();時，其實就完成了對對象的訪問蝇庭。但這里要累贅說一下的是醉鳖，stu雖然通常被認為是一個對象，其實準確來說是不準確的哮内，stu只是一個變量盗棵，變量里存儲的是指向?qū)ο蟮闹羔槪?如果干過C或者C++的小伙伴應該比較清楚指針這個概念)，當我們調(diào)用stu.getName()時北发，虛擬機會根據(jù)指針找到堆里面的對象然后拿到實例數(shù)據(jù)name.需要注意的是纹因，當我們調(diào)用stu.getClass()時，虛擬機會首先根據(jù)stu指針定位到堆里面的對象琳拨，然后根據(jù)對象頭里面存儲的指向Class類元信息的指針再次到方法區(qū)拿到Class對象瞭恰，進行了兩次指針尋找。具體講解圖如下:

在這里插入圖片描述

4 .實戰(zhàn)內(nèi)存異常

內(nèi)存異常是我們工作當中經(jīng)常會遇到問題狱庇，但如果僅僅會通過加大內(nèi)存參數(shù)來解決問題顯然是不夠的惊畏，應該通過一定的手段定位問題，到底是因為參數(shù)問題密任，還是程序問題(無限創(chuàng)建颜启，內(nèi)存泄露)。定位問題后才能采取合適的解決方案浪讳，而不是一內(nèi)存溢出就查找相關參數(shù)加大缰盏。

概念
內(nèi)存泄露:代碼中的某個對象本應該被虛擬機回收，但因為擁有GCRoot引用而沒有被回收淹遵。關于GCRoot概念口猜，下一篇文章講解。
內(nèi)存溢出: 虛擬機由于堆中擁有太多不可回收對象沒有回收透揣，導致無法繼續(xù)創(chuàng)建新對象暮的。

在分析問題之前先給大家講一講排查內(nèi)存溢出問題的方法，內(nèi)存溢出時JVM虛擬機會退出淌实，那么我們怎么知道JVM運行時的各種信息呢冻辩，Dump機制會幫助我們，可以通過加上VM參數(shù)-XX:+HeapDumpOnOutOfMemoryError讓虛擬機在出現(xiàn)內(nèi)存溢出異常時生成dump文件拆祈，然后通過外部工具(作者使用的是VisualVM)來具體分析異常的原因恨闪。

下面從以下幾個方面來配合代碼實戰(zhàn)演示內(nèi)存溢出及如何定位:

• Java堆內(nèi)存異常
• Java棧內(nèi)存異常
• 方法區(qū)內(nèi)存異常

Java堆內(nèi)存異常

/**
    VM Args:
    //這兩個參數(shù)保證了堆中的可分配內(nèi)存固定為20M
    -Xms20m
    -Xmx20m  
    //文件生成的位置，作則生成在桌面的一個目錄
    -XX:+HeapDumpOnOutOfMemoryError //文件生成的位置放坏，作則生成在桌面的一個目錄
    //文件生成的位置咙咽，作則生成在桌面的一個目錄
    -XX:HeapDumpPath=/Users/zdy/Desktop/dump/ 
 */
public class HeapOOM {
    //創(chuàng)建一個內(nèi)部類用于創(chuàng)建對象使用
    static class OOMObject {
    }
    public static void main(String[] args) {
        List<OOMObject> list = new ArrayList<OOMObject>();
        //無限創(chuàng)建對象，在堆中
        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钧敞，還告訴了你是哪一片區(qū)域出的問題:heap space

打開VisualVM工具導入對應的heapDump文件(如何使用請讀者自行查閱相關資料)蜡豹，相應的說明見圖:

在這里插入圖片描述

在這里插入圖片描述

分析dump文件后，我們可以知道溉苛，OOMObject這個類創(chuàng)建了810326個實例镜廉。所以它能不溢出嗎？接下來就在代碼里找這個類在哪new的愚战。排查問題娇唯。(我們的樣例代碼就不用排查了，While循環(huán)太兇猛了)分析dump文件后寂玲，我們可以知道塔插，OOMObject這個類創(chuàng)建了810326個實例。所以它能不溢出嗎拓哟？接下來就在代碼里找這個類在哪new的想许。排查問題。(我們的樣例代碼就不用排查了断序，While循環(huán)太兇猛了)

Java棧內(nèi)存異常

老實說流纹，在棧中出現(xiàn)異常(StackOverFlowError)的概率小到和去蘋果專賣店買手機，買回來后發(fā)現(xiàn)是Android系統(tǒng)的概率是一樣的逢倍。因為作者確實沒有在生產(chǎn)環(huán)境中遇到過，除了自己作死寫樣例代碼測試景图。先說一下異常出現(xiàn)的情況较雕，前面講到過，方法調(diào)用的過程就是方法幀進虛擬機棧和出虛擬機棧的過程挚币，那么有兩種情況可以導致StackOverFlowError,當一個方法幀(比如需要2M內(nèi)存)進入到虛擬機棧(比如還剩下1M內(nèi)存)的時候亮蒋，就會報出StackOverFlow.這里先說一個概念，棧深度:指目前虛擬機棧中沒有出棧的方法幀妆毕。虛擬機棧容量通過參數(shù)-Xss來控制,下面通過一段代碼慎玖，把棧容量人為的調(diào)小一點，然后通過遞歸調(diào)用觸發(fā)異常笛粘。

/**
 * VM Args：
    //設置棧容量為160K趁怔，默認1M
   -Xss160k
 */
public class JavaVMStackSOF {
    private int stackLength = 1;
    public void stackLeak() {
        stackLength++;
        //遞歸調(diào)用，觸發(fā)異常
        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

可以看到薪前，遞歸調(diào)用了751次润努，棧容量不夠用了。
默認的棧容量在正常的方法調(diào)用時示括，棧深度可以達到1000-2000深度铺浇，所以，一般的遞歸是可以承受的住的垛膝。如果你的代碼出現(xiàn)了StackOverflowError鳍侣，首先檢查代碼丁稀，而不是改參數(shù)。

這里順帶提一下倚聚，很多人在做多線程開發(fā)時线衫，當創(chuàng)建很多線程時，容易出現(xiàn)OOM(OutOfMemoryError), 這時可以通過具體情況秉沼，減少最大堆容量桶雀，或者棧容量來解決問題，這是為什么呢唬复。請看下面的公式:

<font color="red">線程數(shù)*(最大棧容量)+最大堆值+其他內(nèi)存(忽略不計或者一般不改動)=機器最大內(nèi)存</font>

當線程數(shù)比較多時矗积，且無法通過業(yè)務上削減線程數(shù)，那么再不換機器的情況下敞咧，你只能把最大棧容量設置小一點棘捣，或者把最大堆值設置小一點。

方法區(qū)內(nèi)存異常

寫到這里時休建，作者本來想寫一個無限創(chuàng)建動態(tài)代理對象的例子來演示方法區(qū)溢出乍恐，避開談論JDK7與JDK8的內(nèi)存區(qū)域變更的過渡，但細想一想测砂，還是把這一塊從始致終的說清楚茵烈。在上一篇文章中JVM系列之Java內(nèi)存結構詳解講到方法區(qū)時提到，JDK7環(huán)境下方法區(qū)包括了(運行時常量池),其實這么說是不準確的砌些。因為從JDK7開始呜投，HotSpot團隊就想到開始去"永久代",大家首先明確一個概念，方法區(qū)和"永久代"(PermGen space)是兩個概念存璃，方法區(qū)是JVM虛擬機規(guī)范仑荐，任何虛擬機實現(xiàn)(J9等)都不能少這個區(qū)間，而"永久代"只是HotSpot對方法區(qū)的一個實現(xiàn)纵东。 為了把知識點列清楚粘招，我還是才用列表的形式:

• JDK7之前(包括JDK7)擁有"永久代"(PermGen space),用來實現(xiàn)方法區(qū)。但在JDK7中已經(jīng)逐漸在實現(xiàn)中把永久代中把很多東西移了出來偎球，比如:符號引用(Symbols)轉移到了native heap,運行時常量池(interned strings)轉移到了java heap洒扎；類的靜態(tài)變量(class statics)轉移到了java heap.
• 所以這就是為什么我說上一篇文章中說方法區(qū)中包含運行時常量池是不正確的，因為已經(jīng)移動到了java heap;
  在JDK7之前(包括7)可以通過-XX:PermSize -XX:MaxPermSize來控制永久代的大小.
  JDK8正式去除"永久代",換成Metaspace(元空間)作為JVM虛擬機規(guī)范中方法區(qū)的實現(xiàn)衰絮。
  元空間與永久代之間最大的區(qū)別在于：元空間并不在虛擬機中逊笆，而是使用本地內(nèi)存。因此岂傲，默認情況下难裆，元空間的大小僅受本地內(nèi)存限制，但仍可以通過參數(shù)控制:-XX:MetaspaceSize與-XX:MaxMetaspaceSize來控制大小。

方法區(qū)與運行時常量池OOM

Java 永久代是非堆內(nèi)存的組成部分乃戈，用來存放類名褂痰、訪問修飾符、常量池症虑、字段描述缩歪、方法描述等，因運行時常量池是方法區(qū)的一部分谍憔，所以這里也包含運行時常量池匪蝙。我們可以通過 jvm 參數(shù) -XX：PermSize=10M -XX：MaxPermSize=10M 來指定該區(qū)域的內(nèi)存大小，-XX：PermSize 默認為物理內(nèi)存的 1/64 ,-XX：MaxPermSize 默認為物理內(nèi)存的 1/4 习贫。String.intern() 方法是一個 Native 方法逛球，它的作用是：如果字符串常量池中已經(jīng)包含一個等于此 String 對象的字符串，則返回代表池中這個字符串的 String 對象苫昌；否則颤绕，將此 String 對象包含的字符串添加到常量池中，并且返回此 String 對象的引用祟身。在 JDK 1.6 及之前的版本中奥务，由于常量池分配在永久代內(nèi)，我們可以通過 -XX：PermSize 和 -XX：MaxPermSize 限制方法區(qū)大小袜硫，從而間接限制其中常量池的容量,通過運行 java -XX：PermSize=8M -XX：MaxPermSize=8M RuntimeConstantPoolOom 下面的代碼我們可以模仿一個運行時常量池內(nèi)存溢出的情況：

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來模擬方法區(qū)內(nèi)存溢出氯葬，《深入理解java虛擬機》中借助 CGLIB 這類字節(jié)碼技術模擬了這個異常，我們這里使用不同的 classloader 來實現(xiàn)（同一個類在不同的 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 上運行上面的代碼將不會出現(xiàn)異常帚称，因為 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的環(huán)境下將報出異常:
Exception in thread “main” java.lang.OutOfMemoryError: Metaspace
這是因為在調(diào)用CGLib的創(chuàng)建代理時會生成動態(tài)代理類阀参，即Class對象到Metaspace,所以While一下就出異常了肝集。
提醒一下:雖然我們?nèi)粘＝?堆Dump",但是dump技術不僅僅是對于"堆"區(qū)域才有效，而是針對OOM的蛛壳，也就是說不管什么區(qū)域杏瞻，凡是能夠報出OOM錯誤的，都可以使用dump技術生成dump文件來分析衙荐。

在經(jīng)常動態(tài)生成大量Class的應用中捞挥，需要特別注意類的回收狀況，這類場景除了例子中的CGLib技術忧吟，常見的還有砌函，大量JSP，反射，OSGI等讹俊。需要特別注意垦沉，當出現(xiàn)此類異常，應該知道是哪里出了問題仍劈，然后看是調(diào)整參數(shù)厕倍，還是在代碼層面優(yōu)化。

附加-直接內(nèi)存異常

直接內(nèi)存異常非常少見贩疙，而且機制很特殊讹弯，因為直接內(nèi)存不是直接向操作系統(tǒng)分配內(nèi)存，而且通過計算得到的內(nèi)存不夠而手動拋出異常这溅，所以當你發(fā)現(xiàn)你的dump文件很小组民，而且沒有明顯異常，只是告訴你OOM芍躏，你就可以考慮下你代碼里面是不是直接或者間接使用了NIO而導致直接內(nèi)存溢出邪乍。

Java內(nèi)存泄漏

Java的一個重要優(yōu)點就是通過垃圾收集器(Garbage Collection，GC)自動管理內(nèi)存的回收对竣，程序員不需要通過調(diào)用函數(shù)來釋放內(nèi)存庇楞。因此，很多程序員認為Java不存在內(nèi)存泄漏問題否纬，或者認為即使有內(nèi)存泄漏也不是程序的責任吕晌，而是GC或JVM的問題。其實临燃，這種想法是不正確的睛驳，因為Java也存在內(nèi)存泄露，但它的表現(xiàn)與C++不同膜廊。

隨著越來越多的服務器程序采用Java技術乏沸，例如JSP，Servlet爪瓜， EJB等蹬跃，服務器程序往往長期運行。另外铆铆，在很多嵌入式系統(tǒng)中蝶缀，內(nèi)存的總量非常有限。內(nèi)存泄露問題也就變得十分關鍵薄货，即使每次運行少量泄漏翁都，長期運行之后，系統(tǒng)也是面臨崩潰的危險谅猾。

Java是如何管理內(nèi)存柄慰？

為了判斷Java中是否有內(nèi)存泄露鳍悠，我們首先必須了解Java是如何管理內(nèi)存的。Java的內(nèi)存管理就是對象的分配和釋放問題坐搔。在Java中贼涩，程序員需要通過關鍵字new為每個對象申請內(nèi)存空間 (基本類型除外)，所有的對象都在堆 (Heap)中分配空間薯蝎。另外遥倦，對象的釋放是由GC決定和執(zhí)行的。在Java中占锯，內(nèi)存的分配是由程序完成的袒哥，而內(nèi)存的釋放是有GC完成的，這種收支兩條線的方法確實簡化了程序員的工作消略。但同時堡称，它也加重了JVM的工作。這也是Java程序運行速度較慢的原因之一艺演。因為却紧，GC為了能夠正確釋放對象，GC必須監(jiān)控每一個對象的運行狀態(tài)胎撤，包括對象的申請晓殊、引用、被引用伤提、賦值等巫俺，GC都需要進行監(jiān)控。

監(jiān)視對象狀態(tài)是為了更加準確地肿男、及時地釋放對象介汹，而釋放對象的根本原則就是該對象不再被引用。

為了更好理解GC的工作原理舶沛，我們可以將對象考慮為有向圖的頂點嘹承，將引用關系考慮為圖的有向邊，有向邊從引用者指向被引對象如庭。另外叹卷，每個線程對象可以作為一個圖的起始頂點，例如大多程序從main進程開始執(zhí)行柱彻，那么該圖就是以main進程頂點開始的一棵根樹豪娜。在這個有向圖中餐胀，根頂點可達的對象都是有效對象哟楷，GC將不回收這些對象。如果某個對象 (連通子圖)與這個根頂點不可達(注意否灾，該圖為有向圖)卖擅，那么我們認為這個(這些)對象不再被引用，可以被GC回收。

以下惩阶，我們舉一個例子說明如何用有向圖表示內(nèi)存管理挎狸。對于程序的每一個時刻，我們都有一個有向圖表示JVM的內(nèi)存分配情況断楷。以下右圖锨匆，就是左邊程序運行到第6行的示意圖。

在這里插入圖片描述

Java使用有向圖的方式進行內(nèi)存管理冬筒，可以消除引用循環(huán)的問題恐锣，例如有三個對象，相互引用舞痰，只要它們和根進程不可達的土榴，那么GC也是可以回收它們的。這種方式的優(yōu)點是管理內(nèi)存的精度很高响牛，但是效率較低玷禽。另外一種常用的內(nèi)存管理技術是使用計數(shù)器，例如COM模型采用計數(shù)器方式管理構件呀打，它與有向圖相比矢赁，精度行低(很難處理循環(huán)引用的問題)，但執(zhí)行效率很高贬丛。

什么是Java中的內(nèi)存泄露坯台？

下面，我們就可以描述什么是內(nèi)存泄漏瘫寝。在Java中蜒蕾，內(nèi)存泄漏就是存在一些被分配的對象，這些對象有下面兩個特點焕阿，首先咪啡，這些對象是可達的，即在有向圖中暮屡，存在通路可以與其相連撤摸；其次，這些對象是無用的褒纲，即程序以后不會再使用這些對象准夷。如果對象滿足這兩個條件，這些對象就可以判定為Java中的內(nèi)存泄漏莺掠，這些對象不會被GC所回收衫嵌，然而它卻占用內(nèi)存。

在C++中彻秆，內(nèi)存泄漏的范圍更大一些楔绞。有些對象被分配了內(nèi)存空間结闸，然后卻不可達，由于C++中沒有GC酒朵，這些內(nèi)存將永遠收不回來桦锄。在Java中，這些不可達的對象都由GC負責回收蔫耽，因此程序員不需要考慮這部分的內(nèi)存泄露结耀。

通過分析，我們得知匙铡，對于C++饼记，程序員需要自己管理邊和頂點，而對于Java程序員只需要管理邊就可以了(不需要管理頂點的釋放)慰枕。通過這種方式具则，Java提高了編程的效率。

在這里插入圖片描述

因此具帮，通過以上分析博肋，我們知道在Java中也有內(nèi)存泄漏，但范圍比C++要小一些蜂厅。因為Java從語言上保證匪凡，任何對象都是可達的，所有的不可達對象都由GC管理掘猿。

對于程序員來說病游，GC基本是透明的，不可見的稠通。雖然衬衬，我們只有幾個函數(shù)可以訪問GC，例如運行GC的函數(shù)System.gc()改橘，但是根據(jù)Java語言規(guī)范定義滋尉， 該函數(shù)不保證JVM的垃圾收集器一定會執(zhí)行。因為飞主，不同的JVM實現(xiàn)者可能使用不同的算法管理GC狮惜。通常，GC的線程的優(yōu)先級別較低碌识。JVM調(diào)用GC的策略也有很多種碾篡，有的是內(nèi)存使用到達一定程度時，GC才開始工作筏餐，也有定時執(zhí)行的开泽，有的是平緩執(zhí)行GC，有的是中斷式執(zhí)行GC胖烛。但通常來說眼姐，我們不需要關心這些。除非在一些特定的場合佩番，GC的執(zhí)行影響應用程序的性能众旗，例如對于基于Web的實時系統(tǒng)，如網(wǎng)絡游戲等趟畏，用戶不希望GC突然中斷應用程序執(zhí)行而進行垃圾回收贡歧，那么我們需要調(diào)整GC的參數(shù)，讓GC能夠通過平緩的方式釋放內(nèi)存赋秀，例如將垃圾回收分解為一系列的小步驟執(zhí)行利朵，Sun提供的HotSpot JVM就支持這一特性。

下面給出了一個簡單的內(nèi)存泄露的例子猎莲。在這個例子中绍弟，我們循環(huán)申請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引用這些對象

其他常見內(nèi)存泄漏

1伤柄、靜態(tài)集合類引起內(nèi)存泄露：

像HashMap、Vector等的使用最容易出現(xiàn)內(nèi)存泄露文搂，這些靜態(tài)變量的生命周期和應用程序一致响迂，他們所引用的所有的對象Object也不能被釋放，因為他們也將一直被Vector等引用著细疚。
例:

Static Vector v = new Vector(10); 
for (int i = 1; i<100; i++) { 
    Object o = new Object(); 
    v.add(o); 
    o = null; 
}// 
在這個例子中蔗彤，循環(huán)申請Object 對象，并將所申請的對象放入一個Vector 中疯兼，如果僅僅釋放引用本身（o=null）然遏，那么Vector 仍然引用該對象，所以這個對象對GC 來說是不可回收的吧彪。因此待侵，如果對象加入到Vector 后，還必須從Vector 中刪除姨裸，最簡單的方法就是將Vector對象設置為null秧倾。

2怨酝、當集合里面的對象屬性被修改后，再調(diào)用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值發(fā)生改變 

    set.remove(p3); //此時remove不掉农猬，造成內(nèi)存泄漏
    set.add(p3); //重新添加，居然添加成功 
    System.out.println("總共有:"+set.size()+" 個元素!"); //結果：總共有:4 個元素! 
    for (Person person : set) { 
        System.out.println(person); 
    } 
}

3售淡、監(jiān)聽器

在java 編程中斤葱，我們都需要和監(jiān)聽器打交道，通常一個應用當中會用到很多監(jiān)聽器揖闸，我們會調(diào)用一個控件的諸如addXXXListener()等方法來增加監(jiān)聽器揍堕，但往往在釋放對象的時候卻沒有記住去刪除這些監(jiān)聽器，從而增加了內(nèi)存泄漏的機會汤纸。

4衩茸、各種連接

比如數(shù)據(jù)庫連接（dataSourse.getConnection()），網(wǎng)絡連接(socket)和io連接贮泞，除非其顯式的調(diào)用了其close（）方法將其連接關閉递瑰，否則是不會自動被GC 回收的。對于Resultset 和Statement 對象可以不進行顯式回收隙畜，但Connection 一定要顯式回收抖部，因為Connection 在任何時候都無法自動回收，而Connection一旦回收议惰，Resultset 和Statement 對象就會立即為NULL慎颗。但是如果使用連接池，情況就不一樣了言询，除了要顯式地關閉連接俯萎，還必須顯式地關閉Resultset Statement 對象（關閉其中一個，另外一個也會關閉）运杭，否則就會造成大量的Statement 對象無法釋放夫啊，從而引起內(nèi)存泄漏。這種情況下一般都會在try里面去的連接辆憔，在finally里面釋放連接撇眯。

5、內(nèi)部類和外部模塊等的引用

內(nèi)部類的引用是比較容易遺忘的一種虱咧，而且一旦沒釋放可能導致一系列的后繼類對象沒有釋放熊榛。此外程序員還要小心外部模塊不經(jīng)意的引用，例如程序員A 負責A 模塊腕巡，調(diào)用了B 模塊的一個方法如：
public void registerMsg(Object b);
這種調(diào)用就要非常小心了玄坦，傳入了一個對象，很可能模塊B就保持了對該對象的引用，這時候就需要注意模塊B 是否提供相應的操作去除引用煎楣。

6豺总、單例模式

不正確使用單例模式是引起內(nèi)存泄露的一個常見問題，單例對象在被初始化后將在JVM的整個生命周期中存在（以靜態(tài)變量的方式）择懂，如果單例對象持有外部對象的引用喻喳，那么這個外部對象將不能被jvm正常回收休蟹，導致內(nèi)存泄露沸枯，考慮下面的例子：

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是個比較復雜的對象或者集合類型會發(fā)生什么情況哪轿。

如何檢測內(nèi)存泄漏

最后一個重要的問題盈魁，就是如何檢測Java的內(nèi)存泄漏。目前窃诉，我們通常使用一些工具來檢查Java程序的內(nèi)存泄漏問題杨耙。市場上已有幾種專業(yè)檢查Java內(nèi)存泄漏的工具，它們的基本工作原理大同小異飘痛，都是通過監(jiān)測Java程序運行時珊膜，所有對象的申請、釋放等動作宣脉，將內(nèi)存管理的所有信息進行統(tǒng)計车柠、分析、可視化塑猖。開發(fā)人員將根據(jù)這些信息判斷程序是否有內(nèi)存泄漏問題竹祷。這些工具包括Optimizeit Profiler，JProbe Profiler羊苟，JinSight , Rational 公司的Purify等塑陵。

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

Optimizeit Profiler版本4.11支持Application令花，Applet，Servlet和Romote Application四類應用凉倚，并且可以支持大多數(shù)類型的JVM彭则，包括SUN JDK系列，IBM的JDK系列占遥，和Jbuilder的JVM等俯抖。并且，該軟件是由Java編寫瓦胎，因此它支持多種操作系統(tǒng)芬萍。Optimizeit系列還包括Thread Debugger和Code Coverage兩個工具尤揣，分別用于監(jiān)測運行時的線程狀態(tài)和代碼覆蓋面。

當設置好所有的參數(shù)了柬祠，我們就可以在OptimizeIt環(huán)境下運行被測程序北戏，在程序運行過程中，Optimizeit可以監(jiān)視內(nèi)存的使用曲線(如下圖)漫蛔，包括JVM申請的堆(heap)的大小嗜愈，和實際使用的內(nèi)存大小。另外莽龟，在運行過程中蠕嫁，我們可以隨時暫停程序的運行，甚至強行調(diào)用GC毯盈，讓GC進行內(nèi)存回收剃毒。通過內(nèi)存使用曲線，我們可以整體了解程序使用內(nèi)存的情況搂赋。這種監(jiān)測對于長期運行的應用程序非常有必要赘阀，也很容易發(fā)現(xiàn)內(nèi)存泄露。

參考文章

https://segmentfault.com/a/1190000009707894

https://www.cnblogs.com/hysum/p/7100874.html

http://c.biancheng.net/view/939.html

https://www.runoob.com/

https://blog.csdn.net/android_hl/article/details/53228348