一、在java中如何讓jvm總是記憶體溢位呢，之前想到的辦法是不停的建立物件，由於java的垃圾回收器的作用，事實上並不能答道效果，最簡單的辦法是建立陣列如下程式碼

1. class Singleton {
2. privatebyte[] a = newbyte[200*1024*1024];
3. privatestatic Singleton singleton = new Singleton();
4. private Singleton(){}
5. publicstatic Singleton getInstance(){
6. return singleton;
7. }
8. }

例項化Singleton類立刻就會丟擲記憶體溢位異常，如何200還不夠，可以再加大。

討論命題：當一個單例的物件長久不用時，會不會被jvm的垃圾收集機制回收。

首先說一下為什麼會產生這一疑問，筆者本人再此之前從來沒有考慮過垃圾回收對單例模式的影響，直到去年讀了一本書，《設計模式之禪》秦小波著。在書中提到在j2ee應用中，jvm垃圾回收機制會把長久不用的單例類物件當作垃圾，並在cpu空閒的時候對其進行回收。之前讀過的幾本設計模式的書，包括《java與模式》，書中都沒有提到jvm垃圾回收機制對單例的影響。並且在工作過程中，也沒有過單例物件被回收的經歷，加上工作中很多前輩曾經告誡過筆者：儘量不要宣告太多的靜態屬性，因為這些靜態屬性被載入後不會被釋放。因此對jvm垃圾收集會回收單例物件這一說法持懷疑態度。漸漸地，發現在同事中和網上的技術人員中，對這一問題也基本上是鮮明的對立兩派。那麼到底jvm會不會回收長久不用的單例物件呢。

對這一問題，筆者本人的觀點是：不會回收。

下面給出測試程式碼

1. class Singleton {
2. privatebyte[] a = newbyte[6*1024*1024];
3. privatestatic Singleton singleton = new Singleton();
4. private Singleton(){}
5. publicstatic Singleton getInstance(){
6. return singleton;
7. }
8. }
9. class Obj {
10. privatebyte[] a = newbyte[3*1024*1024];
11. }
12. publicclass Client{
13. public
    staticvoid main(String[] args) throws Exception{
14. Singleton.getInstance();
15. while(true){
16. new Obj();
17. }
18. }
19. }

class Singleton {
	private byte[] a = new byte[6*1024*1024];
	private static Singleton singleton = new Singleton();
	private Singleton(){}
	
	public static Singleton getInstance(){
		return singleton;
	}
}

class Obj {
	private byte[] a = new byte[3*1024*1024];
}

public class Client{
	public static void main(String[] args) throws Exception{
		Singleton.getInstance();
		while(true){
			new Obj();
		}
	}
}

本段程式的目的是模擬j2ee容器，首先例項化單例類，這個單例類佔6M記憶體，然後程式進入死迴圈，不斷的建立物件，逼迫jvm進行垃圾回收，然後觀察垃圾收集資訊，如果進行垃圾收集後，記憶體仍然大於6M，則說明垃圾回收不會回收單例物件。

執行本程式使用的虛擬機器是hotspot虛擬機器，也就是我們使用的最多的java官方提供的虛擬機器，俗稱jdk，版本是jdk1.6.0_12

執行時vm arguments引數為：-verbose:gc -Xms20M -Xmx20M，意思是每次jvm進行垃圾回收時顯示記憶體資訊，jvm的記憶體設為固定20M。

執行結果：

……

[Full GC 18566K->6278K(20352K), 0.0101066 secs]

[GC 18567K->18566K(20352K), 0.0001978 secs]

[Full GC 18566K->6278K(20352K), 0.0088229 secs]

……

從執行結果中可以看到總有6M空間沒有被收集。因此，筆者認為，至少在hotspot虛擬機器中，垃圾回收是不會回收單例物件的。

後來查閱了一些相關的資料，hotspot虛擬機器的垃圾收集演算法使用根搜尋演算法。這個演算法的基本思路是：對任何“活”的物件，一定能最終追溯到其存活在堆疊或靜態儲存區之中的引用。通過一系列名為根（GC Roots）的引用作為起點，從這些根開始搜尋，經過一系列的路徑，如果可以到達java堆中的物件，那麼這個物件就是“活”的，是不可回收的。可以作為根的物件有：

• 虛擬機器棧（棧楨中的本地變量表）中的引用的物件。
• 方法區中的類靜態屬性引用的物件。
• 方法區中的常量引用的物件。
• 本地方法棧中JNI的引用的物件。

方法區是jvm的一塊記憶體區域，用來存放類相關的資訊。很明顯，java中單例模式建立的物件被自己類中的靜態屬性所引用，符合第二條，因此，單例物件不會被jvm垃圾收集。

雖然jvm堆中的單例物件不會被垃圾收集，但是單例類本身如果長時間不用會不會被收集呢？因為jvm對方法區也是有垃圾收集機制的。如果單例類被收集，那麼堆中的物件就會失去到根的路徑，必然會被垃圾收集掉。對此，筆者查閱了hotspot虛擬機器對方法區的垃圾收集方法，jvm解除安裝類的判定條件如下：

• 該類所有的例項都已經被回收，也就是java堆中不存在該類的任何例項。
• 載入該類的ClassLoader已經被回收。
• 該類對應的java.lang.Class物件沒有任何地方被引用，無法在任何地方通過反射訪問該類的方法。

只有三個條件都滿足，jvm才會在垃圾收集的時候解除安裝類。顯然，單例的類不滿足條件一，因此單例類也不會被解除安裝。也就是說，只要單例類中的靜態引用指向jvm堆中的單例物件，那麼單例類和單例物件都不會被垃圾收集，依據根搜尋演算法，物件是否會被垃圾收集與未被使用時間長短無關，僅僅在於這個物件是不是“活”的。假如一個物件長久未使用而被回收，那麼收集演算法應該是最近最長未使用演算法，最近最長未使用演算法一般用在作業系統的內外存交換中，如果用在虛擬機器垃圾回收中，豈不是太不安全了？以上是筆者的觀點。

因此筆者的觀點是：在hotspot虛擬機器1.6版本中，除非人為地斷開單例中靜態引用到單例物件的聯接，否則jvm垃圾收集器是不會回收單例物件的。