作者：京东批发 刘乐
文章说到JVM渣滓回收 算法 的两个优化标的：吞吐量和停顿时长，并提到这两个优化目的是有抵触的。那么有没有或许提高吞吐量而不影响停顿时长，甚至缩短停顿时长呢？答案是有或许的，提高内存占用（Memy Footprint）就有或许同时优化这两个标的，这篇文章就来聊聊内存相关内容。
内存占用普通指运行运转须要的一切内存，包括堆内内存（On-heap Memory)和堆外内存（Off-heap Memory）
1. 堆内内存
堆内内存是调配给JVM的部分外存，用来寄存一切Class对象实例和数组，JVM GC操作的就是这部分外容。咱们先来回忆一下堆内内存的模型：
堆内内存包括年轻代（浅绿色），老年代（浅蓝色），在JDK7或许更老的版本，图中左边还有个终身代（终身代在逻辑上位于JVM的堆区，但又被称为非堆内存，在JDK8中被元空间取代）。JVM有灵活调整内存战略，经过-Xms，-Xmx 指定堆内内存灵活调整的高低限。 在JVM初始化时实践只调配部分外存，可经过-XX:InialHeapSize指定初始堆内存大小，未被调配的空间为图中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。
NO：在JRE版本1.8.0_131之前，JVM不可感知Docker的资源限度，Xmx, Xms未明白指定时，会经常使用宿主机的内存计算自动值。
1.2 最佳通常
由于每次Eden区满就会触发YGC，而每次YGC的时刻，升职到老年代的对象大小超越老年代残余空间的时刻，就会触发FGC。所以基原本说，GC频率和堆内内存大小是成正比的，也就是说堆内内存越大，吞吐量越大。
假设Xmx设置过小，不只糜费了容器资源，在大流量下会频繁GC，造成一系列疑问，包括吞吐量降低，照应变长，升高，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 target="_blank">he， Memory Pool，Stack Memory，Direct Byte Buffe, 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:+DisableExplitGC禁用了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，这说明终身代的空间不够用了，JDK7以前可以经过-XX:Peize，-XX:MaxPermSize来指定终身代的初始大小和最大大小。JDK8中Metaspace取代终身代，位置由JVM内存变成系统原生内存，也敞开自动的最大空间限度。与此无关的参数关键有上方两个：
◦-XX:MaxMetaspaceSize 指定元空间的最大空间，默以为容器残余的一切空间
◦-XX:MetaspaceSize 指定元空间初次扩大的大小，默以为20.8M
由于MaxMetaspaceSize未指定时，自动无下限，所以须要特意关注内存暴露的疑问，假设程序灵活的创立了很多类，或出现过java.lang.OutOfMemoryError:Metaspace，倡导明白指定-XX:MaxMetaspaceSize。另外Metaspace实践调配的大小是随着须要逐渐扩展的，每次扩展须要一次性FGC，-XX:MetaspaceSize自动的值比拟小，须要频繁GC扩大到须要的大小。经过上方的日志可以看到Metaspace惹起的FGC：
[Full GC (Metata GC Threshold) ...]
为缩小预热影响，可以将-XX:MetaspaceSize，-XX:MaxMetaspaceSize指定成相反的值。另外不少运行由JDK7更新到了JDK8，然而启动参数中仍有-XX:PermSize，-XX:MaxPermSize， 这些参数是不失效的 ，倡导修正成-XX:MetaspaceSize，-XX:MaxMetaspaceSize。
3. 运行肥壮度审核规定
泰山运行肥壮度如今已允许扫描JVM相关危险，在运行TAB的JVM性能 检测 项下。关键包括以下检测：
| 检测目的 | 危险等级 | 巡检规定 |
|---|---|---|
| JVM版本 | 中危 | 版本不低于1.8.0_191 |
| JVM GC方法 | 中危 | 一切分组GC方法分歧 |
| 高危 | 明白指定，并且在容器内存的50%~80%范畴内 | |
| 中危 | 明白指定，并且等于Xmx指定的值 | |
| 堆外内存 | 中危 | 明白指定，并且 堆内*1.1+堆外+系统预留<=容器内存 |
| ParallelGCThreads | 高危 | ParallelGCThreads在容器CPU核数的50%~100%范畴内 |
| ConcGCThreads | 低危 | ConcGCThreads在ParallelGCThreads的20%~50%范畴内（限CMS，G1） |
| CIComlerCount | 低危 | 指定CICompilerCount在介绍值50%~150%内（限1.8 |
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 ，下表给出了消费环境下经常出现规格的介绍值。
| 容器CPU核数 |
|---|
| CICompilerCount手动指定介绍值 |
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=[256]m -XX:MetaspaceSize=[256]m
环境变量设置如下例子：
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 jaile [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都不会失效。
修正补充说明：
上方的JVM参数性能曾经集成到行云部署了，内行云部署-分组-性能治理-JVM参数性能，点填充就可以性能自动的JVM参数，如有须要也可以对特定的参数启动修正， 留意worker类型运行须要在启动脚本(start.sh)中参与如下行：
source /home/admin/default_vm.sh
审核编辑 黄宇