JVM调优

JVM 层面 需要对 JVM 实现参数调优 减少 gc 回收频率 减少 stw 问题
JVM（Java Virtual Machine）调优是优化Java应用程序性能的关键步骤，主要涉及到JVM的内存管理、垃圾回收、线程管理等方面。通过合理配置 JVM 参数和垃圾回收器，可以提高应用的稳定性和响应速度。
jvm调优是为了调优gc，主要就是两个点，一个是减少Full gc的次数，一个是缩短一次Full gc的时间
对JVM内存的系统级的调优主要的目的是减少GC的频率和Full GC的次数

JVM 调优的主要方法

JVM 堆内存调优

调整堆内存大小：
初始堆大小（-Xms）：设置JVM启动时堆的初始内存大小。
最大堆大小（-Xmx）：设置JVM可使用的堆内存的最大值。
根据应用程序的内存需求调整这两个参数，以避免内存溢出或频繁进行垃圾回收。
堆内存区域划分：
JVM堆内存被划分为新生代（Young Generation）和老年代（Old Generation）。新生代又进一步细分为Eden区、两个Survivor区（From Survivor和To Survivor）。
通过调整新生代和老年代的比例（使用-XX:NewRatio参数），以及Eden区和Survivor区的比例（使用-XX:SurvivorRatio参数），可以优化内存分配和回收效率。
调优新生代和老年代：根据应用对象的生命周期，调整新生代（Young Generation）和老年代（Old Generation）的比例，减少 GC 次数和停顿时间。
调整JVM参数：根据应用的特点调整JVM的启动参数，例如堆大小、栈大小、JIT编译阈值等。
分析JVM性能：使用工具如jconsole、jvisualvm或YourKit等分析JVM的性能瓶颈。
调整堆大小、栈大小、元空间大小等参数以适应应用程序的需求。
设置堆内存大小
-Xms 和 -Xmx：设置 JVM 堆内存的初始大小和最大大小。一般建议将 -Xms 和 -Xmx 设置为相同的值，以避免堆动态扩展导致的性能问题。
java -Xms1024m -Xmx1024m -jar app.jar
新生代和老年代内存分配
-Xmn：设置新生代（Young Generation）的大小，通常是堆内存大小的 1/3。新生代的大小会影响 Minor GC 的频率和停顿时间。
java -Xmn512m -jar app.jar
-XX:NewRatio：设置新生代与老年代（Old Generation）的比例，NewRatio=3 表示老年代是新生代的 3 倍。
java -XX:NewRatio=3 -jar app.jar
元空间（Metaspace）配置
-XX:MetaspaceSize 和 -XX:MaxMetaspaceSize：配置元空间的初始大小和最大大小，用于存储类的元数据。在 JDK 8 及以上版本中，永久代被替换为元空间。
java -XX:MetaspaceSize=128m -XX:MaxMetaspaceSize=512m -jar app.jar

垃圾回收器 (GC) 调优

选择合适的垃圾回收器
Serial GC：单线程执行，适用于小型应用和单核处理器环境。
Parallel GC：多线程执行，适用于多核处理器，吞吐量优先。
CMS（Concurrent Mark-Sweep）GC：并发执行，减少停顿时间，适合对延迟敏感的应用。
G1（Garbage-First）GC：Java 9及之后的默认垃圾回收器，适用于大堆和多核环境，具有可预测的停顿时间。
ZGC：适用于超大堆内存，低延迟的场景，暂停时间极短。
调整GC参数：
根据应用程序的具体需求和硬件环境选择合适的GC算法，并通过相应参数进行配置。
例如，使用-XX:+UseParallelGC选择Parallel GC，使用-XX:+UseConcMarkSweepGC选择CMS GC等。
GC日志分析：
启用GC日志（使用-Xloggc:和-XX:+PrintGCDetails参数），并通过工具（如GCViewer、GCEasy）分析GC日志，了解GC行为和性能瓶颈。
JVM 提供了多种垃圾回收器，不同的 GC 适用于不同的应用场景：
1.串行垃圾回收器 (Serial GC)
-XX:+UseSerialGC：单线程执行垃圾回收，适用于小型应用或单核系统。由于是串行处理，在现代服务器上效率较低。
java -XX:+UseSerialGC -jar app.jar
2.并行垃圾回收器 (Parallel GC)
-XX:+UseParallelGC：多线程执行垃圾回收，适用于 CPU 密集型应用，能在较短时间内处理大量对象。默认是 Throughput 优先。
java -XX:+UseParallelGC -XX:ParallelGCThreads=4 -jar app.jar
-XX:+UseParallelOldGC：Parallel GC 的老年代版本，适合需要高吞吐量的应用。
3.CMS 垃圾回收器
-XX:+UseConcMarkSweepGC：以低延迟为目标的垃圾回收器，适用于对响应时间敏感的应用。CMS 可以在应用线程运行的同时执行垃圾回收，减少停顿时间。
java -XX:+UseConcMarkSweepGC -XX:+CMSParallelRemarkEnabled -XX:+UseCMSInitiatingOccupancyOnly -XX:CMSInitiatingOccupancyFraction=75 -jar app.jar
-XX:+CMSParallelRemarkEnabled：使 remark 阶段并行化。
-XX:+UseCMSInitiatingOccupancyOnly：使用 CMSInitiatingOccupancyFraction 来控制 CMS GC 的触发。
-XX:CMSInitiatingOccupancyFraction=75：当老年代使用达到 75% 时触发 CMS GC。
4.G1 垃圾回收器
-XX:+UseG1GC：G1 是适用于大多数应用的低延迟垃圾回收器，能够在目标暂停时间内执行垃圾回收，适合多核 CPU 和大内存场景。
java -XX:+UseG1GC -XX:MaxGCPauseMillis=200 -XX:InitiatingHeapOccupancyPercent=45 -jar app.jar
-XX:MaxGCPauseMillis=200：设置最大 GC 停顿时间为 200 毫秒。
-XX:InitiatingHeapOccupancyPercent=45：当堆内存使用达到 45% 时触发混合 GC。
5. ZGC (Z Garbage Collector)
-XX:+UseZGC：ZGC 是一款专为低延迟设计的垃圾回收器，适用于大内存、高并发的应用场景。ZGC 的停顿时间通常在 10 毫秒以内。
java -XX:+UseZGC -Xms4g -Xmx4g -XX:ConcGCThreads=2 -XX:ParallelGCThreads=4 -jar app.jar
-XX:ConcGCThreads 和 -XX:ParallelGCThreads：配置并发和并行 GC 线程数。
6.Shenandoah GC
-XX:+UseShenandoahGC：另一个低延迟垃圾回收器，与 ZGC 类似，旨在保持低暂停时间，适合超大堆内存的应用。
java -XX:+UseShenandoahGC -XX:ShenandoahGCHeuristics=compact -XX:ShenandoahUncommitDelay=10000 -jar app.jar
-XX:ShenandoahGCHeuristics：设置 GC 策略，如 compact、aggressive。
-XX:ShenandoahUncommitDelay：设置未使用内存的回收延迟时间。

垃圾回收日志与监控

启用 GC 日志
● -Xlog:gc:：启用垃圾回收日志，用于分析和调优。日志包括 GC 事件、时间和内存使用情况。
java -Xlog:gc:file=gc.log:time,uptime:filecount=5,filesize=10M -jar app.jar
file=gc.log：指定日志文件路径。
filecount=5, filesize=10M：指定最多保存 5 个文件，每个文件最大 10 MB。
GC 日志分析
使用 GCViewer、GCEasy 或 Garbagecat 等工具分析 GC 日志，确定 GC 的频率、停顿时间，以及内存使用模式。

JVM 线程调优

调整线程参数：
使用-XX:ParallelGCThreads和-XX:ConcGCThreads等参数调整并行GC和并发GC的线程数。
根据应用程序的并发需求和硬件资源进行合理配置。
优化线程栈大小：
使用-Xss参数设置线程的堆栈大小，避免堆栈溢出并优化线程性能。
配置线程栈大小
-Xss：设置每个线程的栈大小。对于大多数应用，默认值已足够，但在大量线程或递归较深的场景下可能需要调整。
java -Xss512k -jar app.jar
合理使用线程池
● 在应用中使用合理的线程池大小，避免过多或过少的线程造成资源浪费或竞争。可以通过 Executors 或 ThreadPoolExecutor 来创建和管理线程池。
ExecutorService executor = Executors.newFixedThreadPool(10);
调整 GC 线程
-XX:ParallelGCThreads：设置用于并行 GC 的线程数。
java -XX:ParallelGCThreads=8 -jar app.jar
-XX:ConcGCThreads：设置 CMS 或 G1 GC 的并发线程数。

ClassLoader 类加载优化

减少类加载
减少类加载次数和避免类加载器的泄漏，特别是在 Web 容器中重新加载应用时，确保旧的类加载器可以被回收。
使用 -XX:+TraceClassLoading 选项跟踪类加载情况，优化类的加载路径和加载顺序。
缓存类加载器
在可能的情况下缓存常用的类加载器，以减少重复加载的开销。
优化类加载过程：
通过预加载和缓存常用的类、延迟加载不必要的类等方式来优化类加载性能。
使用工具（如JProfiler、VisualVM）分析类加载过程，找出性能瓶颈并进行优化。

高级 JVM 调优

AOT 编译
-XX:AOTLibrary：使用 Ahead-of-Time (AOT) 编译来减少应用启动时间，将热点方法提前编译为本地代码。
java -XX:AOTLibrary=library.so -jar app.jar
JVM 自适应调优
-XX:+UseAdaptiveSizePolicy：启用 JVM 的自适应调整策略，让 JVM 自动调整堆内存和 GC 的各项参数。
使用 -XX:+AlwaysPreTouch
预先触碰所有内存页，减少在应用启动时进行的内存初始化开销，尤其在大内存应用中可以提升启动速度。
java -XX:+AlwaysPreTouch -jar app.jar
锁优化
-XX:+UseBiasedLocking：启用偏向锁（默认启用），在无竞争的情况下减少锁的
调整JIT编译器的参数来提高代码的执行效率。

调优目标、原则

调优目标
JVM调优的目标
吞吐量、延迟、内存占用三者类似CAP，构成了一个不可能三角，只能选择其中两个进行调优，不可三者兼得。
延迟：GC低停顿和GC低频率；
低内存占⽤
⾼吞吐量
选择了其中两个，必然会会以牺牲另一个为代价。
JVM 调优量化目标
Heap 内存使用率 <= 70%;
Old generation 内存使用率<= 70%;
avgpause <= 1 秒;
Full gc 次数 0 或 avg pause interval >= 24 小时
注意：不同应用的JVM调优量化目标是不一样的。
定位出系统瓶颈后，在优化前先制定好优化的目标是什么，例如：
将FGC次数从每小时1次，降低到1天1次
将每分钟的GC耗时从3s降低到500ms
将每次FGC耗时从5s降低到1s以内

调优时机
heap 内存（⽼年代）持续上涨达到设置的最大内存值；
Full GC 次数频繁；
GC 停顿时间过⻓（超过1秒）；
应⽤出现OutOfMemory 等内存异常；
应⽤中有使⽤本地缓存且占⽤⼤量内存空间；
系统吞吐量与响应性能不⾼或下降。
调优原则

1. 多数的Java应⽤不需要在服务器上进⾏JVM优化；
2. 多数导致GC问题的Java应⽤，都不是因为我们参数设置错误，而是代码问题；
3. 在应⽤上线之前，先考虑将机器的JVM参数设置到最优（最适合）
4. 减少创建对象的数量；
5. 减少使⽤全局变量和大对象；
6. JVM优化是到最后不得已才采⽤的⼿段；
7. 在实际使⽤中，分析GC情况优化代码比优化JVM参数更好；
   制订优化方案
   针对定位出的系统瓶颈制定相应的优化方案，常见的有：
   代码bug：升级修复bug。典型的有：死循环、使用无界队列。
   不合理的JVM参数配置：优化 JVM 参数配置。
   典型的有：年轻代内存配置过小、堆内存配置过小、元空间配置过小。

jvm调优分析

运维三连 top free df
基础的性能问题排查，例如dump堆操作、堆内存分析、GC分析
1.Full GC
会对整个堆进行整理，包括Young、Tenured和Perm。Full GC因为需要对整个堆进行回收，所以比较慢，因此应该尽可能减少Full GC的次数
2.导致Full GC的原因
1)年老代（Tenured）被写满
调优时尽量让对象在新生代GC时被回收、让对象在新生代多存活一段时间和不要创建过大的对象及数组避免直接在旧生代创建对象 。
2)持久代Pemanet Generation空间不足
增大Perm Gen空间，避免太多静态对象 ， 控制好新生代和旧生代的比例
3)System.gc()被显示调用
垃圾回收不要手动触发，尽量依靠JVM自身的机制
在对JVM调优的过程中，很大一部分工作就是对于FullGC的调节，下面详细介绍对应JVM调优的方法和步骤。
1）CPU指标
// 显示系统各个进程的资源使用情况
top
// 查看某个进程中的线程占用情况
top -Hp pid
// 查看当前 Java 进程的线程堆栈信息
jstack pid
// 显示系统各个进程的资源使用情况
top
// 查看某个进程中的线程占用情况
top -Hp pid
// 查看当前 Java 进程的线程堆栈信息
jstack pid
常见的工具：JProfiler、JVM Profiler、Arthas等
2）JVM 内存指标
查看当前 JVM 堆内存参数配置是否合理
查看堆中对象的统计信息
查看堆存储快照，分析内存的占用情况
查看堆各区域的内存增长是否正常
查看是哪个区域导致的GC
查看GC后能否正常回收到内存
// 查看当前的 JVM 参数配置
ps -ef | grep java
// 查看 Java 进程的配置信息，包括系统属性和JVM命令行标志
jinfo pid
// 输出 Java 进程当前的 gc 情况
jstat -gc pid
// 输出 Java 堆详细信息
jmap -heap pid
// 显示堆中对象的统计信息
jmap -histo:live pid
// 生成 Java 堆存储快照dump文件
jmap -F -dump:format=b,file=dumpFile.phrof pid
常见的工具：Eclipse MAT、JConsole等。
3.JVM GC指标
查看每分钟GC时间是否正常
查看每分钟YGC次数是否正常
查看FGC次数是否正常
查看单次FGC时间是否正常
查看单次GC各阶段详细耗时，找到耗时严重的阶段
查看对象的动态晋升年龄是否正常
JVM 的 GC指标一般是从 GC 日志里面查看，默认的 GC 日志可能比较少，我们可以添加以下参数，来丰富我们的GC日志输出，方便我们定位问题。
GC日志常用 JVM 参数：
// 打印GC的详细信息
-XX:+PrintGCDetails
// 打印GC的时间戳
-XX:+PrintGCDateStamps
// 在GC前后打印堆信息
-XX:+PrintHeapAtGC
// 打印Survivor区中各个年龄段的对象的分布信息
-XX:+PrintTenuringDistribution
// JVM启动时输出所有参数值，方便查看参数是否被覆盖
-XX:+PrintFlagsFinal
// 打印GC时应用程序的停止时间
-XX:+PrintGCApplicationStoppedTime
// 打印在GC期间处理引用对象的时间（仅在PrintGCDetails时启用）
-XX:+PrintReferenceGC

性能分析办法
jstat 查看堆内存的分布
jstat 命令，对Java应用程序的资源和性能进行实时的命令行的监控。jstat 性能分析
jstat -pid
jmap命令，用来诊断内存问题，如内存泄漏等。jmap用来查看堆信息，查看内存， 堆内的使用情况
jmap -dump:format=b,file=
jstack用来查看栈信息，jstack 查看线程
jstack,主要分析线程问题，跟jmap主要分析OOM和堆内存问题不同。
主要用来跟踪java进程中的线程的执行状态，比较重要。
jstack pid; //可以打印出进程中线程的栈，及状态
jps 进程的状态
jinfo 是 JDK 自带的命令，可以用来查看正在运行的 java 应用程序的扩展参数，包括Java System属性和JVM命令行参数；也可以动态的修改正在运行的 JVM 一些参数。当系统崩溃时，jinfo可以从core文件里面知道崩溃的Java应用程序的配置信息

JVM性能调优步骤

调优步骤
分 析GC日志及dump⽂件，判断是否需要优化，确定瓶颈问题点 ；
确 定jvm调优量化⽬标；
确 定jvm调优参数（根据历史jvm参数来调整）；
调优⼀台服务器，对⽐观察调优前后的差异；
不断的分析和调整，知道找到合适的jvm参数配置；
找到最合适的参数，将这些参数应⽤到所有服务器，并进行后续跟踪
监控GC的状态
使用各种JVM工具，查看当前日志，分析当前JVM参数设置，并且分析当前堆内存快照和gc日志，根据实际的各区域内存划分和GC执行时间，觉得是否进行优化。
每次垃圾回收的时间越来越长，由之前的10ms延长到50ms左右，FullGC的时间也有之前的0.5s延长到4、5s
FullGC的次数越来越多，最频繁时隔不到1分钟就进行一次FullGC
年老代的内存越来越大并且每次FullGC后年老代没有内存被释放
之后系统会无法响应新的请求，逐渐到达OutOfMemoryError的临界值，这个时候就需要分析JVM内存快照dump。
生成堆的dump文件
通过JMX的MBean生成当前的Heap信息，大小为一个3G（整个堆的大小）的hprof文件，如果没有启动JMX可以通过Java的jmap命令来生成该文件。
分析dump文件
打开这个3G的堆信息文件，显然一般的Window系统没有这么大的内存，必须借助高配置的Linux，几种工具打开该文件：
Visual VM
IBM HeapAnalyzer
JDK 自带的Hprof工具
Mat(Eclipse专门的静态内存分析工具)推荐使用
备注：文件太大，建议使用Eclipse专门的静态内存分析工具Mat打开分析。
分析结果，判断是否需要优化
如果各项参数设置合理，系统没有超时日志出现，GC频率不高，GC耗时不高，那么没有必要进行GC优化，如果GC时间超过1-3秒，或者频繁GC，则必须优化。
注：如果满足下面的指标，则一般不需要进行GC：
Minor GC执行时间不到50ms；
Minor GC执行不频繁，约10秒一次；
Full GC执行时间不到1s；
Full GC执行频率不算频繁，不低于10分钟1次；
调整GC类型和内存分配
如果内存分配过大或过小，或者采用的GC收集器比较慢，则应该优先调整这些参数，并且先找1台或几台机器进行beta，然后比较优化过的机器和没有优化的机器的性能对比，并有针对性的做出最后选择。
不断的分析和调整
通过不断的试验和试错，分析并找到最合适的参数，如果找到了最合适的参数，则将这些参数应用到所有服务器。
cms参数优化步流程
JVM调优参数参考
1.针对JVM堆的设置，一般可以通过-Xms -Xmx限定其最小、最大值，为了防止垃圾收集器在最小、最大之间收缩堆而产生额外的时间，通常把最大、最小设置为相同的值;
2.年轻代和年老代将根据默认的比例（1：2）分配堆内存， 可以通过调整二者之间的比率NewRadio来调整二者之间的大小，也可以针对回收代。
比如年轻代，通过 -XX:newSize -XX:MaxNewSize来设置其绝对大小。同样，为了防止年轻代的堆收缩，我们通常会把-XX:newSize -XX:MaxNewSize设置为同样大小。
3.年轻代和年老代设置多大才算合理
1）更大的年轻代必然导致更小的年老代，大的年轻代会延长普通GC的周期，但会增加每次GC的时间；小的年老代会导致更频繁的Full GC
2）更小的年轻代必然导致更大年老代，小的年轻代会导致普通GC很频繁，但每次的GC时间会更短；大的年老代会减少Full GC的频率
如何选择应该依赖应用程序对象生命周期的分布情况： 如果应用存在大量的临时对象，应该选择更大的年轻代；如果存在相对较多的持久对象，年老代应该适当增大。但很多应用都没有这样明显的特性。
在抉择时应该根 据以下两点：
（1）本着Full GC尽量少的原则，让年老代尽量缓存常用对象，JVM的默认比例1：2也是这个道理 。
（2）通过观察应用一段时间，看其他在峰值时年老代会占多少内存，在不影响Full GC的前提下，根据实际情况加大年轻代，比如可以把比例控制在1：1。但应该给年老代至少预留1/3的增长空间。
4.在配置较好的机器上（比如多核、大内存），可以为年老代选择并行收集算法： -XX:+UseParallelOldGC 。
5.线程堆栈的设置：每个线程默认会开启1M的堆栈，用于存放栈帧、调用参数、局部变量等，对大多数应用而言这个默认值太了，一般256K就足用。
理论上，在内存不变的情况下，减少每个线程的堆栈，可以产生更多的线程，但这实际上还受限于操作系统。

JVM 参数介绍

JVM主要参数：堆设置、回收器选择（串行、并行、并发收集器）
JVM 参数类型大致分为以下几类：
标准参数（-），即在 JVM 的各个版本中基本不变的，相对比较稳定的参数，向后兼容;
非标准参数（-X），变化比较小的参数，默认 JVM 实现这些参数的功能，但是并不保证所有 JVM 实现都满足，且不保证向后兼容；
非Stable参数（-XX），此类参数各个 JVM 实现会有所不同，将来可能会随时取消，需要慎重使用；
java -Xmx3550m -Xms3550m -Xmn2g -Xss128k
-XX:MaxPermSize=16m -XX:NewRatio=4 -XX:SurvivorRatio=4 -XX:MaxTenuringThreshold=0
-Xmx3550m： 最大堆大小为3550m。
-Xms3550m： 设置初始堆大小为3550m。
-Xmn2g： 设置年轻代大小为2g。
-Xss128k： 每个线程的堆栈大小为128k。
-XX:MaxPermSize： 设置持久代大小为16m
-XX:NewRatio=4: 设置年轻代（包括Eden和两个Survivor区）与年老代的比值（除去持久代）。
-XX:SurvivorRatio=4： 设置年轻代中Eden区与Survivor区的大小比值。设置为4，则两个Survivor区
与一个Eden区的比值为2:4，一个Survivor区占整个年轻代的1/6
-XX:MaxTenuringThreshold=0： 设置垃圾最大年龄。如果设置为0的话，则年轻代对象不经过
Survivor区，直接进入年老代
-Xms 初始堆大小，ms是memory start的简称 ，等价于-XX:InitialHeapSize
-Xmx 最大堆大小，mx是memory max的简称 ，等价于参数-XX:MaxHeapSize
-XX:NewSize=n 设置年轻代大小
-XX:NewRatio=n 设置年轻代和年老代的比值。如:-XX:NewRatio=3，表示年轻代与年老代比值为1：3，年轻代占整个年轻代年老代和的1/4，默认新生代和老年代的比例=1:2
-XX:SurvivorRatio=n 年轻代中Eden区与两个Survivor区的比值。注意Survivor区有两个，默认是8，表示
Eden:S0:S1=8:1:1
如：-XX:SurvivorRatio=3，表示Eden：Survivor=3：2，一个Survivor区占整个年轻代的1/5。
-XX:MaxPermSize=n 设置持久代大小，
-XX:MetaspaceSize 设置元空间大小 。
–XX:+UseParNewGC：指定使用 ParNew + Serial Old 垃圾回收器组合；
-XX:+UseParallelOldGC：指定使用 ParNew + ParNew Old 垃圾回收器组合；
-XX:+UseConcMarkSweepGC：指定使用 CMS + Serial Old 垃圾回收器组合；
-XX:+PrintGC：开启打印 gc 信息；
-XX:+PrintGCDetails：打印 gc 详细信息。
-XX:+UseParallelGC： 选择垃圾收集器为并行收集器。
-XX:ParallelGCThreads=20： 配置并行收集器的线程数
-XX:+UseConcMarkSweepGC： 设置年老代为并发收集。
-XX:CMSFullGCsBeforeCompaction：由于并发收集器不对内存空间进行压缩、整理，所以运行一段
时间以后会产生“碎片”，使得运行效率降低。此值设置运行多少次GC以后对内存空间进行压缩、整理。
-XX:+UseCMSCompactAtFullCollection： 打开对年老代的压缩。可能会影响性能，但是可以消除碎
片
-XX:+UseG1GC:使用G1收集器

-XX:ParallelGCThreads:指定GC工作的线程数量

-XX:G1HeapRegionSize:指定分区大小(1MB~32MB，且必须是2的N次幂)，
默认将整堆划分为2048个分区.

-XX:MaxGCPauseMillis:目标暂停时间(默认200ms)
也就是垃圾回收的时候允许停顿的时间

-XX:G1NewSizePercent:新生代内存初始空间(默认整堆5%)

-XX:G1MaxNewSizePercent:新生代内存最大空间，默认是60%。

-XX:TargetSurvivorRatio:Survivor区的填充容量(默认50%)，Survivor
区域里的一批对象(年龄1+年龄2+年龄n的多个年龄对象)总和超过
了Survivor区域的50%，此时就会把年龄n(含)以上的对象都放入老年代

-XX:MaxTenuringThreshold:最大年龄阈值(默认15) ，当在年轻代经历了15次GC
还没有被回收掉，那么进入老年代。

-XX:InitiatingHeapOccupancyPercent:老年代占用空间达到整堆内存阈值(默认45%)，
则执行新生代和老年代的混合收集(MixedGC)，比如我们之前说的堆默认有2048个region，
如果有接近1000个region都是老年代的region，则可能 就要触发MixedGC了。
也就是MixedGC触发的条件

-XX:G1MixedGCLiveThresholdPercent(默认85%) region中的存活对象低于这个值时
才会回收该region，如果超过这 个值，存活对象过多，回收的的意义不大。
在我们回收老年代的时候，我们需要知道老年代每个region中有多少存活对象。比如一个
region中有100个对象，其中有85个是存活对象，垃圾对象是15个。那么这样的region回收
的意义不大。反过来，如果有80格式垃圾对象，存活对象有只有20个，那么这时候就应该被回收。

-XX:G1MixedGCCountTarget:在一次回收过程中指定做几次筛选回收(默认8次)，
在最后一个筛选回收阶段可以回收一 会，然后暂停回收，恢复系统运行，
一会再开始回收，这样可以让系统不至于单次停顿时间过长。

-XX:G1HeapWastePercent(默认5%): gc过程中空出来的region是否充足阈值，在混合回收的时候，
对Region回收都 是基于复制算法进行的，都是把要回收的Region里的存活对象放入其他Region，
然后这个Region中的垃圾对象全部清 理掉，这样的话在回收过程就会不断空出来新的Region，
一旦空闲出来的Region数量达到了堆内存的5%，此时就会立 即停止混合回收，
意味着本次混合回收就结束了。