本文轉自互聯網，侵刪
本系列文章將整理到我在GitHub上的《Java面試指南》倉庫，更多精彩內容請到我的倉庫裏查看
喜歡的話麻煩點下Star哈
文章將同步到我的個人博客：
www.how2playlife.com
本文是微信公衆號【Java技術江湖】的《深入理解JVM虛擬機》其中一篇，本文部分內容來源於網絡，爲了把本文主題講得清晰透徹，也整合了很多我認爲不錯的技術博客內容，引用其中了一些比較好的博客文章，如有侵權，請聯繫作者。
該系列博文會告訴你如何從入門到進階，一步步地學習JVM基礎知識，並上手進行JVM調優實戰，JVM是每一個Java工程師必須要學習和理解的知識點，你必須要掌握其實現原理，才能更完整地瞭解整個Java技術體系，形成自己的知識框架。
爲了更好地總結和檢驗你的學習成果，本系列文章也會提供每個知識點對應的面試題以及參考答案。
如果對本系列文章有什麼建議，或者是有什麼疑問的話，也可以關注公衆號【Java技術江湖】聯繫作者，歡迎你參與本系列博文的創作和修訂。
<!-- more -->
實戰內存溢出異常
大家好，相信大部分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), 這時可以通過具體情況，減少最大堆容量，或者棧容量來解決問題，這是爲什麼呢。請看下面的公式:
<font color="red">線程數*(最大棧容量)+最大堆值+其他內存(忽略不計或者一般不改動)=機器最大內存</font>
當線程數比較多時，且無法通過業務上削減線程數，那麼再不換機器的情況下，你只能把最大棧容量設置小一點，或者把最大堆值設置小一點。
方法區內存異常
寫到這裏時，作者本來想寫一個無限創建動態代理對象的例子來演示方法區溢出，避開談論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進行內存回收。通過內存使用曲線，我們可以整體瞭解程序使用內存的情況。這種監測對於長期運行的應用程序非常有必要，也很容易發現內存泄露。
參考文章
<https://segmentfault.com/a/1190000009707894>
<https://www.cnblogs.com/hysum/p/7100874.html>