相信有一定java開發經驗的人或多或少都會遇到OutOfMemoryError的問題，這個問題曾困擾了我很長時間，隨着解決各類問題經驗的積累以及對問題根源的探索，終於有了一個比較深入的認識。
在解決java內存溢出問題之前，需要對jvm（java虛擬機）的內存管理有一定的認識。jvm管理的內存大致包括三種不同類型的內存區域：Permanent Generation space（永久保存區域）、Heap space(堆區域)、Java Stacks(Java棧）。其中永久保存區域主要存放Class（類）和Meta的信息，Class第一次被Load的時候被放入PermGen space區域，Class需要存儲的內容主要包括方法和靜態屬性。堆區域用來存放Class的實例（即對象），對象需要存儲的內容主要是非靜態屬性。每次用new創建一個對象實例後，對象實例存儲在堆區域中，這部分空間也被jvm的垃圾回收機制管理。而Java棧跟大多數編程語言包括彙編語言的棧功能相似，主要基本類型變量以及方法的輸入輸出參數。Java程序的每個線程中都有一個獨立的堆棧。容易發生內存溢出問題的內存空間包括：Permanent Generation space和Heap space。
第一種OutOfMemoryError： PermGen space
發生這種問題的原意是程序中使用了大量的jar或class，使java虛擬機裝載類的空間不夠，與Permanent Generation space有關。解決這類問題有以下兩種辦法：
- 增加java虛擬機中的XX:PermSize和XX:MaxPermSize參數的大小，其中XX:PermSize是初始永久保存區域大小，XX:MaxPermSize是最大永久保存區域大小。如針對tomcat6.0，在catalina.sh 或catalina.bat文件中一系列環境變量名說明結束處（大約在70行左右） 增加一行：
JAVA_OPTS=" -XX:PermSize=64M -XX:MaxPermSize=128m"如果是windows服務器還可以在系統環境變量中設置。感覺用tomcat發佈sprint+struts+hibernate架構的程序時很容易發生這種內存溢出錯誤。使用上述方法，我成功解決了部署ssh項目的tomcat服務器經常宕機的問題。 - 清理應用程序中web-inf/lib下的jar，如果tomcat部署了多個應用，很多應用都使用了相同的jar，可以將共同的jar移到tomcat共同的lib下，減少類的重複加載。這種方法是網上部分人推薦的，我沒試過，但感覺減少不了太大的空間，最靠譜的還是第一種方法。
第二種OutOfMemoryError： Java heap space
發生這種問題的原因是java虛擬機創建的對象太多，在進行垃圾回收之間，虛擬機分配的到堆內存空間已經用滿了，與Heap space有關。解決這類問題有兩種思路：
- 檢查程序，看是否有死循環或不必要地重複創建大量對象。找到原因後，修改程序和算法。 我以前寫一個使用K-Means文本聚類算法對幾萬條文本記錄（每條記錄的特徵向量大約10來個）進行文本聚類時，由於程序細節上有問題，就導致了Java heap space的內存溢出問題，後來通過修改程序得到了解決。
- 增加Java虛擬機中Xms（初始堆大小）和Xmx（最大堆大小）參數的大小。如：
set JAVA_OPTS= -Xms256m -Xmx1024m
第三種OutOfMemoryError：unable to create new native thread
在java應用中，有時候會出現這樣的錯誤：OutOfMemoryError: unable to create new native thread.這種怪事是因爲JVM已經被系統分配了大量的內存(比如1.5G)，並且它至少要佔用可用內存的一半。有人發現，在線程個數很多的情況下，你分配給JVM的內存越多，那麼，上述錯誤發生的可能性就越大。
那麼是什麼原因造成這種問題呢？
每一個32位的進程最多可以使用2G的可用內存，因爲另外2G被操作系統保留。這裏假設使用1.5G給JVM，那麼還餘下500M可用內存。這500M內存中的一部分必須用於系統dll的加載，那麼真正剩下的也許只有400M，現在關鍵的地方出現了：當你使用Java創建一個線程，在JVM的內存裏也會創建一個Thread對象，但是同時也會在操作系統裏創建一個真正的物理線程(參考JVM規範)，操作系統會在餘下的400兆內存裏創建這個物理線程，而不是在JVM的1500M的內存堆裏創建。在jdk1.4裏頭，默認的棧大小是256KB，但是在jdk1.5裏頭，默認的棧大小爲1M每線程，因此，在餘下400M的可用內存裏邊我們最多也只能創建400個可用線程。
這樣結論就出來了，要想創建更多的線程，你必須減少分配給JVM的最大內存。還有一種做法是讓JVM宿主在你的JNI代碼裏邊。
給出一個有關能夠創建線程的最大個數的估算公式：
(MaxProcessMemory - JVMMemory - ReservedOsMemory) / (ThreadStackSize) = Number of threadsMaxProcessMemory - JVMMemory - ReservedOsMemory) / (ThreadStackSize) = Number of threads
對於jdk1.5而言，假設操作系統保留120M內存：
1.5GB JVM: (2GB-1.5Gb-120MB)/(1MB) = ~380 threads
1.0GB JVM: (2GB-1.0Gb-120MB)/(1MB) = ~880 threads JVM: (2GB-1.5Gb-120MB)/(1MB) = ~380 threads
1.0GB JVM: (2GB-1.0Gb-120MB)/(1MB) = ~880 threads
對於棧大小爲256KB的jdk1.4而言，
allocated to JVM: ~1520 threads
1.0GB allocated to JVM: ~3520 threads
對於這個異常我們首先需要判斷下，發生內存溢出時進程中到底都有什麼樣的線程，這些線程是否是應該存在的，是否可以通過優化來降低線程數； 另外一方面默認情況下java爲每個線程分配的棧內存大小是1M，通常情況下，這1M的棧內存空間是足足夠用了，因爲在通常在棧上存放的只是基礎類型的數據或者對象的引用，這些東西都不會佔據太大的內存， 我們可以通過調整jvm參數，降低爲每個線程分配的棧內存大小來解決問題，例如在jvm參數中添加-Xss128k將線程棧內存大小設置爲128k。
原文地址：http://outofmemory.cn/java/OutOfMemoryError/PermGen-space-Java-heap-space-unable-create-new-native-thread
對於JVM的內存寫過的文章已經有點多了，而且有點爛了，不過說那麼多大多數在解決OOM的情況，於此，本文就只闡述這個內容，攜帶一些分析和理解和部分擴展內容，也就是JVM宕機中的一些問題，OK，下面說下OOM的常見情況：
第一類內存溢出，也是大家認爲最多，第一反應認爲是的內存溢出，就是堆棧溢出：
那什麼樣的情況就是堆棧溢出呢？當你看到下面的關鍵字的時候它就是堆棧溢出了：
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個以上，要知道完的話慢慢看吧，不過意義不大，而且要知道默認值最靠譜的是看源碼而不是看文檔，官方文檔也只能保證絕大部是正確的，不能保證所有的是正確的。
本文最後追加在jdk 1.6u 24後通過上面說明的-XX:+PrintFlagsFinal輸出的參數以及默認值（還是那句話，在不同的平臺上是不一樣的），輸出的參數如下，可以看看JVM的參數是相當的多，參數如此之多，你只需要掌握關鍵即可，參數還有很多有衝突的，不要糾結於每一個參數的細節：
$java -XX:+PrintFlagsFinal
原文地址：http://www.open-open.com/home/space.php?uid=71669&do=blog&id=8891