談JVM xmx, xms等內(nèi)存相關(guān)參數(shù)合理性設(shè)置

作者：京東零售 劉樂(lè)

上一篇文章說(shuō)到JVM垃圾回收算法的兩個(gè)優(yōu)化標(biāo)的：吞吐量和停頓時(shí)長(zhǎng)，并提到這兩個(gè)優(yōu)化目標(biāo)是有沖突的。那么有沒(méi)有可能提高吞吐量而不影響停頓時(shí)長(zhǎng)，甚至縮短停頓時(shí)長(zhǎng)呢？答案是有可能的，提高內(nèi)存占用（Memory Footprint）就有可能同時(shí)優(yōu)化這兩個(gè)標(biāo)的，這篇文章就來(lái)聊聊內(nèi)存相關(guān)內(nèi)容。

內(nèi)存占用一般指應(yīng)用運(yùn)行需要的所有內(nèi)存，包括堆內(nèi)內(nèi)存（On-heap Memory)和堆外內(nèi)存（Off-heap Memory）

1. 堆內(nèi)內(nèi)存

堆內(nèi)內(nèi)存是分配給JVM的部分內(nèi)存，用來(lái)存放所有Java Class對(duì)象實(shí)例和數(shù)組，JVM GC操作的就是這部分內(nèi)容。我們先來(lái)回顧一下堆內(nèi)內(nèi)存的模型：

堆內(nèi)內(nèi)存包括年輕代（淺綠色），老年代（淺藍(lán)色），在JDK7或者更老的版本，圖中右邊還有個(gè)永久代（永久代在邏輯上位于JVM的堆區(qū)，但又被稱為非堆內(nèi)存，在JDK8中被元空間取代）。JVM有動(dòng)態(tài)調(diào)整內(nèi)存策略，通過(guò)-Xms，-Xmx 指定堆內(nèi)內(nèi)存動(dòng)態(tài)調(diào)整的上下限。 在JVM初始化時(shí)實(shí)際只分配部分內(nèi)存，可通過(guò)-XX:InitialHeapSize指定初始堆內(nèi)存大小，未被分配的空間為圖中virtual部分。年輕代和老年代在每次GC的時(shí)候都有可能調(diào)整大小，以保證存活對(duì)象占用百分比在特定閾值范圍內(nèi)，直到達(dá)到Xms指定的下限或Xms指定的上限。（閾值范圍通過(guò)-XX:MinHeapFreeRatio, XX:MaxHeapFreeRatio指定，默認(rèn)值分別為40， 70）。

GC調(diào)優(yōu)中還有個(gè)的重要參數(shù)是老年代和年輕代的比例，通過(guò)-XX:NewRatio設(shè)定，與此相關(guān)的還有-XX:MaxNewSize和-XX:NewSize，分別設(shè)定年輕代大小的上下限，-Xmn則直接指定年輕代的大小。

1.1 參數(shù)默認(rèn)值

?-Xmx: Xmx的默認(rèn)值比較復(fù)雜，官方文檔上有時(shí)候?qū)懙氖?GB，但實(shí)際值跟JRE版本、JVM 模式（client, server）和系統(tǒng)（平臺(tái)類型，32位，64位）等都有關(guān)。經(jīng)過(guò)查閱源碼和實(shí)驗(yàn)，確定在生產(chǎn)環(huán)境下（server模式，64位Centos，JRE 8），Xmx的默認(rèn)值可以采用以下規(guī)則計(jì)算：

?容器內(nèi)存小于等于2G：默認(rèn)值為容器內(nèi)存的1/2，最小16MB， 最大512MB。

?容器內(nèi)存大于2G：默認(rèn)值為容器內(nèi)存的1/4, 最大可到達(dá)32G。

?-Xms: 默認(rèn)值為容器內(nèi)存的1/64, 最小8MB，如果明確指定了Xmx并且小于容器內(nèi)存1/64, Xms默認(rèn)值為Xmx指定的值。

?-NewRatio: 默認(rèn)2，即年輕代和年老代的比例為1:2， 年輕代大小為堆內(nèi)內(nèi)存的1/3。

NOTE：在JRE版本1.8.0_131之前，JVM無(wú)法感知Docker的資源限制，Xmx, Xms未明確指定時(shí)，會(huì)使用宿主機(jī)的內(nèi)存計(jì)算默認(rèn)值。

1.2 最佳實(shí)踐

由于每次Eden區(qū)滿就會(huì)觸發(fā)YGC，而每次YGC的時(shí)候，晉升到老年代的對(duì)象大小超過(guò)老年代剩余空間的時(shí)候，就會(huì)觸發(fā)FGC。所以基本來(lái)說(shuō)，GC頻率和堆內(nèi)內(nèi)存大小是成反比的，也就是說(shuō)堆內(nèi)內(nèi)存越大，吞吐量越大。

如果Xmx設(shè)置過(guò)小，不僅浪費(fèi)了容器資源，在大流量下會(huì)頻繁GC，導(dǎo)致一系列問(wèn)題，包括吞吐量降低，響應(yīng)變長(zhǎng)，CPU升高，java.lang.OutOfMemoryError異常等。當(dāng)然Xmx也不建議設(shè)置過(guò)大，否則會(huì)導(dǎo)致進(jìn)程hang住或者使用容器Swap。所以合理設(shè)置Xmx非常重要，特別是對(duì)于1.8.0_131之前的版本，一定要明確指定Xmx。推薦設(shè)置為容器內(nèi)存的50%，不能超過(guò)容器內(nèi)存的80%。

JVM的動(dòng)態(tài)內(nèi)存策略不太適合服務(wù)使用，因?yàn)槊看蜧C需要計(jì)算Heap是否需要伸縮，內(nèi)存抖動(dòng)需要向系統(tǒng)申請(qǐng)或釋放內(nèi)存，特別是在服務(wù)重啟的預(yù)熱階段，內(nèi)存抖動(dòng)會(huì)比較頻繁。另外，容器中如果有其他進(jìn)程還在消費(fèi)內(nèi)存，JVM內(nèi)存抖動(dòng)時(shí)可能申請(qǐng)內(nèi)存失敗，導(dǎo)致OOM。因此建議服務(wù)模式下，將Xms設(shè)置Xmx一樣的值。

NewRatio建議在2~3之間，最優(yōu)選擇取決于對(duì)象的生命周期分布。一般先確定老年代的空間（足夠放下所有l(wèi)ive data，并適當(dāng)增加10%~20%)，其余是年輕代，年輕代大小一定要小于老年代。

另外，以上建議都是基于一個(gè)容器部署一個(gè)JVM實(shí)例的使用情況。有個(gè)別需求，需要在一個(gè)容器內(nèi)啟用多個(gè)JVM，或者包含其他語(yǔ)言的，研發(fā)需要按業(yè)務(wù)需求在推薦值范圍內(nèi)分配JVM的Xmx。

2. 堆外內(nèi)存

和堆內(nèi)內(nèi)存對(duì)應(yīng)的就是堆外內(nèi)存。堆外內(nèi)存包括很多部分，比如Code Cache， Memory Pool，Stack Memory，Direct Byte Buffers, Metaspace等等，其中我們需要重點(diǎn)關(guān)注的是Direct Byte Buffers和Metaspace。

2.1 Direct Byte Buffers

Direct Byte Buffers是系統(tǒng)原生內(nèi)存，不位于JVM里，狹義上的堆外內(nèi)存就是指的Direct Byte Buffers。為什么要使用系統(tǒng)原生內(nèi)存呢? 為了更高效的進(jìn)行Socket I/O或文件讀寫(xiě)等內(nèi)核態(tài)資源操作，會(huì)使用JNI（Java原生接口），此時(shí)操作的內(nèi)存需要是連續(xù)和確定的。而Heap中的內(nèi)存不能保證連續(xù)，且GC也可能導(dǎo)致對(duì)象隨時(shí)移動(dòng)。因此涉及Output操作時(shí)，不直接使用Heap上的數(shù)據(jù)，需要先從Heap上拷貝到原生內(nèi)存，Input操作則相反。因此為了避免多余的拷貝，提高I/O效率，不少第三方包和框架使用Direct Byte Buffers，比Netty。

Direct Byte Buffers雖然有上述優(yōu)點(diǎn)，但使用起來(lái)也有一定風(fēng)險(xiǎn)。常見(jiàn)的Direct Byte Buffers使用方法是用java.nio.DirectByteBuffer的unsafe.allocateMemory方法來(lái)創(chuàng)建，DirectByteBuffer對(duì)象只保存了系統(tǒng)分配的原生內(nèi)存的大小和啟始位置，這些原生內(nèi)存的釋放需要等到DirectByteBuffer對(duì)象被回收。有些特殊的情況下（比如JVM一直沒(méi)有FGC，設(shè)置-XX:+DisableExplicitGC禁用了System.gc），這部分對(duì)象會(huì)持續(xù)增加，直到堆外內(nèi)存達(dá)到-XX:MaxDirectMemorySize 指定的大小或者耗盡所有的系統(tǒng)內(nèi)存。

MaxDirectMemorySize不明確指定的時(shí)候，默認(rèn)值為0，在代碼中實(shí)際為Runtime.getRuntime().maxMemory()，略小于-Xmx指定的值（堆內(nèi)內(nèi)存的最大值減去一個(gè)Survivor區(qū)大小）。此默認(rèn)值有點(diǎn)過(guò)大，MaxDirectMemorySize未設(shè)置或設(shè)置過(guò)大，有可能發(fā)生堆外內(nèi)存泄露，導(dǎo)致進(jìn)程被系統(tǒng)Kill。

由于存在一定風(fēng)險(xiǎn)，建議在啟動(dòng)參數(shù)里明確指定-XX:MaxDirectMemorySize的值，并滿足下面規(guī)則：

?Xmx * 110% + MaxDirectMemorySize + 系統(tǒng)預(yù)留內(nèi)存 <= 容器內(nèi)存

?Xmx * 110% 中額外的10%是留給其他堆外內(nèi)存的，是個(gè)保守估計(jì)，個(gè)別業(yè)務(wù)運(yùn)行時(shí)線程較多，需自行判斷，上式中左側(cè)還需加上Xss * 線程數(shù)

?系統(tǒng)預(yù)留內(nèi)存512M到1G，視容器規(guī)格而定

?I/O較多的業(yè)務(wù)適當(dāng)提高M(jìn)axDirectMemorySize比例

2.2 Metaspace

Metaspace（元空間）是JDK8關(guān)于方法區(qū)新的實(shí)現(xiàn)，取代之前的永久代，用來(lái)保存類、方法、數(shù)據(jù)結(jié)構(gòu)等運(yùn)行時(shí)信息和元信息的。很多研發(fā)在老版本時(shí)可能遇到過(guò)java.lang.OutOfMemoryError: PermGen Space，這說(shuō)明永久代的空間不夠用了，JDK7以前可以通過(guò)-XX:PermSize，-XX:MaxPermSize來(lái)指定永久代的初始大小和最大大小。JDK8中Metaspace取代永久代，位置由JVM內(nèi)存變成系統(tǒng)原生內(nèi)存，也取消默認(rèn)的最大空間限制。與此有關(guān)的參數(shù)主要有下面兩個(gè)：

?-XX:MaxMetaspaceSize 指定元空間的最大空間，默認(rèn)為容器剩余的所有空間

?-XX:MetaspaceSize 指定元空間首次擴(kuò)充的大小，默認(rèn)為20.8M

由于MaxMetaspaceSize未指定時(shí)，默認(rèn)無(wú)上限，所以需要特別關(guān)注內(nèi)存泄露的問(wèn)題，如果程序動(dòng)態(tài)的創(chuàng)建了很多類，或出現(xiàn)過(guò)java.lang.OutOfMemoryError:Metaspace，建議明確指定-XX:MaxMetaspaceSize。另外Metaspace實(shí)際分配的大小是隨著需要逐步擴(kuò)大的，每次擴(kuò)大需要一次FGC，-XX:MetaspaceSize默認(rèn)的值比較小，需要頻繁GC擴(kuò)充到需要的大小。通過(guò)下面的日志可以看到Metaspace引起的FGC：

[Full GC (Metadata GC Threshold) ...]

為減少預(yù)熱影響，可以將-XX:MetaspaceSize，-XX:MaxMetaspaceSize指定成相同的值。另外不少應(yīng)用由JDK7升級(jí)到了JDK8，但是啟動(dòng)參數(shù)中仍有-XX:PermSize，-XX:MaxPermSize，這些參數(shù)是不生效的，建議修改成-XX:MetaspaceSize，-XX:MaxMetaspaceSize。

3. 應(yīng)用健康度檢查規(guī)則

?泰山應(yīng)用健康度現(xiàn)在已支持掃描JVM相關(guān)風(fēng)險(xiǎn)，在應(yīng)用TAB的JVM配置檢測(cè)項(xiàng)下。主要包括以下檢測(cè)：

?上一篇文章已經(jīng)說(shuō)了ParallelGCThreads，這里再補(bǔ)充一下新支持的兩個(gè)檢測(cè)，ConcGCThreads，CICompilerCount。

ConcGCThreads一般稱為并發(fā)標(biāo)記線程數(shù)，為了減少GC的STW的時(shí)間，CMS和G1都有并發(fā)標(biāo)記的過(guò)程，此時(shí)業(yè)務(wù)線程仍在工作，只是并發(fā)標(biāo)記是CPU密集型任務(wù)，業(yè)務(wù)的吞吐量會(huì)下降，RT會(huì)變長(zhǎng)。ConcGCThreads的默認(rèn)值不同GC策略略有不同，CMS下是(ParallelGCThreads + 3) / 4 向下取整，G1下是ParallelGCThreads / 4 四舍五入。一般來(lái)說(shuō)采用默認(rèn)值就可以了，但是還是由于在JRE版本1.8.0_131之前，JVM無(wú)法感知Docker的資源限制的問(wèn)題，ConcGCThreads的默認(rèn)值會(huì)比較大（20左右），對(duì)業(yè)務(wù)會(huì)有影響。

CICompilerCount是JIT進(jìn)行熱點(diǎn)編譯的線程數(shù)，和并發(fā)標(biāo)記線程數(shù)一樣，熱點(diǎn)編譯也是CPU密集型任務(wù)，默認(rèn)值為2。在CICompilerCountPerCPU開(kāi)啟的時(shí)候（JDK7默認(rèn)關(guān)閉，JDK8默認(rèn)開(kāi)啟），手動(dòng)指定CICompilerCount是不會(huì)生效的，JVM會(huì)使用系統(tǒng)CPU核數(shù)進(jìn)行計(jì)算。所以當(dāng)使用JRE8并且版本小于1.8.0_131，采用默認(rèn)參數(shù)時(shí)，CICompilerCount會(huì)在20左右，對(duì)業(yè)務(wù)性能影響較大，特別是啟動(dòng)階段。建議升級(jí)Java版本，特殊情況要使用老版本Java 8，請(qǐng)加上-XX:CICompilerCount=[n], 同時(shí)不能指定-XX:+CICompilerCountPerCPU ，下表給出了生產(chǎn)環(huán)境下常見(jiàn)規(guī)格的推薦值。

4. 修改建議

1） 再次建議升級(jí)JRE版本到1.8.0_191及以上； 2） 建議在Shell腳本中，Export JAVA_OPTS環(huán)境變量, 至少包含以下幾項(xiàng)(方括號(hào)中的值根據(jù)文中推薦選取)：

-server -Xms[8192m] -Xmx[8192m] -XX:MaxDirectMemorySize=[4096m]

如果特殊原因要使用1.8.0_131以下版本， 則同時(shí)需要加上以下參數(shù)(方括號(hào)中的值根據(jù)文中推薦選取)：

-XX:ParallelGCThreads=[8] -XX:ConcGCThreads=[2] -XX:CICompilerCount=[2]

下面的項(xiàng)建議測(cè)試后使用，需自行確定具體大小（特別是使用JRE8但仍配置-XX:PermSize，-XX:MaxPermSize的應(yīng)用）：

-XX:MaxMetaspaceSize=[256]m -XX:MetaspaceSize=[256]m

環(huán)境變量設(shè)置如下例子：

export JAVA_OPTS="-Djava.library.path=/usr/local/lib -server -Xms4096m -Xmx4096m -XX:MaxMetaspaceSize=512m -XX:MetaspaceSize=512m -XX:MaxDirectMemorySize=2048m -XX:ParallelGCThreads=8 -XX:ConcGCThreads=2 -XX:CICompilerCount=2 -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/export/Logs -XX:+UseG1GC [other_options...] -jar jarfile [args...]"

另外，如果應(yīng)用未接入U(xiǎn)MP或PFinder， JAVA_OPTS中盡量不要用Shell函數(shù)或者變量，否則健康度有可能會(huì)提示解析失敗。

NOTE: Java options 的使用應(yīng)該按照下面的順序：

?執(zhí)行類： java [-options] class [args...]

?執(zhí)行包：java [-options] -jar jarfile [args...] 或 java -jar [-options] jarfile [args...]

即options要放到執(zhí)行對(duì)象之前，部分應(yīng)用使用了以下順序：

java -jar jarfile [-options] [args...] 或者 java -jar jarfile [args...] [-options]

這些Java options都不會(huì)生效。

修改補(bǔ)充說(shuō)明：

上面的JVM參數(shù)配置已經(jīng)集成到行云部署了，在行云部署-分組-配置管理-JVM參數(shù)配置，點(diǎn)填充就可以配置默認(rèn)的JVM參數(shù)，如有需要也可以對(duì)特定的參數(shù)進(jìn)行修改，注意worker類型應(yīng)用需要在啟動(dòng)腳本(start.sh)中增加如下行：

source /home/admin/default_vm.sh

審核編輯 黃宇