关于jvm:谈JVM-xmx-xms等内存相关参数合理性设置

作者:京东批发 刘乐

说到JVM垃圾回收算法的两个优化标的：吞吐量和进展时长，并提到这两个优化指标是有抵触的。那么有没有可能进步吞吐量而不影响进展时长，甚至缩短进展时长呢？答案是有可能的，进步内存占用（Memory Footprint）就有可能同时优化这两个标的，这篇文章就来聊聊内存相干内容。

内存占用个别指利用运行须要的所有内存，包含堆内内存（On-heap Memory)和堆外内存（Off-heap Memory）

1. 堆内内存

堆内内存是调配给JVM的局部内存，用来寄存所有Java Class对象实例和数组，JVM GC操作的就是这部分内容。咱们先来回顾一下堆内内存的模型：

图1. 堆内内存

堆内内存包含年老代（浅绿色），老年代（浅蓝色），在JDK7或者更老的版本，图中左边还有个永恒代（永恒代在逻辑上位于JVM的堆区，但又被称为非堆内存，在JDK8中被元空间取代）。JVM有动静调整内存策略，通过-Xms，-Xmx 指定堆内内存动静调整的上上限。 在JVM初始化时理论只调配局部内存，可通过-XX:InitialHeapSize指定初始堆内存大小，未被调配的空间为图中virtual局部。年老代和老年代在每次GC的时候都有可能调整大小，以保障存活对象占用百分比在特定阈值范畴内，直到达到Xms指定的上限或Xms指定的下限。（阈值范畴通过-XX:MinHeapFreeRatio, XX:MaxHeapFreeRatio指定，默认值别离为40， 70）。

GC调优中还有个的重要参数是老年代和年老代的比例，通过-XX:NewRatio设定，与此相关的还有-XX:MaxNewSize和-XX:NewSize，别离设定年老代大小的上上限，-Xmn则间接指定年老代的大小。

1.1 参数默认值

◦-Xmx: Xmx的默认值比较复杂，官网文档上有时候写的是1GB，但理论值跟JRE版本、JVM 模式（client, server）和零碎（平台类型，32位，64位）等都无关。通过查阅源码和试验，确定在生产环境下（server模式，64位Centos，JRE 8），Xmx的默认值能够采纳以下规定计算：

▪容器内存小于等于2G：默认值为容器内存的1/2，最小16MB， 最大512MB。

▪容器内存大于2G：默认值为容器内存的1/4, 最大可达到32G。

◦-Xms: 默认值为容器内存的1/64, 最小8MB，如果明确指定了Xmx并且小于容器内存1/64, Xms默认值为Xmx指定的值。

◦-NewRatio: 默认2，即年老代和年轻代的比例为1:2， 年老代大小为堆内内存的1/3。

NOTE：在JRE版本1.8.0_131之前，JVM无奈感知Docker的资源限度，Xmx, Xms未明确指定时，会应用宿主机的内存计算默认值。

1.2 最佳实际

因为每次Eden区满就会触发YGC，而每次YGC的时候，降职到老年代的对象大小超过老年代残余空间的时候，就会触发FGC。所以根本来说，GC频率和堆内内存大小是成反比的，也就是说堆内内存越大，吞吐量越大。

如果Xmx设置过小，不仅节约了容器资源，在大流量下会频繁GC，导致一系列问题，包含吞吐量升高，响应变长，CPU升高，java.lang.OutOfMemoryError异样等。当然Xmx也不倡议设置过大，否则会导致过程hang住或者应用容器Swap。所以正当设置Xmx十分重要，特地是对于1.8.0_131之前的版本，肯定要明确指定Xmx。举荐设置为容器内存的50%，不能超过容器内存的80%。

JVM的动态内存策略不太适宜服务应用，因为每次GC须要计算Heap是否须要伸缩，内存抖动须要向零碎申请或开释内存，特地是在服务重启的预热阶段，内存抖动会比拟频繁。另外，容器中如果有其余过程还在生产内存，JVM内存抖动时可能申请内存失败，导致OOM。因而倡议服务模式下，将Xms设置Xmx一样的值。

NewRatio倡议在2~3之间，最优抉择取决于对象的生命周期散布。个别先确定老年代的空间（足够放下所有live data，并适当减少10%~20%)，其余是年老代，年老代大小肯定要小于老年代。

另外，以上倡议都是基于一个容器部署一个JVM实例的应用状况。有个别需要，须要在一个容器内启用多个JVM，或者蕴含其余语言的，研发须要按业务需要在推荐值范畴内调配JVM的Xmx。

2. 堆外内存

和堆内内存对应的就是堆外内存。堆外内存包含很多局部，比方Code Cache， Memory Pool，Stack Memory，Direct Byte Buffers, Metaspace等等，其中咱们须要重点关注的是Direct Byte Buffers和Metaspace。

2.1 Direct Byte Buffers

Direct Byte Buffers是零碎原生内存，不位于JVM里，广义上的堆外内存就是指的Direct Byte Buffers。为什么要应用零碎原生内存呢? 为了更高效的进行Socket I/O或文件读写等内核态资源操作，会应用JNI（Java原生接口），此时操作的内存须要是间断和确定的。而Heap中的内存不能保障间断，且GC也可能导致对象随时挪动。因而波及Output操作时，不间接应用Heap上的数据，须要先从Heap上拷贝到原生内存，Input操作则相同。因而为了防止多余的拷贝，进步I/O效率，不少第三方包和框架应用Direct Byte Buffers，比Netty。

Direct Byte Buffers尽管有上述长处，但应用起来也有肯定危险。常见的Direct Byte Buffers应用办法是用java.nio.DirectByteBuffer的unsafe.allocateMemory办法来创立，DirectByteBuffer对象只保留了零碎调配的原生内存的大小和启始地位，这些原生内存的开释须要等到DirectByteBuffer对象被回收。有些非凡的状况下（比方JVM始终没有FGC，设置-XX:+DisableExplicitGC禁用了System.gc），这部分对象会继续减少，直到堆外内存达到-XX:MaxDirectMemorySize 指定的大小或者耗尽所有的零碎内存。

MaxDirectMemorySize不明确指定的时候，默认值为0，在代码中理论为Runtime.getRuntime().maxMemory()，略小于-Xmx指定的值（堆内内存的最大值减去一个Survivor区大小）。此默认值有点过大，MaxDirectMemorySize未设置或设置过大，有可能产生堆外内存泄露，导致过程被零碎Kill。

因为存在肯定危险，倡议在启动参数里明确指定-XX:MaxDirectMemorySize的值，并满足上面规定：

◦Xmx * 110% + MaxDirectMemorySize + 零碎预留内存 <= 容器内存

◦Xmx 110% 中额定的10%是留给其余堆外内存的，是个激进预计，个别业务运行时线程较多，需自行判断，上式中左侧还需加上Xss 线程数

◦零碎预留内存512M到1G，视容器规格而定

◦I/O较多的业务适当进步MaxDirectMemorySize比例

2.2 Metaspace

Metaspace（元空间）是JDK8对于办法区新的实现，取代之前的永恒代，用来保留类、办法、数据结构等运行时信息和元信息的。很多研发在老版本时可能遇到过java.lang.OutOfMemoryError: PermGen Space，这阐明永恒代的空间不够用了，能够通过-XX:PermSize，-XX:MaxPermSize来指定永恒代的初始大小和最大大小。Metaspace取代永恒代，地位由JVM内存变成零碎原生内存，也勾销默认的最大空间限度。与此有关的参数次要有上面两个：

◦-XX:MaxMetaspaceSize 指定元空间的最大空间，默认为容器残余的所有空间

◦-XX:MetaspaceSize 指定元空间首次裁减的大小，默认为20.8M

因为MaxMetaspaceSize未指定时，默认无下限，所以须要特地关注内存泄露的问题，如果程序动静的创立了很多类，或呈现过java.lang.OutOfMemoryError:Metaspace，倡议明确指定-XX:MaxMetaspaceSize。另外Metaspace理论调配的大小是随着须要逐渐扩充的，每次扩充须要一次FGC，-XX:MetaspaceSize默认的值比拟小，须要频繁GC裁减到须要的大小。通过上面的日志能够看到Metaspace引起的FGC：

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

为缩小预热影响，能够将-XX:MetaspaceSize，-XX:MaxMetaspaceSize指定成雷同的值。另外不少利用由JDK7降级到了JDK8，然而启动参数中仍有-XX:PermSize，-XX:MaxPermSize，这些参数是不失效的，倡议批改成-XX:MetaspaceSize，-XX:MaxMetaspaceSize。

3. 利用衰弱度查看规定

泰山利用衰弱度当初已反对扫描JVM相干危险，在利用TAB的JVM配置检测项下。次要包含以下检测：

上一篇文章曾经说了ParallelGCThreads，这里再补充一下新反对的两个检测，ConcGCThreads，CICompilerCount。

ConcGCThreads个别称为并发标记线程数，为了缩小GC的STW的工夫，CMS和G1都有并发标记的过程，此时业务线程仍在工作，只是并发标记是CPU密集型工作，业务的吞吐量会降落，RT会变长。ConcGCThreads的默认值不同GC策略略有不同，CMS下是(ParallelGCThreads + 3) / 4 向下取整，G1下是ParallelGCThreads / 4 四舍五入。一般来说采纳默认值就能够了，然而还是因为在JRE版本1.8.0_131之前，JVM无奈感知Docker的资源限度的问题，ConcGCThreads的默认值会比拟大（20左右），对业务会有影响。

CICompilerCount是JIT进行热点编译的线程数，和并发标记线程数一样，热点编译也是CPU密集型工作，默认值为2。在CICompilerCountPerCPU开启的时候（JDK7默认敞开，JDK8默认开启），手动指定CICompilerCount是不会失效的，JVM会应用零碎CPU核数进行计算。所以当应用JRE8并且版本小于1.8.0_131，采纳默认参数时，CICompilerCount会在20左右，对业务性能影响较大，特地是启动阶段。倡议降级Java版本，非凡状况要应用老版本Java 8，请加上-XX:CICompilerCount=[n], 同时不能指定-XX:+CICompilerCountPerCPU ，下表给出了生产环境下常见规格的推荐值。

4. 批改倡议

1） 再次倡议降级JRE版本到1.8.0_191及以上； 2） 倡议在Shell脚本中，Export JAVA_OPTS环境变量, 至多蕴含以下几项(方括号中的值依据文中举荐选取)：

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

如果非凡起因要应用1.8.0_131以下版本， 则同时须要加上以下参数(方括号中的值依据文中举荐选取)：

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

上面的项倡议测试后应用，需自行确定具体大小（特地是应用JRE8但仍配置-XX:PermSize，-XX:MaxPermSize的利用）：

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

环境变量设置如下例子：

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...]"

另外，如果利用未接入UMP或PFinder， JAVA_OPTS中尽量不要用Shell函数或者变量，否则衰弱度有可能会提醒解析失败。

NOTE: Java options 的应用应该依照上面的程序：

◦执行类： java [-options] class [args...]

◦执行包：java [-options] -jar jarfile [args...] 或 java -jar [-options] jarfile [args...]

即options要放到执行对象之前，局部利用应用了以下程序：

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

这些Java options都不会失效。