對於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下這個參數才有效。
原文鏈接：https://blog.csdn.net/cp_panda_5/article/details/79613870