第一類記憶體溢位，也是大家認為最多，第一反應認為是的記憶體溢位，就是堆疊溢位：

那什麼樣的情況就是堆疊溢位呢？當你看到下面的關鍵字的時候它就是堆疊溢位了：

java.lang.OutOfMemoryError: ......java heap space.....

也就是當你看到heap相關的時候就肯定是堆疊溢位了，此時如果程式碼沒有問題的情況下，適當調整-Xmx和-Xms是可以避免的，不過一定是程式碼沒有問題的前提，為什麼會溢位呢，要麼程式碼有問題，要麼訪問量太多並且每個訪問的時間太長或者資料太多，導致資料釋放不掉，因為垃圾回收器是要找到那些是垃圾才能回收，這裡它不會認為這些東西是垃圾，自然不會去回收了；主意這個溢位之前，可能系統會提前先報錯關鍵字為：

java.lang.OutOfMemoryError:GC over head limit exceeded

這種情況是當系統處於高頻的GC狀態，而且回收的效果依然不佳的情況，就會開始報這個錯誤，這種情況一般是產生了很多不可以被釋放的物件，有可能是引用使用不當導致，或申請大物件導致，但是java heap space的記憶體溢位有可能提前不會報這個錯誤，也就是可能記憶體就直接不夠導致，而不是高頻GC.

第二類記憶體溢位，PermGen的溢位，或者PermGen 滿了的提示，你會看到這樣的關鍵字：

關鍵資訊為:

java.lang.OutOfMemoryError: PermGen space

原因：系統的程式碼非常多或引用的第三方包非常多、或程式碼中使用了大量的常量、或通過intern注入常量、或者通過動態程式碼載入等方法，導致常量池的膨脹，雖然JDK 1.5以後可以通過設定對永久帶進行回收，但是我們希望的是這個地方是不做GC的，它夠用就行，所以一般情況下今年少做類似的操作，所以在面對這種情況常用的手段是：增加-XX:PermSize和-XX:MaxPermSize的大小。

第三類記憶體溢位：在使用ByteBuffer中的allocateDirect()的時候會用到，很多javaNIO的框架中被封裝為其他的方法

溢位關鍵字：

java.lang.OutOfMemoryError: Direct buffer memory
如果你在直接或間接使用了ByteBuffer中的allocateDirect方法的時候，而不做clear的時候就會出現類似的問題，常規的引用程式IO輸出存在一個核心態與使用者態的轉換過程，也就是對應直接記憶體與非直接記憶體，如果常規的應用程式你要將一個檔案的內容輸出到客戶端需要通過OS的直接記憶體轉換拷貝到程式的非直接記憶體（也就是heap中），然後再輸出到直接記憶體由作業系統傳送出去，而直接記憶體就是由OS和應用程式共同管理的，而非直接記憶體可以直接由應用程式自己控制的記憶體，jvm垃圾回收不會回收掉直接記憶體這部分的記憶體，所以要注意了哦。

如果經常有類似的操作，可以考慮設定引數：-XX:MaxDirectMemorySize

第四類記憶體溢位錯誤：

溢位關鍵字：

java.lang.StackOverflowError

這個引數直接說明一個內容，就是-Xss太小了，我們申請很多區域性呼叫的棧針等內容是存放在使用者當前所持有的執行緒中的，執行緒在jdk 1.4以前預設是256K，1.5以後是1M，如果報這個錯，只能說明-Xss設定得太小，當然有些廠商的JVM不是這個引數，本文僅僅針對Hotspot VM而已；不過在有必要的情況下可以對系統做一些優化，使得-Xss的值是可用的。

第五類記憶體溢位錯誤：

溢位關鍵字：

java.lang.OutOfMemoryError: unable to create new native thread

上面第四種溢位錯誤，已經說明了執行緒的記憶體空間，其實執行緒基本只佔用heap以外的記憶體區域，也就是這個錯誤說明除了heap以外的區域，無法為執行緒分配一塊記憶體區域了，這個要麼是記憶體本身就不夠，要麼heap的空間設定得太大了，導致了剩餘的記憶體已經不多了，而由於執行緒本身要佔用記憶體，所以就不夠用了，說明了原因，如何去修改，不用我多說，你懂的。

第六類記憶體溢位：

溢位關鍵字

java.lang.OutOfMemoryError: request {} byte for {}out of swap

這類錯誤一般是由於地址空間不夠而導致。

六大類常見溢位已經說明JVM中99%的溢位情況，要逃出這些溢位情況非常困難，除非一些很怪異的故障問題會發生，比如由於實體記憶體的硬體問題，導致了code cache的錯誤（在由byte code轉換為native code的過程中出現，但是概率極低），這種情況記憶體 會被直接crash掉，類似還有swap的頻繁互動在部分系統中會導致系統直接被crash掉，OS地址空間不夠的話，系統根本無法啟動，呵呵；JNI的濫用也會導致一些本地記憶體無法釋放的問題，所以儘量避開JNI；socket連線資料開啟過多的socket也會報類似：IOException: Too many open files等錯誤資訊。

JNI就不用多說了，儘量少用，除非你的程式碼太牛B了，我無話可說，呵呵，這種記憶體如果沒有在被呼叫的語言內部將記憶體釋放掉（如C語言），那麼在程序結束前這些記憶體永遠釋放不掉，解決辦法只有一個就是將程序kill掉。

另外GC本身是需要記憶體空間的，因為在運算和中間資料轉換過程中都需要有記憶體，所以你要保證GC的時候有足夠的記憶體哦，如果沒有的話GC的過程將會非常的緩慢。

順便這裡就提及一些新的CMS GC的內容和策略（有點亂，每次寫都很亂，但是能看多少看多少吧）：

首先我再寫一次一前部落格中的已經寫過的內容，就是很多引數沒啥建議值，建議值是自己在現場根據實際情況科學計算和測試得到的綜合效果，建議值沒有絕對好的，而且預設值很多也是有問題的，因為不同的版本和廠商都有很大的區別，預設值沒有永久都是一樣的，就像-Xss引數的變化一樣，要看到你當前的java程式heap的大致情況可以這樣看看（以下引數是隨便設定的，並不是什麼預設值）：

$sudo jmap -heap `pgrep java` 
Attaching to process ID 4280, please wait...
Debugger attached successfully.
Server compiler detected.
JVM version is 19.1-b02

using thread-local object allocation.
Parallel GC with 8 thread(s)

Heap Configuration:
MinHeapFreeRatio = 40
MaxHeapFreeRatio = 70
MaxHeapSize = 1073741824 (1024.0MB)
NewSize = 134217728 (128.0MB)
MaxNewSize = 134217728 (128.0MB)
OldSize = 5439488 (5.1875MB)
NewRatio = 2
SurvivorRatio = 8
PermSize = 134217728 (128.0MB)
MaxPermSize = 268435456 (256.0MB)

Heap Usage:
PS Young Generation
Eden Space:
capacity = 85721088 (81.75MB)
used = 22481312 (21.439849853515625MB)
free = 63239776 (60.310150146484375MB)
26.22611602876529% used
From Space:
capacity = 24051712 (22.9375MB)
used = 478488 (0.45632171630859375MB)
free = 23573224 (22.481178283691406MB)
1.9894134770946867% used
To Space:
capacity = 24248320 (23.125MB)
used = 0 (0.0MB)
free = 24248320 (23.125MB)
0.0% used
PS Old Generation
capacity = 939524096 (896.0MB)
used = 16343864 (15.586723327636719MB)
free = 923180232 (880.4132766723633MB)
1.7395896571023124% used
PS Perm Generation
capacity = 134217728 (128.0MB)
used = 48021344 (45.796722412109375MB)
free = 86196384 (82.20327758789062MB)
35.77868938446045% used

付：sudo是需要拿到管理員許可權，如果你的系統許可權很大那麼就不需要了，最後的grep java那個內容如果不對，可以直接通過jps或者ps命令將和java相關的程序號直接寫進去，如：java -map 4280，這個引數其實完全可以通過jstat工具來替代，而且看到的效果更加好，這個引數在線上應用中，儘量少用（尤其是高併發的應用中），可能會觸發JVM的bug，導致應用掛起；在jvm 1.6u14後可以編寫任意一段程式，然後在執行程式的時候，增加引數為：-XX:+PrintFlagsFinal來輸出當前JVM中執行時的引數值，或者通過jinfo來檢視，jinfo是非常強大的工具，可以對部分引數進行動態修改，當然記憶體相關的東西是不能修改的，只能增加一些不是很相關的引數，有關JVM的工具使用，後續文章中如果有機會我們再來探討，不是本文的重點；補充：關於引數的預設值對不同的JVM版本、不同的廠商、運行於不同的環境（一般和位數有關係）預設值會有區別。

OK，再說下反覆的一句，沒有必要的話就不要亂設定引數，引數不是拿來玩的，預設的引數對於這門JDK都是有好處的，關鍵是否適合你的應用場景，一般來講你常規的只需要設定以下幾個引數就可以了：

-server 表示為伺服器端，會提供很多伺服器端預設的配置，如並行回收，而伺服器上一般這個引數都是預設的，所以都是可以省掉，與之對應的還有一個-client引數，一般在64位機器上，JVM是預設啟動-server引數，也就是預設啟動並行GC的，但是是ParallelGC而不是ParallelOldGC，兩者演算法不同（後面會簡單說明下），而比較特殊的是windows 32位上預設是-client，這兩個的區別不僅僅是預設的引數不一樣，在jdk包下的jre包下一般會包含client和server包，下面分別對應啟動的動態連結庫，而真正看到的java、javac等相關命令指示一個啟動導向，它只是根據命令找到對應的JVM並傳入jvm中進行啟動，也就是看到的java.exe這些檔案並不是jvm；說了這麼多，最終總結一下就是，-server和-client就是完全不同的兩套VM，一個用於桌面應用，一個用於伺服器的。

-Xmx 為Heap區域的最大值

-Xms 為Heap區域的初始值，線上環境需要與-Xmx設定為一致，否則capacity的值會來回飄動，飄得你心曠神怡，你懂的。

-Xss（或-ss） 這個其實也是可以預設的，如果你真的覺得有設定的必要，你就改下吧，1.5以後是1M的預設大小（指一個執行緒的native空間），如果程式碼不多，可以設定小點來讓系統可以接受更大的記憶體。注意，還有一個引數是-XX:ThreadStackSize，這兩個引數在設定的過程中如果都設定是有衝突的，一般按照JVM常理來說，誰設定在後面，就以誰為主，但是最後發現如果是在1.6以上的版本，-Xss設定在後面的確都是以-Xss為主，但是要是-XX:ThreadStackSize設定在後面，主執行緒還是為-Xss為主，而其它執行緒以-XX:ThreadStackSize為主，主執行緒做了一個特殊判定處理；單獨設定都是以本身為主，-Xss不設定也不會採用其預設值，除非兩個都不設定會採用-Xss的預設值。另外這個引數針對於hotspot的vm，在IBM的jvm中，還有一個引數為-Xoss，主要原因是IBM在對棧的處理上有運算元棧和方法棧等各種不同的棧種類，而hotspot不管是什麼棧都放在一個私有的執行緒內部的，不區分是什麼棧，所以只需要設定一個引數，而IBM的J9不是這樣的；有關棧上的細節，後續我們有機會專門寫文章來說明。

-XX:PermSize與-XX:MaxPermSize兩個包含了class的裝載的位置，或者說是方法區（但不是本地方法區），在Hotspot預設情況下為64M，主意全世界的JVM只有hostpot的VM才有Perm的區域，或者說只有hotspot才有對使用者可以設定的這塊區域，其他的JVM都沒有，其實並不是沒有這塊區域，而是這塊區域沒有讓使用者來設定，其實這塊區域本身也不應該讓使用者來設定，我們也沒有一個明確的說法這塊空間必須要設定多大，都是拍腦袋設定一個數字，如果釋出到線上看下如果用得比較多，就再多點，如果用的少，就減少點，而這塊區域和效能關鍵沒有多大關係，只要能裝下就OK，並且時不時會因為Perm不夠而導致Full GC，所以交給開發者來調節這個引數不知道是怎麼想的；所以Oracle將在新一代JVM中將這個區域徹底刪掉，也就是對使用者透明，G1的如果真正穩定起來，以後JVM的啟動引數將會非常簡單，而且理論上管理再大的記憶體也是沒有問題的，其實G1（garbage first，一種基於region的垃圾收集回收器）已經在hotspot中開始有所試用，不過目前效果不好，還不如CMS呢，所以只是試用，G1已經作為ORACLE對JVM研發的最高重點，CMS自現在最高版本後也不再有新功能（可以修改bug），該專案已經進行5年，尚未釋出正式版，CMS是四五年前釋出的正式版，但是是最近一兩年才開始穩定，而G1的複雜性將會遠遠超越CMS，所以要真正使用上G1還有待考察，全世界目前只有IBM J9真正實現了G1論文中提到的思想（論文於05年左右發表），IBM已經將J9應用於websphere中，但是並不代表這是全世界最好的jvm，全世界最好的jvm是Azul(無停頓垃圾回收演算法和一個零開銷的診斷/監控工具)，幾乎可以說這個jvm是沒有暫停的，在全世界很多頂尖級的公司使用，不過價格非常貴，不能直接使用，目前這個jvm的主導者在研究JRockit，而目前hotspot和JRockit都是Oracle的，所以他們可能會合並，所以我們應該對JVM的效能充滿信心。

也就是說你常用的情況下只需要設定4個引數就OK了，除非你的應用有些特殊，否則不要亂改，那麼來看看一些其他情況的引數吧：

先來看個不大常用的，就是大家都知道JVM新的物件應該說幾乎百分百的在Eden裡面，除非Eden真的裝不下，我們不考慮這種變態的問題，因為線上環境Eden區域都是不小的，來降低GC的次數以及全域性 GC的概率；而JVM習慣將記憶體按照較為連續的位置進行分配，這樣使得有足夠的記憶體可以被分配，減少碎片，那麼對於記憶體最後一個位置必然就有大量的徵用問題，JVM在高一點的版本里面提出了為每個執行緒分配一些私有的區域來做來解決這個問題，而1.5後的版本還可以動態管理這些區域，那麼如何自己設定和檢視這些區域呢，看下英文全稱為：Thread Local Allocation Buffer，簡稱就是：TLAB，即記憶體本地的持有的buffer，設定引數有：

-XX:+UseTLAB 啟用這種機制的意思
-XX:TLABSize=<size in kb> 設定大小，也就是本地執行緒中的私有區域大小（只有這個區域放不下才會到Eden中去申請）。
-XX:+ResizeTLAB 是否啟動動態修改

這幾個引數在多CPU下非常有用。

-XX:+PrintTLAB 可以輸出TLAB的內容。

下面再閒扯些其它的引數：

如果你需要對Yong區域進行並行回收應該如何修改呢？在jdk1.5以後可以使用引數：

-XX:+UseParNewGC

注意： 與它衝突的引數是：-XX:+UseParallelOldGC和-XX:+UseSerialGC，如果需要用這個引數，又想讓整個區域是並行回收的，那麼就使用-XX:+UseConcMarkSweepGC引數來配合，其實這個引數在使用了CMS後，預設就會啟動該引數，也就是這個引數在CMS GC下是無需設定的，後面會提及到這些引數。

預設伺服器上的對Full並行GC策略為（這個時候Yong空間回收的時候啟動PSYong演算法，也是並行回收的）：

-XX:+UseParallelGC

另外，在jdk1.5後出現一個新的引數如下，這個對Yong的回收演算法和上面一樣，對Old區域會有所區別，上面對Old回收的過程中會做一個全域性的Compact，也就是全域性的壓縮操作，而下面的演算法是區域性壓縮，為什麼要區域性壓縮呢？是因為JVM發現每次壓縮後再邏輯上資料都在Old區域的左邊位置，申請的時候從左向右申請，那麼生命力越長的物件就一般是靠左的，所以它認為左邊的物件就是生命力很強，而且較為密集的，所以它針對這種情況進行部分密集，但是這兩種演算法mark階段都是會暫停的，而且存活的物件越多活著的越多；而ParallelOldGC會進行部分壓縮演算法（主意一點，最原始的copy演算法是不需要經過mark階段，因為只需要找到一個或活著的就只需要做拷貝就可以，而Yong區域借用了Copy演算法，只是唯一的區別就是傳統的copy演算法是採用兩個相同大小的記憶體來拷貝，浪費空間為50%，所以分代的目標就是想要實現很多優勢所在，認為新生代85%以上的物件都應該是死掉的，所以S0和S1一般並不是很大），該演算法為jdk 1.5以後對於絕大部分應用的最佳選擇。

-XX:+UseParallelOldGC

-XX:ParallelGCThread=12：並行回收的執行緒數，最好根據實際情況而定，因為執行緒多往往存在徵用排程和上下文切換的開銷；而且也並非CPU越多執行緒數也可以設定越大，一般設定為12就再增加用處也不大，主要是演算法本身內部的徵用會導致其執行緒的極限就是這樣。

設定Yong區域大小：

-Xmn Yong區域的初始值和最大值一樣大

-XX:NewSize和-XX:MaxNewSize如果設定以為一樣大就是和-Xmn，在JRockit中會動態變化這些引數，根據實際情況有可能會變化出兩個Yong區域，或者沒有Yong區域，有些時候會生出來一個半長命物件區域；這裡除了這幾個引數外，還有一個引數是NewRatio是設定Old/Yong的倍數的，這幾個引數都是有衝突的，伺服器端建議是設定-Xmn就可以了，如果幾個引數全部都有設定，-Xmn和-XX:NewSize與-XX:MaxNewSize將是誰設定在後面，以誰的為準，而-XX:NewSize -XX:MaxNewSize與-XX:NewRatio時，那麼引數設定的結果可能會以下這樣的（jdk 1.4.1後）：

min(MaxNewSize,max(NewSize, heap/(NewRatio+1)))

-XX:NewRatio為Old區域為Yong的多少倍，間接設定Yong的大小，1.6中如果使用此引數，則預設會在適當時候被動態調整，具體請看下面引數UseAdaptiveSizepollcy 的說明。

三個引數不要同時設定，因為都是設定Yong的大小的。

-XX:SurvivorRatio：該引數為Eden與兩個求助空間之一的比例，注意Yong的大小等價於Eden + S0 + S1，S0和S1的大小是等價的，這個引數為Eden與其中一個S區域的大小比例，如引數為8，那麼Eden就佔用Yong的80%，而S0和S1分別佔用10%。

以前的老版本有一個引數為：-XX:InitialSurivivorRatio，如果不做任何設定，就會以這個引數為準，這個引數的預設值就是8，不過這個引數並不是Eden/Survivor的大小，而是Yong/Survivor，所以所以預設值8，代表每一個S區域的空間大小為Yong區域的12.5%而不是10%。另外順便提及一下，每次大家看到GC日誌的時候，GC日誌中的每個區域的最大值，其中Yong的空間最大值，始終比設定的Yong空間的大小要小一點，大概是小12.5%左右，那是因為每次可用空間為Eden加上一個Survivor區域的大小，而不是整個Yong的大小，因為可用空間每次最多是這樣大，兩個Survivor區域始終有一塊是空的，所以不會加上兩個來計算。

-XX:MaxTenuringThreshold=15：在正常情況下，新申請的物件在Yong區域發生多少次GC後就會被移動到Old（非正常就是S0或S1放不下或者不太可能出現的Eden都放不下的物件），這個引數一般不會超過16（因為計數器從0開始計數，所以設定為15的時候相當於生命週期為16）。

要檢視現在的這個值的具體情況，可以使用引數：-XX:+PrintTenuringDistribution

通過上面的jmap應該可以看出我的機器上的MinHeapFreeRatio和MaxHeapFreeRatio分別為40個70，也就是大家經常說的在GC後剩餘空間小於40%時capacity開始增大，而大於70%時減小，由於我們不希望讓它移動，所以這兩個引數幾乎沒有意義，如果你需要設定就設定引數為：

-XX:MinHeapFreeRatio=40
-XX:MaxHeapFreeRatio=70

JDK 1.6後有一個動態調節板塊的，當然如果你的每一個板塊都是設定固定值，這個引數也沒有用，不過如果是非固定的，建議還是不要動態調整，預設是開啟的，建議將其關掉，引數為：

-XX:+UseAdaptiveSizepollcy 建議使用-XX:-UseAdaptiveSizepollcy關掉，為什麼當你的引數設定了NewRatio、Survivor、MaxTenuringThreshold這幾個引數如果在啟動了動態更新情況下，是無效的，當然如果你設定-Xmn是有效的，但是如果設定的比例的話，初始化可能會按照你的引數去執行，不過執行過程中會通過一定的演算法動態修改，監控中你可能會發現這些引數會發生改變，甚至於S0和S1的大小不一樣。

如果啟動了這個引數，又想要跟蹤變化，那麼就使用引數：-XX:+PrintAdaptiveSizePolicy

上面已經提到，javaNIO中通過Direct記憶體來提高效能，這個區域的大小預設是64M，在適當的場景可以設定大一些。

-XX:MaxDirectMemorySize

一個不太常用的引數：

-XX:+ScavengeBeforeFullGC 預設是開啟狀態，在full GC前先進行minor GC。

對於java堆中如果要設定大頁記憶體，可以通過設定引數：

付：此引數必須在作業系統的核心支援的基礎上，需要在OS級別做操作為：

echo 1024 > /proc/sys/vm/nr_hugepages

echo 2147483647 > /proc/sys/kernel/shmmax

-XX:+UseLargePages

-XX:LargePageSizeInBytes

此時整個JVM都將在這塊記憶體中，否則全部不在這塊記憶體中。

javaIO的臨時目錄設定

-Djava.io.tmpdir

jstack會去尋找/tmp/hsperfdata_admin下去尋找與程序號相同的檔案，32位機器上是沒有問題的，64為機器的是有BUG的，在jdk 1.6u23版本中已經修復了這個bug，如果你遇到這個問題，就需要升級JDK了。

還記得上次說的平均晉升大小嗎，在並行GC時，如果平均晉升大小大於old剩餘空間，則發生full GC，那麼當小於剩餘空間時，也就是平均晉升小於剩餘空間，但是剩餘空間小於eden + 一個survivor的空間時，此時就依賴於引數：

-XX:-HandlePromotionFailure

啟動該引數時，上述情況成立就發生minor gc（YGC），大於則發生full gc（major gc）。

一般預設直接分配的物件如果大於Eden的一半就會直接晉升到old區域，但是也可以通過引數來指定：

-XX:PretenureSizeThreshold=2m 我個人不建議使用這個引數

也就是當申請物件大於這個值就會晉升到old區域。

傳說中GC時間的限制，一個是通過比例限制，一個是通過最大暫停時間限制，但是GC時間能限制麼，呵呵，在增量中貌似可以限制，不過不能限制住GC總體的時間，所以這個引數也不是那麼關鍵。

-XX:GCTimeRatio=

-XX:MaxGCPauseMillis

-XX:GCTimeLimit

要看到真正暫停的時間就一個是看GCDetail的日誌，另一個是設定引數看：

-XX:+PrintGCApplicationStoppedTime

有些人，有些人就是喜歡在程式碼裡面裡頭寫System.gc()，耍酷，這個不是測試程式是線上業務，這樣將會導致N多的問題，不多說了，你應該懂的，不懂的話看下書吧，而RMI是很不聽話的一個鳥玩意，EJB的框架也是基於RMI寫的，RMI為什麼不聽話呢，就是它自己在裡面非要搞個System.gc()，哎，為了放置頻繁的做，頻繁的做，你就將這個命令的執行禁用掉吧，當然程式不用改，不然那些EJB都跑步起來了，呵呵：

-XX:+DisableExplicitGC 預設是沒有禁用掉，寫成+就是禁用掉的了，但是有些時候在使用allocateDirect的時候，很多時候還真需要System.gc來強制回收這塊資源。

記憶體溢位時匯出溢位的錯誤資訊：
-XX:+HeapDumpOnOutOfMemoryError

-XX:HeapDumpPath=/home/xieyu/logs/ 這個引數指定匯出時的路徑，不然匯出的路徑就是虛擬機器的目標位置，不好找了，預設的檔名是：java_pid<程序號>.hprof，這個檔案可以類似使用jmap -dump:file=....,format=b <pid>來dump類似的內容，檔案字尾都是hprof，然後下載mat工具進行分析即可（不過記憶體有多大dump檔案就多大，而本地分析的時候記憶體也需要那麼大，所以很多時候下載到本地都無法啟動是很正常的），後續文章有機會我們來說明這些工具，另外jmap -dump引數也不要經常用，會導致應用掛起哦;另外此引數只會在第一次輸出OOM的時候才會進行堆的dump操作（java heap的溢位是可以繼續執行再執行的程式的，至於web應用是否服務要看應用伺服器自身如何處理，而c heap區域的溢位就根本沒有dump的機會，因為直接就宕機了，目前系統無法看到c heap的大小以及內部變化，要看大小隻能間接通過看JVM程序的記憶體大小（top或類似引數），這個大小一般會大於heap+perm的大小，多餘的部分基本就可以認為是c heap的大小了，而看內部變化呢只有google perftools可以達到這個目的），如果記憶體過大這個dump操作將會非常長，所以hotspot如果以後想管理大記憶體，這塊必須有新的辦法出來。

最後，用dump出來的檔案，通過mat分析出來的結果往往有些時候難以直接確定到底哪裡有問題，可以看到的維度大概有：那個類使用的記憶體最多，以及每一個執行緒使用的記憶體，以及執行緒內部每一個呼叫的類和方法所使用的記憶體，但是很多時候無法判定到底是程式什麼地方呼叫了這個類或者方法，因為這裡只能看到最終消耗記憶體的類，但是不知道誰使用了它，一個辦法是掃描程式碼，但是太笨重，而且如果是jar包中呼叫了就不好弄了，另一種方法是寫agent，那麼就需要相應的配合了，但是有一個非常好的工具就是btrace工具（jdk 1.7貌似還不支援），可以跟蹤到某個類的某個方法被那些類中的方法呼叫過，那這個問題就好說了，只要知道開銷記憶體的是哪一個類，就能知道誰呼叫過它，OK，關於btrace的不是本文重點，網上都有，後續文章有機會再探討，
原理：
No performance impact during runtime（無效能影響）
Dumping a –Xmx512m heap
Create a 512MB .hprof file（512M記憶體就dump出512M的空間大小）
JVM is “dead” during dumping（死掉時dump）
Restarting JVM during this dump will cause unusable .hprof file（重啟導致檔案不可用）

註明的NUMA架構，在JVM中開始支援，當然也需要CPU和OS的支援才可以，需要設定引數為：

-XX:+UseNUMA 必須在並行GC的基礎上才有的

老年代無法分配區域的最大等待時間為(預設值為0，但是也不要去動它)：

-XX:GCExpandToAllocateDelayMillis

讓JVM中所有的set和get方法轉換為原生代碼：

-XX:+UseFastAccessorMethods

以時間戳輸出Heap的利用率

-XX:+PrintHeapUsageOverTime

在64bit的OS上面（其實一般達不到57位左右），由於指標會放大為8個byte，所以會導致空間使用增加，當然，如果記憶體夠大，就沒有問題，但是如果升級到64bit系統後，只是想讓記憶體達到4G或者8G，那麼就完全可以通過很多指標壓縮為4byte就OK了，所以在提供以下引數(本引數於jdk 1.6u23後使用，並自動開啟，所以也不需要你設定，知道就OK)：

-XX:+UseCompressedOops 請注意：這個引數預設在64bit的環境下預設啟動，但是如果JVM的記憶體達到32G後，這個引數就會預設為不啟動，因為32G記憶體後，壓縮就沒有多大必要了，要管理那麼大的記憶體指標也需要很大的寬度了。

後臺JIT編譯優化啟動

-XX:+BackgroundCompilation

如果你要輸出GC的日誌以及時間戳，相關的引數有：

-XX:+PrintGCDetails 輸出GC的日誌詳情，包含了時間戳

-XX:+PrintGCTimeStamps 輸出GC的時間戳資訊，按照啟動JVM後相對時間的每次GC的相對秒值（毫秒在小數點後面），也就是每次GC相對啟動JVM啟動了多少秒後發生了這次GC

-XX:+PrintGCDateStamps輸出GC的時間資訊，會按照系統格式的日期輸出每次GC的時間

-XX:+PrintGCTaskTimeStamps輸出任務的時間戳資訊，這個細節上比較複雜，後續有文章來探討。

-XX:-TraceClassLoading 跟蹤類的裝載

-XX:-TraceClassUnloading 跟蹤類的解除安裝

-XX:+PrintHeapAtGC 輸出GC後各個堆板塊的大小。

將常量資訊GC資訊輸出到日誌檔案：

-Xloggc:/home/xieyu/logs/gc.log

現在面對大記憶體比較流行是是CMS GC（最少1.5才支援），首先明白CMS的全稱是什麼，不是傳統意義上的內容管理系統（Content Management System）哈，第一次我也沒看懂，它的全稱是：Concurrent Mark Sweep，三個單詞分別代表併發、標記、清掃（主意這裡沒有compact操作，其實CMS GC的確沒有compact操作），也就是在程式執行的同時進行標記和清掃工作，至於它的原理前面有提及過，只是有不同的廠商在上面做了一些特殊的優化，比如一些廠商在標記根節點的過程中，標記完當前的根，那麼這個根下面的內容就不會被暫停恢復運行了，而移動過程中，通過讀屏障來看這個記憶體是不是發生移動，如果在移動稍微停一下，移動過去後再使用，hotspot還沒這麼厲害，暫停時間還是挺長的，只是相對其他的GC策略在面對大記憶體來講是不錯的選擇。

下面看一些CMS的策略（併發GC總時間會比常規的並行GC長，因為它是在執行時去做GC，很多資源徵用都會影響其GC的效率，而總體的暫停時間會短暫很多很多，其並行執行緒數預設為：（上面設定的並行執行緒數 + 3）/ 4

付：CMS是目前Hotspot管理大記憶體最好的JVM，如果是常規的JVM，最佳選擇為ParallelOldGC，如果必須要以響應時間為準，則選擇CMS，不過CMS有兩個隱藏的隱患：

1、CMS GC雖然是併發且並行執行的GC，但是初始化的時候如果採用預設值92%（JVM 1.5的白皮書上描述為68%其實是錯誤的，1.6是正確的），就很容易出現問題，因為CMS GC僅僅針對Old區域，Yong區域使用ParNew演算法，也就是Old的CMS回收和Yong的回收可以同時進行，也就是回收過程中Yong有可能會晉升物件Old，並且業務也可以同時執行，所以92%基本開始啟動CMS GC很有可能old的記憶體就不夠用了，當記憶體不夠用的時候，就啟動Full GC，並且這個Full GC是序列的，所以如果弄的不好，CMS會比並行GC更加慢，為什麼要啟用序列是因為CMS GC、並行GC、序列GC的繼承關係決定的，簡單說就是它沒辦法去呼叫並行GC的程式碼，細節說後續有文章來細節說明），建議這個值設定為70%左右吧，不過具體時間還是自己決定。

2、CMS GC另一個大的隱患，其實不看也差不多應該清楚，看名字就知道，就是不會做Compact操作，它最噁心的地方也在這裡，所以上面才說一般的應用都不使用它，它只有記憶體垃圾非常多，多得無法分配晉升的空間的時候才會出現一次compact，但是這個是Full GC，也就是上面的序列，很恐怖的，所以記憶體不是很大的，不要考慮使用它，而且它的演算法十分複雜。

還有一些小的隱患是：和應用一起徵用CPU（不過這個不是大問題，增加CPU即可）、整個執行過程中時間比並行GC長（這個也不是大問題，因為我們更加關心暫停時間而不是執行時間，因為暫停會影響非常多的業務）。

啟動CMS為全域性GC方法(注意這個引數也不能上面的並行GC進行混淆，Yong預設是並行的，上面已經說過

-XX:+UseConcMarkSweepGC

在併發GC下啟動增量模式，只能在CMS GC下這個引數才有效。

-XX:+CMSIncrementalMode

啟動自動調節duty cycle，即在CMS GC中發生的時間比率設定，也就是說這段時間內最大允許發生多長時間的GC工作是可以調整的。

-XX:+CMSIncrementalPacing

在上面這個引數設定後可以分別設定以下兩個引數（引數設定的比率，範圍為0-100）：

-XX:CMSIncrementalDutyCycleMin=0
-XX:CMSIncrementalDutyCycle=10

增量GC上還有一個保護因子（CMSIncrementalSafetyFactor），不太常用；CMSIncrementalOffset提供增量GC連續時間比率的設定；CMSExpAvgFactor為增量併發的GC增加權重計算。

-XX:CMSIncrementalSafetyFactor=
-XX:CMSIncrementalOffset= 
-XX:CMSExpAvgFactor=

是否啟動並行CMS GC（預設也是開啟的）

-XX:+CMSParallelRemarkEnabled

要單獨對CMS GC設定並行執行緒數就設定（預設也不需要設定）：

-XX:ParallelCMSThreads

對PernGen進行垃圾回收：

JDK 1.5在CMS GC基礎上需要設定引數（也就是前提是CMS GC才有）：

-XX:+CMSClassUnloadingEnabled -XX:+CMSPermGenSweepingEnabled

1.6以後的版本無需設定：-XX:+CMSPermGenSweepingEnabled，注意，其實一直以來Full GC都會觸發對Perm的回收過程，CMS GC需要有一些特殊照顧，雖然VM會對這塊區域回收，但是Perm回收的條件幾乎不太可能實現，首先需要這個類的classloader必須死掉，才可以將該classloader下所有的class幹掉，也就是要麼全部死掉，要麼全部活著；另外，這個classloader下的class沒有任何object在使用，這個也太苛刻了吧，因為常規的物件申請都是通過系統預設的，應用伺服器也有自己預設的classloader，要讓它死掉可能性不大，如果這都死掉了，系統也應該快掛了。

CMS GC因為是在程式執行時進行GC，不會暫停，所以不能等到不夠用的時候才去開啟GC，官方說法是他們的預設值是68%，但是可惜的是文件寫錯了，經過很多測試和原始碼驗證這個引數應該是在92%的時候被啟動，雖然還有8%的空間，但是還是很可憐了，當CMS發現記憶體實在不夠的時候又回到常規的並行GC，所以很多人在沒有設定這個引數的時候發現CMS GC並沒有神馬優勢嘛，和並行GC一個鳥樣子甚至於更加慢，所以這個時候需要設定引數（這個引數在上面已經說過，啟動CMS一定要設定這個引數）：

-XX:CMSInitiatingOccupancyFraction=70

這樣保證Old的記憶體在使用到70%的時候，就開始啟動CMS了；如果你真的想看看預設值，那麼就使用引數：-XX:+PrintCMSInitiationStatistics 這個變數只有JDK 1.6可以使用 1.5不可以，檢視實際值-XX:+PrintCMSStatistics；另外，還可以設定引數-XX:CMSInitiatingPermOccupancyFraction來設定Perm空間達到多少時啟動CMS GC，不過意義不大。

JDK 1.6以後有些時候啟動CMS GC是根據計算代價進行啟動，也就是不一定按照你指定的引數來設定的，如果你不想讓它按照所謂的成本來計算GC的話，那麼你就使用一個引數：-XX:+UseCMSInitiatingOccupancyOnly，預設是false，它就只會按照你設定的比率來啟動CMS GC了。如果你的程式中有System.gc以及設定了ExplicitGCInvokesConcurrent在jdk 1.6中，這種情況使用NIO是有可能產生問題的。

啟動CMS GC的compation操作，也就是發生多少次後做一次全域性的compaction：

-XX:+UseCMSCompactAtFullCollection

-XX:CMSFullGCsBeforeCompaction：發生多少次CMS Full GC，這個引數最好不要設定，因為要做compaction的話，也就是真正的Full GC是序列的，非常慢，讓它自己去決定什麼時候需要做compaction。

-XX:CMSMaxAbortablePrecleanTime=5000 設定preclean步驟的超時時間，單位為毫秒，preclean為cms gc其中一個步驟，關於cms gc步驟比較多，本文就不細節探討了。

並行GC在mark階段，可能會同時發生minor GC，old區域也可能發生改變，於是併發GC會對發生了改變的內容進行remark操作，這個觸發的條件是：

-XX:CMSScheduleRemarkEdenSizeThreshold

-XX:CMSScheduleRemarkEdenPenetration

即Eden區域多大的時候開始觸發，和eden使用量超過百分比多少的時候觸發，前者預設是2M，後者預設是50%。

但是如果長期不做remark導致old做不了，可以設定超時，這個超時預設是5秒，可以通過引數：

-XX:CMSMaxAbortablePrecleanTime

-XX:+ExplicitGCInvokesConcurrent 在顯示發生GC的時候，允許進行並行GC。

-XX:+ExplicitGCInvokesConcurrentAndUnloadsClasses 幾乎和上面一樣，只不過多一個對Perm區域的回收而已。

補充：

其實JVM還有很多的版本，很多的廠商，與其優化的原則，隨便舉兩個例子hotspot在GC中做的一些優化（這裡不說程式碼的編譯時優化或執行時優化）：

Eden申請的空間物件由Old區域的某個物件的一個屬性指向（也就是Old區域的這個空間不回收，Eden這塊就沒有必要考慮回收），所以Hotspot在CPU寫上面，做了一個屏障，當發生賦值語句的時候（對記憶體來講賦值就是一種寫操作），如果發現是一個新的物件由Old指向Eden，那麼就會將這個物件記錄在一個卡片機裡面，這個卡片機是有很多512位元組的卡片組成，當在YGC過程中，就基本不會去移動或者管理這塊物件（付：這種卡片機會在CMS GC的演算法中使用，不過和這個卡片不是放在同一個地方的，也是CMS GC的關鍵，對於CMS GC的演算法細節描述，後續文章我們單獨說明）。

Old區域對於一些比較大的物件，JVM就不會去管理個物件，也就是compact過程中不會去移動這塊物件的區域等等吧。

以上大部分引數為hotspot的自帶關於效能的引數，參考版本為JDK 1.5和1.6的版本，很多為個人經驗說明，不足以說明所有問題，如果有問題，歡迎探討；另外，JDK的引數是不是就只有這些呢，肯定並不是，我知道的也不止這些，但是有些覺得沒必要說出來的引數和一些數學運算的引數我就不想給出來了，比如像禁用掉GC的引數有神馬意義，我們的伺服器要是把這個禁用掉幹個屁啊，呵呵，做測試還可以用這玩玩，讓它不做GC直接溢位；還有一些什麼計算因子啥的，還有很多複雜的數學運算規則，要是把這個配置明白了，就太那個了，而且一般情況下也沒那個必要，JDK到現在的配置引數多達上500個以上，要知道完的話慢慢看吧，不過意義不大，而且要知道預設值最靠譜的是看原始碼而不是看文件，官方文件也只能保證絕大部是正確的，不能保證所有的是正確的。