JVM內存設置多大合適？Xmx和Xmn如何設置？
展開
本文地址：https://www.dutycode.com/jvm_xmx_xmn_xms_shezhi.html
除非注明，文章均為 www.dutycode.com 原創，歡迎轉載！轉載請注明本文地址,謝謝。
問題:
新上線一個java服務，或者是RPC或者是WEB站點， 內存的設置該怎么設置呢？設置成多大比較合適，既不浪費內存，又不影響性能呢？
分析：
依據的原則是根據Java Performance里面的推薦公式來進行設置。
具體來講：
Java整個堆大小設置，Xmx 和 Xms設置為老年代存活對象的3-4倍，即FullGC之后的老年代內存占用的3-4倍
永久代 PermSize和MaxPermSize設置為老年代存活對象的1.2-1.5倍。
年輕代Xmn的設置為老年代存活對象的1-1.5倍。
老年代的內存大小設置為老年代存活對象的2-3倍。
BTW：
1、Sun官方建議年輕代的大小為整個堆的3/8左右， 所以按照上述設置的方式，基本符合Sun的建議。
2、堆大小=年輕代大小+年老代大小， 即xmx=xmn+老年代大小 。 Permsize不影響堆大小。
3、為什么要按照上面的來進行設置呢？ 沒有具體的說明，但應該是根據多種調優之后得出的一個結論。
如何確認老年代存活對象大小？
方式1（推薦/比較穩妥）：
JVM參數中添加GC日志，GC日志中會記錄每次FullGC之后各代的內存大小，觀察老年代GC之后的空間大小。可觀察一段時間內（比如2天）的FullGC之后的內存情況，根據多次的FullGC之后的老年代的空間大小數據來預估FullGC之后老年代的存活對象大小（可根據多次FullGC之后的內存大小取平均值）
方式2：（強制觸發FullGC, 會影響線上服務，慎用）
方式1的方式比較可行，但需要更改JVM參數，並分析日志。同時，在使用CMS回收器的時候，有可能不能觸發FullGC（只發生CMS GC），所以日志中並沒有記錄FullGC的日志。在分析的時候就比較難處理。
BTW：使用jstat -gcutil工具來看FullGC的時候， CMS GC是會造成2次的FullGC次數增加。 具體可參見之前寫的一篇關於jstat使用的文章
所以，有時候需要強制觸發一次FullGC，來觀察FullGC之后的老年代存活對象大小。
注：強制觸發FullGC，會造成線上服務停頓（STW），要謹慎，建議的操作方式為，在強制FullGC前先把服務節點摘除，FullGC之后再將服務掛回可用節點，對外提供服務
在不同時間段觸發FullGC，根據多次FullGC之后的老年代內存情況來預估FullGC之后的老年代存活對象大小
如何觸發FullGC ？
使用jmap工具可觸發FullGC
jmap -dump:live,format=b,file=heap.bin <pid> 將當前的存活對象dump到文件，此時會觸發FullGC
jmap -histo:live <pid> 打印每個class的實例數目,內存占用,類全名信息.live子參數加上后,只統計活的對象數量. 此時會觸發FullGC
具體操作實例：
以我司的一個RPC服務為例。
BTW：剛上線的新服務，不知道該設置多大的內存的時候，可以先多設置一點內存，然后根據GC之后的情況來進行分析。
初始JVM內存參數設置為： Xmx=2G Xms=2G xmn=1G
使用jstat 查看當前的GC情況。如下圖：
YGC平均耗時： 173.825s/15799=11ms
FGC平均耗時：0.817s/41=19.9ms
平均大約10-20s會產生一次YGC
看起來似乎不錯，YGC觸發的頻率不高，FGC的耗時也不高，但這樣的內存設置是不是有些浪費呢？
為了快速看數據，我們使用了方式2，產生了幾次FullGC，FullGC之后，使用的jmap -heap 來看的當前的堆內存情況（也可以根據GC日志來看）
heap情況如下圖：（命令 ： jmap -heap <pid>）
上圖中的concurrent mark-sweep generation即為老年代的內存描述。
老年代的內存占用為100M左右。 按照整個堆大小是老年代（FullGC）之后的3-4倍計算的話，設置各代的內存情況如下：
Xmx=512m Xms=512m Xmn=128m PermSize=128m 老年代的大小為 （512-128=384m）為老年代存活對象大小的3倍左右
調整之后的，heap情況
GC情況如下：
YGC 差不多在10s左右觸發一次。每次YGC平均耗時大約9.41ms。可接受。
FGC平均耗時：0.016s/2=8ms
整體的GC耗時減少。但GC頻率比之前的2G時的要多了一些。
注： 看上述GC的時候，發現YGC的次數突然會增多很多個，比如 從1359次到了1364次。具體原因是？
總結：
在內存相對緊張的情況下，可以按照上述的方式來進行內存的調優， 找到一個在GC頻率和GC耗時上都可接受的一個內存設置，可以用較小的內存滿足當前的服務需要
但當內存相對寬裕的時候，可以相對給服務多增加一點內存，可以減少GC的頻率，GC的耗時相應會增加一些。 一般要求低延時的可以考慮多設置一點內存， 對延時要求不高的，可以按照上述方式設置較小內存。
補充：
永久代（方法區）並不在堆內，所以之前有看過一篇文章中描述的 整個堆大小=年輕代+年老代+永久代的描述是不正確的。
————————————————
版權聲明：本文為CSDN博主「losetowin」的原創文章，遵循CC 4.0 BY-SA版權協議，轉載請附上原文出處鏈接及本聲明。
原文鏈接：https://blog.csdn.net/losetowin/article/details/78569001