作者：京东零售 刘乐
吞吐量和中止时长，这两个优化目标是有抵触的。那么有没有或许进步吞吐量而不影响中止时长，乃至缩短中止时长呢？答案是有或许的，进步内存占用（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装备检测项下。首要包含以下检测：
| 检测指标
|
危险等级
|
巡检规矩
| |
JVM版别
|
中危
|
版别不低于1.8.0_191
| |
JVM GC办法
|
中危
|
一切分组GC办法一致
| |
Xmx
|
高危
|
清晰指定，并且在容器内存的50%~80%规模内
| |
Xms
|
中危
|
清晰指定，并且等于Xmx指定的值
| |
堆外内存
|
中危
|
清晰指定，并且 堆内*1.1+堆外+体系预留<=容器内存
| |
ParallelGCThreads
|
高危
|
ParallelGCThreads在容器CPU核数的50%~100%规模内
| |
ConcGCThreads
|
低危
|
ConcGCThreads在ParallelGCThreads的20%~50%规模内（限CMS，G1）
| |
CICompilerCount
|
低危
|
指定CICompilerCount在引荐值50%~150%内（限1.8<JRE<1.8.0_131)
|
上一篇文章已经说了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，下表给出了出产环境下常见标准的引荐值。
| 容器CPU核数
|
1
|
2
|
4
|
8
|
16
| |
CICompilerCount手动指定引荐值
|
2
|
2
|
3
|
3
|
8
|
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都不会收效。
