669
係統架構-性能篇章1（應用係統性能2-OOM&參數配置）
對於JVM的內存寫過的文章已經有點多了，而且有點爛了，不過說那麼多大多數在解決OOM的情況，於此，本文就隻闡述這個內容，攜帶一些分析和理解和部分擴展內容，也就是JVM宕機中的一些問題，OK，下麵說下OOM的常見情況（本文基於jdk 1.6係列版本來編寫，其餘的版本未必完全適用）：
第一類內存溢出，也是大家認為最多，第一反應認為是的內存溢出，就是堆棧溢出：
那什麼樣的情況就是堆棧溢出呢？當你看到下麵的關鍵字的時候它就是堆棧溢出了：
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
uintx AdaptivePermSizeWeight = 20 {product}
uintx AdaptiveSizeDecrementScaleFactor = 4 {product}
uintx AdaptiveSizeMajorGCDecayTimeScale = 10 {product}
uintx AdaptiveSizePausePolicy = 0 {product}
uintx AdaptiveSizePolicyCollectionCostMargin = 50 {product}
uintx AdaptiveSizePolicyInitializingSteps = 20 {product}
uintx AdaptiveSizePolicyOutputInterval = 0 {product}
uintx AdaptiveSizePolicyWeight = 10 {product}
uintx AdaptiveSizeThroughPutPolicy = 0 {product}
uintx AdaptiveTimeWeight = 25 {product}
bool AdjustConcurrency = false {product}
bool AggressiveOpts = false {product}
intx AliasLevel = 3 {product}
intx AllocatePrefetchDistance = -1 {product}
intx AllocatePrefetchInstr = 0 {product}
intx AllocatePrefetchLines = 1 {product}
intx AllocatePrefetchStepSize = 16 {product}
intx AllocatePrefetchStyle = 1 {product}
bool AllowJNIEnvProxy = false {product}
bool AllowParallelDefineClass = false {product}
bool AllowUserSignalHandlers = false {product}
bool AlwaysActAsServerClassMachine = false {product}
bool AlwaysCompileLoopMethods = false {product}
intx AlwaysInflate = 0 {product}
bool AlwaysLockClassLoader = false {product}
bool AlwaysPreTouch = false {product}
bool AlwaysRestoreFPU = false {product}
bool AlwaysTenure = false {product}
bool AnonymousClasses = false {product}
bool AssertOnSuspendWaitFailure = false {product}
intx Atomics = 0 {product}
uintx AutoGCSelectPauseMillis = 5000 {product}
intx BCEATraceLevel = 0 {product}
intx BackEdgeThreshold = 100000 {pd product}
bool BackgroundCompilation = true {pd product}
uintx BaseFootPrintEstimate = 268435456 {product}
intx BiasedLockingBulkRebiasThreshold = 20 {product}
intx BiasedLockingBulkRevokeThreshold = 40 {product}
intx BiasedLockingDecayTime = 25000 {product}
intx BiasedLockingStartupDelay = 4000 {product}
bool BindGCTaskThreadsToCPUs = false {product}
bool BlockOffsetArrayUseUnallocatedBlock = false {product}
bool BytecodeVerificationLocal = false {product}
bool BytecodeVerificationRemote = true {product}
intx CICompilerCount = 1 {product}
bool CICompilerCountPerCPU = false {product}
bool CITime = false {product}
bool CMSAbortSemantics = false {product}
uintx CMSAbortablePrecleanMinWorkPerIteration = 100 {product}
intx CMSAbortablePrecleanWaitMillis = 100 {product}
uintx CMSBitMapYieldQuantum = 10485760 {product}
uintx CMSBootstrapOccupancy = 50 {product}
bool CMSClassUnloadingEnabled = false {product}
uintx CMSClassUnloadingMaxInterval = 0 {product}
bool CMSCleanOnEnter = true {product}
bool CMSCompactWhenClearAllSoftRefs = true {product}
uintx CMSConcMarkMultiple = 32 {product}
bool CMSConcurrentMTEnabled = true {product}
uintx CMSCoordinatorYieldSleepCount = 10 {product}
bool CMSDumpAtPromotionFailure = false {product}
uintx CMSExpAvgFactor = 50 {product}
bool CMSExtrapolateSweep = false {product}
uintx CMSFullGCsBeforeCompaction = 0 {product}
uintx CMSIncrementalDutyCycle = 10 {product}
uintx CMSIncrementalDutyCycleMin = 0 {product}
bool CMSIncrementalMode = false {product}
uintx CMSIncrementalOffset = 0 {product}
bool CMSIncrementalPacing = true {product}
uintx CMSIncrementalSafetyFactor = 10 {product}
uintx CMSIndexedFreeListReplenish = 4 {product}
intx CMSInitiatingOccupancyFraction = -1 {product}
intx CMSInitiatingPermOccupancyFraction = -1 {product}
intx CMSIsTooFullPercentage = 98 {product}
double CMSLargeCoalSurplusPercent = {product}
double CMSLargeSplitSurplusPercent = {product}
bool CMSLoopWarn = false {product}
uintx CMSMaxAbortablePrecleanLoops = 0 {product}
intx CMSMaxAbortablePrecleanTime = 5000 {product}
uintx CMSOldPLABMax = 1024 {product}
uintx CMSOldPLABMin = 16 {product}
uintx CMSOldPLABNumRefills = 4 {product}
uintx CMSOldPLABReactivityCeiling = 10 {product}
uintx CMSOldPLABReactivityFactor = 2 {product}
bool CMSOldPLABResizeQuicker = false {product}
uintx CMSOldPLABToleranceFactor = 4 {product}
bool CMSPLABRecordAlways = true {product}
uintx CMSParPromoteBlocksToClaim = 16 {product}
bool CMSParallelRemarkEnabled = true {product}
bool CMSParallelSurvivorRemarkEnabled = true {product}
bool CMSPermGenPrecleaningEnabled = true {product}
uintx CMSPrecleanDenominator = 3 {product}
uintx CMSPrecleanIter = 3 {product}
uintx CMSPrecleanNumerator = 2 {product}
bool CMSPrecleanRefLists1 = true {product}
bool CMSPrecleanRefLists2 = false {product}
bool CMSPrecleanSurvivors1 = false {product}
bool CMSPrecleanSurvivors2 = true {product}
uintx CMSPrecleanThreshold = 1000 {product}
bool CMSPrecleaningEnabled = true {product}
bool CMSPrintChunksInDump = false {product}
bool CMSPrintObjectsInDump = false {product}
uintx CMSRemarkVerifyVariant = 1 {product}
bool CMSReplenishIntermediate = true {product}
uintx CMSRescanMultiple = 32 {product}
uintx CMSRevisitStackSize = 1048576 {product}
uintx CMSSamplingGrain = 16384 {product}
bool CMSScavengeBeforeRemark = false {product}
uintx CMSScheduleRemarkEdenPenetration = 50 {product}
uintx CMSScheduleRemarkEdenSizeThreshold = 2097152 {product}
uintx CMSScheduleRemarkSamplingRatio = 5 {product}
double CMSSmallCoalSurplusPercent = {product}
double CMSSmallSplitSurplusPercent = {product}
bool CMSSplitIndexedFreeListBlocks = true {product}
intx CMSTriggerPermRatio = 80 {product}
intx CMSTriggerRatio = 80 {product}
bool CMSUseOldDefaults = false {product}
intx CMSWaitDuration = 2000 {product}
uintx CMSWorkQueueDrainThreshold = 10 {product}
bool CMSYield = true {product}
uintx CMSYieldSleepCount = 0 {product}
intx CMSYoungGenPerWorker = 16777216 {product}
uintx CMS_FLSPadding = 1 {product}
uintx CMS_FLSWeight = 75 {product}
uintx CMS_SweepPadding = 1 {product}
uintx CMS_SweepTimerThresholdMillis = 10 {product}
uintx CMS_SweepWeight = 75 {product}
bool CheckJNICalls = false {product}
bool ClassUnloading = true {product}
intx ClearFPUAtPark = 0 {product}
bool ClipInlining = true {product}
uintx CodeCacheExpansionSize = 32768 {pd product}
uintx CodeCacheFlushingMinimumFreeSpace = 1536000 {product}
uintx CodeCacheMinimumFreeSpace = 512000 {product}
bool CollectGen0First = false {product}
bool CompactFields = true {product}
intx CompilationPolicyChoice = 0 {product}
intx CompilationRepeat = 0 {C1 product}
ccstrlist CompileCommand = {product}
ccstr CompileCommandFile = {product}
ccstrlist CompileOnly = {product}
intx CompileThreshold = 1500 {pd product}
bool CompilerThreadHintNoPreempt = true {product}
intx CompilerThreadPriority = -1 {product}
intx CompilerThreadStackSize = 0 {pd product}
uintx ConcGCThreads = 0 {product}
bool ConvertSleepToYield = true {pd product}
bool ConvertYieldToSleep = false {product}
bool DTraceAllocProbes = false {product}
bool DTraceMethodProbes = false {product}
bool DTraceMonitorProbes = false {product}
uintx DefaultMaxRAMFraction = 4 {product}
intx DefaultThreadPriority = -1 {product}
intx DeferPollingPageLoopCount = -1 {product}
intx DeferThrSuspendLoopCount = 4000 {product}
bool DeoptimizeRandom = false {product}
bool DisableAttachMechanism = false {product}
bool DisableExplicitGC = false {product}
bool DisplayVMOutputToStderr = false {product}
bool DisplayVMOutputToStdout = false {product}
bool DontCompileHugeMethods = true {product}
bool DontYieldALot = false {pd product}
bool DumpSharedSpaces = false {product}
bool EagerXrunInit = false {product}
intx EmitSync = 0 {product}
uintx ErgoHeapSizeLimit = 0 {product}
ccstr ErrorFile = {product}
bool EstimateArgEscape = true {product}
intx EventLogLength = 2000 {product}
bool ExplicitGCInvokesConcurrent = false {product}
bool ExplicitGCInvokesConcurrentAndUnloadsClasses = false {produ
bool ExtendedDTraceProbes = false {product}
bool FLSAlwaysCoalesceLarge = false {product}
uintx FLSCoalescePolicy = 2 {product}
double FLSLargestBlockCoalesceP
最後更新：2017-04-02 06:51:56