摘要
大家在面试时候经常被问到的JVM调优相关问题，但是对于大部分初级程序员来说很难遇到JVM级别的调优。因此本文总结一下在生产换种涉及到JVM的优化的问题和优化的解决方案。
一、JVM调优的背景 1.1 生产环境中的问题- 生产环境发生了内存溢出该如何处理？
- 生产环境应该给服务器分配多少内存合适？
- 如何对垃圾回收器的性能进行调优？
- 生产环境 CPU 负载飙高该如何处理？
- 生产环境应该给应用分配多少线程合适？
- 不加 log，如何确定请求是否执行了某一行代码？
- 不加 log，如何实时查看某个方法的入参与返回值？
- 防止出现 OOM
- 解决 OOM
- 减少 Full GC 出现的频率
- 上线前
- 项目运行阶段
- 线上出现 OOM
- 运行日志
- 异常堆栈
- GC 日志
- 线程快照
- 堆转储快照
- 合理地编写代码
- 充分并合理的使用硬件资源
- 合理地进行 JVM 调优
- GC 频繁
- cpu load 过高
- OOM
- 内存泄露
- 死锁
- 程序响应时间较长
- 打印 GC 日志，通过 GCviewer
- Universal JVM GC analyzer - Java Garbage collection log analysis made easy
- 灵活运用命令行工具、jstack、jmap、jinfo 等
- dump 出堆文件，使用内存分析工具分析文件
- 使用阿里 Arthas、jconsole、JVisualVM 来实时查看 JVM 状态
- jstack 查看堆栈信息
- 适当增加内存，根据业务背景选择垃圾回收器
- 优化代码，控制内存使用
- 增加机器，分散节点压力
- 合理设置线程池线程数量
- 使用中间件提高程序效率，比如缓存、消息队列等
- 其他……
停顿时间（或响应时间）：提交请求和返回该请求的响应之间使用的时间，一般比较关注平均响应时间。常用操作的响应时间列表：
操作响应时间打开一个站点几秒数据库查询一条记录（有索引）十几毫秒机械磁盘一次寻址定位4 毫秒从机械磁盘顺序读取 1M 数据2 毫秒从 SSD 磁盘顺序读取 1M 数据0.3 毫秒从远程分布式换成 Redis 读取一个数据0.5 毫秒从内存读取 1M 数据十几微妙Java 程序本地方法调用几微妙网络传输 2Kb 数据1 微妙 4.1 在垃圾回收环节中：- 暂停时间：执行垃圾收集时，程序的工作线程被暂停的时间。
- -XX:MaxGCPauseMillis
- 对单位时间内完成的工作量（请求）的量度
- 在 GC 中：运行用户代码的事件占总运行时间的比例（总运行时间：程序的运行时间+内存回收的时间）
- 吞吐量为 1-1/(1+n)，其中-XX::GCTimeRatio=n
- 同一时刻，对服务器有实际交互的请求数
- Java 堆区所占的内存大小
以高速公路通行状况为例
- 吞吐量：每天通过高速公路收费站的车辆的数据
- 并发数：高速公路上正在行驶的车辆的数目
- 响应时间：车速
JVM——调参与监控命令工具_庄小焱-CSDN博客
六、JVM调优内部参数方案 6.1 JVM运行时参数> java -X
-Xmixed 混合模式执行 (默认)
-Xint 仅解释模式执行
-Xbootclasspath:
设置搜索路径以引导类和资源
-Xbootclasspath/a:
附加在引导类路径末尾
-Xbootclasspath/p:
置于引导类路径之前
-Xdiag 显示附加诊断消息
-Xnoclassgc 禁用类垃圾收集
-Xincgc 启用增量垃圾收集
-Xloggc: 将 GC 状态记录在文件中 (带时间戳)
-Xbatch 禁用后台编译
-Xms 设置初始 Java 堆大小
-Xmx 设置最大 Java 堆大小
-Xss 设置 Java 线程堆栈大小
-Xprof 输出 cpu 配置文件数据
-Xfuture 启用最严格的检查, 预期将来的默认值
-Xrs 减少 Java/VM 对操作系统信号的使用 (请参阅文档)
-Xcheck:jni 对 JNI 函数执行其他检查
-Xshare:off 不尝试使用共享类数据
-Xshare:auto 在可能的情况下使用共享类数据 (默认)
-Xshare:on 要求使用共享类数据, 否则将失败。
-XshowSettings 显示所有设置并继续
-XshowSettings:all
显示所有设置并继续
-XshowSettings:vm 显示所有与 vm 相关的设置并继续
-XshowSettings:properties
显示所有属性设置并继续
-XshowSettings:locale
显示所有与区域设置相关的设置并继续
-X 选项是非标准选项, 如有更改, 恕不另行通知。
-X 参数选项
java -X
-Xmixed 混合模式执行 (默认)
-Xint 仅解释模式执行
-Xbootclasspath:
设置搜索路径以引导类和资源
-Xbootclasspath/a:
附加在引导类路径末尾
-Xbootclasspath/p:
置于引导类路径之前
-Xdiag 显示附加诊断消息
-Xnoclassgc 禁用类垃圾收集
-Xincgc 启用增量垃圾收集
-Xloggc: 将 GC 状态记录在文件中 (带时间戳)
-Xbatch 禁用后台编译
-Xms 设置初始 Java 堆大小
-Xmx 设置最大 Java 堆大小
-Xss 设置 Java 线程堆栈大小
-Xprof 输出 cpu 配置文件数据
-Xfuture 启用最严格的检查, 预期将来的默认值
-Xrs 减少 Java/VM 对操作系统信号的使用 (请参阅文档)
-Xcheck:jni 对 JNI 函数执行其他检查
-Xshare:off 不尝试使用共享类数据
-Xshare:auto 在可能的情况下使用共享类数据 (默认)
-Xshare:on 要求使用共享类数据, 否则将失败。
-XshowSettings 显示所有设置并继续
-XshowSettings:all
显示所有设置并继续
-XshowSettings:vm 显示所有与 vm 相关的设置并继续
-XshowSettings:properties
显示所有属性设置并继续
-XshowSettings:locale
显示所有与区域设置相关的设置并继续
-X 选项是非标准选项, 如有更改, 恕不另行通知-XX 参数选项
-XX:+ 启用option属性
-XX:- 禁用option属性
-XX:= 设置option数值，可以带单位如k/K/m/M/g/G
-XX:= 设置option字符值
打印设置的 XX 选项及值
-XX:+PrintCommandLineFlags 程序运行时JVM默认设置或用户手动设置的XX选项
-XX:+PrintFlagsInitial 打印所有XX选项的默认值
-XX:+PrintFlagsFinal 打印所有XX选项的实际值
-XX:+PrintVMOptions 打印JVM的参数堆、栈、方法区等内存大小设置
# 栈
-Xss128k -XX:ThreadStackSize=128k 设置线程栈的大小为128K
# 堆
-Xms2048m -XX:InitialHeapSize=2048m 设置JVM初始堆内存为2048M
-Xmx2048m -XX:MaxHeapSize=2048m 设置JVM最大堆内存为2048M
-Xmn2g -XX:NewSize=2g -XX:MaxNewSize=2g 设置年轻代大小为2G
-XX:SurvivorRatio=8 设置Eden区与Survivor区的比值，默认为8
-XX:NewRatio=2 设置老年代与年轻代的比例，默认为2
-XX:+UseAdaptiveSizePolicy 设置大小比例自适应，默认开启
-XX:PretenureSizeThreadshold=1024 设置让大于此阈值的对象直接分配在老年代，只对Serial、ParNew收集器有效
-XX:MaxTenuringThreshold=15 设置新生代晋升老年代的年龄限制，默认为15
-XX:TargetSurvivorRatio 设置MinorGC结束后Survivor区占用空间的期望比例
# 方法区
-XX:MetaspaceSize / -XX:PermSize=256m 设置元空间/永久代初始值为256M
-XX:MaxMetaspaceSize / -XX:MaxPermSize=256m 设置元空间/永久代最大值为256M
-XX:+UseCompressedOops 使用压缩对象
-XX:+UseCompressedClassPointers 使用压缩类指针
-XX:CompressedClassSpaceSize 设置Klass Metaspace的大小，默认1G
# 直接内存
-XX:MaxDirectMemorySize 指定DirectMemory容量，默认等于Java堆最大值OutOfMemory 相关的选项
-XX:+HeapDumpOnOutMemoryError 内存出现OOM时生成Heap转储文件，两者互斥
-XX:+HeapDumpBeforeFullGC 出现FullGC时生成Heap转储文件，两者互斥
-XX:HeapDumpPath= 指定heap转储文件的存储路径，默认当前目录
-XX:OnOutOfMemoryError= 指定可行性程序或脚本的路径，当发生OOM时执行脚本# Serial回收器
-XX:+UseSerialGC 年轻代使用Serial GC， 老年代使用Serial Old GC
# ParNew回收器
-XX:+UseParNewGC 年轻代使用ParNew GC
-XX:ParallelGCThreads 设置年轻代并行收集器的线程数。
一般地，最好与CPU数量相等，以避免过多的线程数影响垃圾收集性能。
# Parallel回收器
-XX:+UseParallelGC 年轻代使用 Parallel Scavenge GC，互相激活
-XX:+UseParallelOldGC 老年代使用 Parallel Old GC，互相激活
-XX:ParallelGCThreads
-XX:MaxGCPauseMillis 设置垃圾收集器最大停顿时间（即STW的时间），单位是毫秒。
为了尽可能地把停顿时间控制在MaxGCPauseMills以内，收集器在工作时会调整Java堆大小或者其他一些参数。
对于用户来讲，停顿时间越短体验越好；但是服务器端注重高并发，整体的吞吐量。
所以服务器端适合Parallel，进行控制。该参数使用需谨慎。
-XX:GCTimeRatio 垃圾收集时间占总时间的比例（1 / (N＋1)），用于衡量吞吐量的大小
取值范围（0,100），默认值99，也就是垃圾回收时间不超过1％。
与前一个-XX：MaxGCPauseMillis参数有一定矛盾性。暂停时间越长，Radio参数就容易超过设定的比例。
-XX:+UseAdaptiveSizePolicy 设置Parallel Scavenge收集器具有自适应调节策略。
在这种模式下，年轻代的大小、Eden和Survivor的比例、晋升老年代的对象年龄等参数会被自动调整，以达到在堆大小、吞吐量和停顿时间之间的平衡点。
在手动调优比较困难的场合，可以直接使用这种自适应的方式，仅指定虚拟机的最大堆、目标的吞吐量（GCTimeRatio）和停顿时间（MaxGCPauseMills），让虚拟机自己完成调优工作。
# CMS回收器
-XX:+UseConcMarkSweepGC 年轻代使用CMS GC。
开启该参数后会自动将-XX：＋UseParNewGC打开。即：ParNew（Young区）+ CMS（Old区）+ Serial Old的组合
-XX:CMSInitiatingOccupanyFraction 设置堆内存使用率的阈值，一旦达到该阈值，便开始进行回收。JDK5及以前版本的默认值为68，DK6及以上版本默认值为92％。
如果内存增长缓慢，则可以设置一个稍大的值，大的阈值可以有效降低CMS的触发频率，减少老年代回收的次数可以较为明显地改善应用程序性能。
反之，如果应用程序内存使用率增长很快，则应该降低这个阈值，以避免频繁触发老年代串行收集器。
因此通过该选项便可以有效降低Fu1l GC的执行次数。
-XX:+UseCMSInitiatingOccupancyOnly 是否动态可调，使CMS一直按CMSInitiatingOccupancyFraction设定的值启动
-XX:+UseCMSCompactAtFullCollection 用于指定在执行完Full GC后对内存空间进行压缩整理
以此避免内存碎片的产生。不过由于内存压缩整理过程无法并发执行，所带来的问题就是停顿时间变得更长了。
-XX:CMSFullGCsBeforeCompaction 设置在执行多少次Full GC后对内存空间进行压缩整理。
-XX:ParallelCMSThreads 设置CMS的线程数量。
CMS 默认启动的线程数是(ParallelGCThreads＋3)/4，ParallelGCThreads 是年轻代并行收集器的线程数。
当CPU 资源比较紧张时，受到CMS收集器线程的影响，应用程序的性能在垃圾回收阶段可能会非常糟糕。
-XX:ConcGCThreads 设置并发垃圾收集的线程数，默认该值是基于ParallelGCThreads计算出来的
-XX:+CMSScavengeBeforeRemark 强制hotspot在cms remark阶段之前做一次minor gc，用于提高remark阶段的速度
-XX:+CMSClassUnloadingEnable 如果有的话，启用回收Perm 区（JDK8之前）
-XX:+CMSParallelInitialEnabled 用于开启CMS initial-mark阶段采用多线程的方式进行标记
用于提高标记速度，在Java8开始已经默认开启
-XX:+CMSParallelRemarkEnabled 用户开启CMS remark阶段采用多线程的方式进行重新标记，默认开启
-XX:+ExplicitGCInvokesConcurrent
-XX:+ExplicitGCInvokesConcurrentAndUnloadsClasses
这两个参数用户指定hotspot虚拟在执行System.gc()时使用CMS周期
-XX:+CMSPrecleaningEnabled 指定CMS是否需要进行Pre cleaning阶段
# G1回收器
-XX:+UseG1GC 手动指定使用G1收集器执行内存回收任务。
-XX:G1HeapRegionSize 设置每个Region的大小。
值是2的幂，范围是1MB到32MB之间，目标是根据最小的Java堆大小划分出约2048个区域。默认是堆内存的1/2000。
-XX:MaxGCPauseMillis 设置期望达到的最大GC停顿时间指标（JVM会尽力实现，但不保证达到）。默认值是200ms
-XX:ParallelGCThread 设置STW时GC线程数的值。最多设置为8
-XX:ConcGCThreads 设置并发标记的线程数。将n设置为并行垃圾回收线程数（ParallelGCThreads）的1/4左右。
-XX:InitiatingHeapOccupancyPercent 设置触发并发GC周期的Java堆占用率阈值。超过此值，就触发GC。默认值是45。
-XX:G1NewSizePercent 新生代占用整个堆内存的最小百分比（默认5％）
-XX:G1MaxNewSizePercent 新生代占用整个堆内存的最大百分比（默认60％）
-XX:G1ReservePercent=10 保留内存区域，防止 to space（Survivor中的to区）溢出
- 优先让 JVM 自适应，调整堆的大小
- 串行收集器：内存小于 100M；单核、单机程序，并且没有停顿时间的要求
- 并行收集器：多 CPU、高吞吐量、允许停顿时间超过 1 秒
- 并发收集器：多 CPU、追求低停顿时间、快速响应（比如延迟不能超过 1 秒，如互联网应用）
- 官方推荐 G1，性能高。现在互联网的项目，基本都是使用 G1。
-XX:+PrintGC -verbose:gc 打印简要日志信息
-XX:+PrintGCDetails 打印详细日志信息
-XX:+PrintGCTimeStamps 打印程序启动到GC发生的时间，搭配-XX:+PrintGCDetails使用
-XX:+PrintGCDateStamps 打印GC发生时的时间戳，搭配-XX:+PrintGCDetails使用
-XX:+PrintHeapAtGC 打印GC前后的堆信息，如下图
-Xloggc: 输出GC导指定路径下的文件中
编辑
-XX:+TraceClassLoading 监控类的加载
-XX:+PrintGCApplicationStoppedTime 打印GC时线程的停顿时间
-XX:+PrintGCApplicationConcurrentTime 打印垃圾收集之前应用未中断的执行时间
-XX:+PrintReferenceGC 打印回收了多少种不同引用类型的引用
-XX:+PrintTenuringDistribution 打印JVM在每次MinorGC后当前使用的Survivor中对象的年龄分布
-XX:+UseGCLogFileRotation 启用GC日志文件的自动转储
-XX:NumberOfGCLogFiles=1 设置GC日志文件的循环数目
-XX:GCLogFileSize=1M 设置GC日志文件的大小
-XX:+DisableExplicitGC 禁用hotspot执行System.gc()，默认禁用
-XX:ReservedCodeCacheSize=[g|m|k]、-XX:InitialCodeCacheSize=[g|m|k] 指定代码缓存的大小
-XX:+UseCodeCacheFlushing 放弃一些被编译的代码，避免代码缓存被占满时JVM切换到interpreted-only的情况
-XX:+DoEscapeAnalysis 开启逃逸分析
-XX:+UseBiasedLocking 开启偏向锁
-XX:+UseLargePages 开启使用大页面
-XX:+PrintTLAB 打印TLAB的使用情况
-XX:TLABSize 设置TLAB大小
public class MemoryMonitor {
public static void main(String[] args) {
MemoryMXBean memorymbean = ManagementFactory.getMemoryMXBean();
MemoryUsage usage = memorymbean.getHeapMemoryUsage();
System.out.println("INIT HEAP: " + usage.getInit() / 1024 / 1024 + "m");
System.out.println("MAX HEAP: " + usage.getMax() / 1024 / 1024 + "m");
System.out.println("USE HEAP: " + usage.getUsed() / 1024 / 1024 + "m");
System.out.println("\nFull Information:");
System.out.println("Heap Memory Usage: " + memorymbean.getHeapMemoryUsage());
System.out.println("Non-Heap Memory Usage: " + memorymbean.getNonHeapMemoryUsage());
System.out.println("=======================通过java来获取相关系统状态============================ ");
System.out.println("当前堆内存大小totalMemory " + (int) Runtime.getRuntime().totalMemory() / 1024 / 1024 + "m");// 当前堆内存大小
System.out.println("空闲堆内存大小freeMemory " + (int) Runtime.getRuntime().freeMemory() / 1024 / 1024 + "m");// 空闲堆内存大小
System.out.println("最大可用总堆内存maxMemory " + Runtime.getRuntime().maxMemory() / 1024 / 1024 + "m");// 最大可用总堆内存大小
}
}
针对 HotSpot VM的实现，它里面的GC按照回收区域又分为两大种类型:一种是部分收集（Partial GC)，一种是整堆收集（Full GC)。部分收集（Partial GC）:不是完整收集整个Java堆的垃圾收集。其中又分为:
- 新生代收集（Minor GC / Young GC):只是新生代（Eden / S0, S1）的垃圾收集
- 老年代收集(Major GC/ Old GC):只是老年代的垃圾收集。目前，只有CMS GC会有单独收集老年代的行为。注意，很多时候Major GC会和 Full GC混淆使用，需要具体分辨是老年代回收还是整堆回收。
混合收集（Mixed GC):收集整个新生代以及部分老年代的垃圾收集。只有G1GC会有这种行为。
整堆收集（Full GC）:收集整个 java堆和方法区的垃圾收集。MinorGC MinorGC（或 young GC 或 YGC）日志：
[GC (Allocation Failure) [PSYoungGen: 31744K->2192K (36864K) ] 31744K->2200K (121856K), 0.0139308 secs] [Times: user=0.05 sys=0.01, real=0.01 secs]
FullGC
[Full GC (Metadata GC Threshold) [PSYoungGen: 5104K->0K (132096K) ] [Par01dGen: 416K->5453K (50176K) ]5520K->5453K (182272K), [Metaspace: 20637K->20637K (1067008K) ], 0.0245883 secs] [Times: user=0.06 sys=0.00, real=0.02 secs]
透过日志看垃圾收集器
-
Serial 收集器：新生代显示 "[DefNew"，即 Default New Generation
-
ParNew 收集器：新生代显示 "[ParNew"，即 Parallel New Generation
-
Parallel Scavenge 收集器：新生代显示"[PSYoungGen"，JDK1.7 使用的即 PSYoungGen
-
Parallel Old 收集器：老年代显示"[ParoldGen"
-
G1 收集器：显示”garbage-first heap“
透过日志看 GC 原因
- Allocation Failure：表明本次引起 GC 的原因是因为新生代中没有足够的区域存放需要分配的数据
- Metadata GCThreshold：Metaspace 区不够用了
- FErgonomics：JVM 自适应调整导致的 GC
- System：调用了 System.gc()方法
透过日志看 GC 前后情况
通过图示，我们可以发现 GC 日志格式的规律一般都是：GC 前内存占用-＞ GC 后内存占用（该区域内存总大小）
[PSYoungGen: 5986K->696K (8704K) ] 5986K->704K (9216K)-
中括号内：GC 回收前年轻代堆大小，回收后大小，（年轻代堆总大小）
-
括号外：GC 回收前年轻代和老年代大小，回收后大小，（年轻代和老年代总大小）
注意：Minor GC 堆内存总容量 = 9/10 年轻代 + 老年代。原因是 Survivor 区只计算 from 部分，而 JVM 默认年轻代中 Eden 区和 Survivor 区的比例关系，Eden:S0:S1=8:1:1。
透过日志看 GC 时间
GC 日志中有三个时间：user，sys 和 real
- user：进程执行用户态代码（核心之外）所使用的时间。这是执行此进程所使用的实际 CPU 时间，其他进程和此进程阻塞的时间并不包括在内。在垃圾收集的情况下，表示 GC 线程执行所使用的 CPU 总时间。
- sys：进程在内核态消耗的 CPU 时间，即在内核执行系统调用或等待系统事件所使用的 CPU 时间
- real：程序从开始到结束所用的时钟时间。这个时间包括其他进程使用的时间片和进程阻塞的时间（比如等待 I/O 完成）。对于并行 gc，这个数字应该接近（用户时间＋系统时间）除以垃圾收集器使用的线程数。
由于多核的原因，一般的 GC 事件中，real time 是小于 sys time ＋ user time 的，因为一般是多个线程并发的去做 GC，所以 real time 是要小于 sys ＋ user time 的。如果 real ＞ sys ＋ user 的话，则你的应用可能存在下列问题：IO 负载非常重或 CPU 不够用。
十、GC 日志分析工具 GCEasyGCEasy 是一款在线的 GC 日志分析器，可以通过 GC 日志分析进行内存泄露检测、GC 暂停原因分析、JVM 配置建议优化等功能，大多数功能是免费的。
官网地址：https://gceasy.io/
GCViewerGCViewer 是一款离线的 GC 日志分析器，用于可视化 Java VM 选项 -verbose:gc 和 .NET 生成的数据 -Xloggc:。还可以计算与垃圾回收相关的性能指标（吞吐量、累积的暂停、最长的暂停等）。当通过更改世代大小或设置初始堆大小来调整特定应用程序的垃圾回收时，此功能非常有用。
源码下载：https://github.com/chewiebug/GCViewer
运行版本下载：https://github.com/chewiebug/GCViewer/wiki/Changelog
GChisto- 官网上没有下载的地方，需要自己从 SVN 上拉下来编译
- 不过这个工具似乎没怎么维护了，存在不少 bug
- 工具很强大，但是只能打开由以下参数生成的 GC log，-verbose:gc -Xloggc:gc.log。添加其他参数生成的 gc.log 无法打开
- HPjmeter 集成了以前的 HPjtune 功能，可以分析在 HP 机器上产生的垃圾回收日志文件
《JVM调优实战分析》
