默认情况下，初始堆大小：物理内存大小的1/64。最大堆大小：物理内存大小的1/4或1G。
参考官方文档：https://docs.oracle.com/javase/8/docs/technotes/guides/vm/gc-ergonomics.html
建议：通常将-Xms和-Xmx配置成一样的值，目的是为了能够在Java垃圾回收机制清理完堆区后不需要重新分隔计算堆区的大小，从而提高性能。
默认比例
注：
1）默认SurvivorRatio=8，但是在运行的过程中，JVM可能会动态调整，即使关闭自适应参数（-XX:-UseAdaptiveSizePolicy）也会动态调整，解决办法是显式指定-XX:SurvivorRatio=8。
2）-Xmn可以设置新生代的空间的大小与NewRatio（默认是2）参数冲突，如果设置了以-Xmn为准。
public class HeapSpaceInitial {
public static void main(String[] args) throws InterruptedException {
//返回Java虚拟机中的堆内存总量
long initialMemory = Runtime.getRuntime().totalMemory() / 1024 / 1024;
//返回Java虚拟机试图使用的最大堆内存量
long maxMemory = Runtime.getRuntime().maxMemory() / 1024 / 1024;
System.out.println("-Xms : " + initialMemory + "M");
System.out.println("-Xmx : " + maxMemory + "M");
Thread.sleep(1000000);
}
}
注：控制台输出19M是因为只计算了S0/S1中的一个。
方式二：VisualVM查看
D:JavaEEJavaEE_2022_0311JVMTestsrc>jstat -gc 38036 S0C S1C S0U S1U EC EU OC OU MC MU CCSC CCSU YGC YGCT FGC FGCT GCT 512.0 512.0 0.0 496.0 5632.0 3987.5 13824.0 1412.1 8576.0 8249.0 1152.0 987.9 1 0.002 0 0.000 0.002 D:JavaEEJavaEE_2022_0311JVMTestsrc>方式四：通过GC日志查看
-Xms20m -Xmx20m -XX:+PrintGCDetails
注意：5632K(Eden)+512K(from/to) = 6144K，即total只包含from/to中一个的大小。
JVM在进行GC时，并非每次都会上面3个内存区域一起回收，大部分回收的都是新生代。
针对HotSpot VM的实现，它里面的GC按照回收区域又分为两大类型：一种是部分收集（Partial GC），一种是整堆收集（Full GC）
部分收集：不是完整收集整个Java堆的垃圾收集。又分为：
① 新生代收集（Minor GC/Young GC）：只是新生代的垃圾收集
② 老年代收集（Major GC/Old GC）:只是老年代的垃圾收集。
目前，只有CMS GC会有单独收集老年代的行为。
③ 混合收集（Mixed GC）:收集整个新生代以及部分老年代的垃圾收集。
目前，只有G1 GC会有这种行为。
整堆收集（Full GC）:收集整个Java堆和方法区的垃圾收集。
1）新生代GC（Minor GC）触发机制：
在GC开始的时候，对象只会存在于Eden区和名为“From”的Survivor区，Survivor区“To”是空的。
紧接着进行GC，Eden区中所有存活的对象都会被复制到“To”，而在“From”区中，仍存活的对象会根据他们的年龄值来决定去向。
年龄达到一定值(年龄阈值，可以通过XX:MaxTenuringThreshold来设置)的对象会被移动到年老代中，没有达到阈值的对象会被复制到“To”区域。
经过这次GC后，Eden区和From区已经被清空。这个时候，“From”和“To”会交换他 们的角色，也就是新的“To”就是上次GC前的“From”，新的“From”就是上次GC前的“To”。不管怎样，都会保证名为To的Survivor区域是空的。
GC会一直重复这样的过程，直到“To”区被填满，“To”区被填满之后，会将所有对象移动到年老代中。
当Eden区满了会触发YGC，Survior区满了不会触发YGC，当Eden区满触发YGC会同时回收Eden区和Survior区，S0/S1区如果满了，会直接晋升到老年代。
2）老年代GC（Major GC）触发机制：
老年代空间不足时，会先触发Minor GC,如果之后空间还不足，则触发Major GC。
3）Full GC触发机制：
System.gc()老年代空间不足，比如通过Minor GC后进入老年代的平均大小大于老年代的可用内存；Eden、S0向S1区复制对象时，对象大小大于S1的内存，则对象会存到老年代，此时如果老年代的内存小于该对象大小，会触发Full GC。总之就是老年代的内存不够。方法区空间不足
每次Full GC前会调用一次Young GC
有限分配到Eden长期存活的对象分配到老年代大对象直接分配到老年代动态对象年龄判断
如果Survivor区中所有相同年龄对象的大小总和大于Survivor大小的一半，年龄大于或等于该年龄的对象可以直接进入老年代，无须等到MaxTenuringThreshold中要求的年龄。
垃圾收集次数
频繁收集Young区
减少收集Old区
基本不动方法区
STW事件和采用哪款GC无关，所有的GC都有这个事件。
哪怕是G1也不能完全避免Stop-the-world情况发生，只能说垃圾回收器越来越优秀，回收效率越来越高，尽可能地缩短了暂停时间。
STW是JVM在后台自动发起和自动完成的，在用户不可见的情况下，把用户正常的工作线程全部停掉。
开发中不要用System.gc();会导致Stop-the-world的发生。
强软弱虚强引用：强引用的对象是可触及的，垃圾收集器永远不会回收掉被引用的对象。
软引用：被软引用关联着的对象，在系统将要发生内存溢出异常前，会把这些对象列进回收范围之中进行第二次回收。
new SoftReference(Object)(obj);
弱引用：被弱引用关联的对象只能生存到下一次垃圾收集发生位置。
虚引用：为一个对象设置虚引用关联的唯一目的在于跟踪垃圾回收过程。比如：能在这个对象被收集器回收时收到一个系统通知。
垃圾回收算法 对象存活判断 1）引用计算法（Java不用）假设有一个对象A，任何一个对象对A的引用，那么对象A的引用计数器+1，当引用失败 时，对象A的引用计数器就-1，如果对象A的计数器的值为0，就说明对象A没有引用了，可以被回收。
优点：实现简单，垃圾对象便于辨识；判定效率高，回收没有延迟性。
缺点：无法处理循环引用。
可导性分析时，分析工作必须在一个能保障一致性的快照中进行。这也是导致GC进行时必须“Stop The World”的一个重要原因。
标记清除算法，是将垃圾回收分为2个阶段，分别是标记和清除。
标记：从根节点开始标记引用的对象。
清除：未被标记引用的对象就是垃圾对象，可以被清理。
缺点：
1）效率较低，标记和清除两个动作都需要遍历所有的对象，并且在GC时，需要停止应用程序，对于交互性要求比较高的应用而言这个体验是非常差的。
2）通过标记清除算法清理出来的内存，碎片化较为严重，因为被回收的对象可能存在于内存的各个角落，所以清理出来的内存是不连贯的。
清除：清除并不是真的置空，而是把需要清除的对象地址保存在空闲的地址列表里，下次有新对象需要加载时，判断垃圾的位置空间是否够，够就存放。
标记压缩算法（Mark Compact）标记压缩算法是在标记清除算法的基础之上，做了优化改进的算法。和标记清除算法一 样，也是从根节点开始，对对象的引用进行标记，在清理阶段，并不是简单的清理未标 记的对象，而是将存活的对象压缩到内存的一端，然后清理边界以外的垃圾，从而解决了碎片化的问题。
复制算法（Copying）–新生代复制算法的核心就是，将原有的内存空间一分为二，每次只用其中的一块，在垃圾回收 时，将正在使用的对象复制到另一个内存空间中，然后将该内存空间清空，交换两个内存的角色，完成垃圾的回收。
复制算法适用于存活对象少的地方，如果一片区域大部分对象都是存活的，垃圾反而很少，复制过去就不理想。应该是一片区域大部分都是垃圾，小部分是存活的，只需要将小部分复制过去。
分代算法（Generational Collectiing，Java使用）目前几乎所有的GC都是采用分代收集算法执行垃圾回收的。
年轻代(Young Gen)
年轻代特点：区域相对老年代较小，对象生命周期短、存活率低、回收频繁。
这种情况复制算法的回收整理，速度是最快的。复制算法的效率之和当前存活对象大小有关，因此很适用于年轻代的回收。而复制算法内存利用率不高的问题，通过hostpot中的两个survivor的设计得到缓解。老年代(Tenured Gen)老年代特点:区域较大，对象生命周期长、存活率高，回收不及年轻代频繁。这种情况存在大量存活率高的对象，复制算法明显变得不合适。一般是由标记-清除或者标记-清除与标记-整理的混合实现。
CMS是基于标记清除实现的，对于碎片问题，CMS采用基于标记-压缩算法的Serial Old回收器作为补偿措施：当内存回收不佳（碎片导致的Concurrent Mode Failure时），将采用Serial Old执行Full GC以达到对老年代内存的整理。
垃圾回收器 评估GC性能重点关注两点：
1）吞吐量：运行用户代码的时间占总运行时间的比例（总运行时间=程序运行时间+内存回收时间）
2）暂停时间：执行垃圾收集时，程序的工作线程被暂停的时间。
标准：在最大吞吐量优先的情况下，降低停顿时间。
经典的垃圾收集器串行回收器：Serial、Serial Old
并行回收器：ParNew、Parallel Scavenge、Parallel Old
并发回收器：CMS、G1
使用-XX:+PrintCommandLineFlags查看命令行相关参数，其中包含垃圾收集器。
# 第一种方式：打印命令行参数 D:JavaEEJavaEE_2022_0311JVMTestsrc>java -XX:+PrintCommandLineFlags com.studio.Test -XX:InitialHeapSize=265097920 -XX:MaxHeapSize=4241566720 -XX:+PrintCommandLineFlags -XX:+UseCompressedClassPointers -XX:+UseCompressedOops -XX:-UseLargePagesIndividualAllocation -XX:+UseParallelGC # 第二种方式：查看具体的垃圾收集器 D:JavaEEJavaEE_2022_0311JVMTestsrc>jinfo -flag UseParallelGC 57084 -XX:+UseParallelGC D:JavaEEJavaEE_2022_0311JVMTestsrc>jinfo -flag UseParallelOldGC 57084 -XX:+UseParallelOldGC串行垃圾收集器
串行回收默认被应用在客户端的Client模式下的JVM中。
串行垃圾收集器，是指使用单线程进行垃圾回收，垃圾回收时，只有一个线程在工作， 并且java应用中的所有线程都要暂停，等待垃圾回收的完成。这种现象称之为STW（Stop-The-World）。
对于交互性较强的应用而言，这种垃圾收集器是不能够接受的。
一般在Javaweb应用中是不会采用该收集器的。
Serial和Serial Old都是Client模式下默认的垃圾收集器。
新生代：Serial采用复制算法、串行回收和“STW”机制。
老年代：Serial Old采用使用标记-压缩、串行回收和“STW”机制。
SerialOld在Server模式下有两个用途：
① 与新生代的Parallel Scavenge配合使用
② 作为老年代CMS收集器的后备垃圾收集方案
-XX:+UseSerialGC -XX:+PrintCommandLineFlags
添加-XX:+PrintCommandLineFlags打印参数后，程序运行，控制台输出-XX:+UseSerialGC，表示当前新生代和老年代使用的都是串行垃圾收集器。
-XX:InitialHeapSize=16777216 -XX:MaxHeapSize=16777216 -XX:+PrintCommandLineFlags -XX:+PrintGCDetails -XX:+UseCompressedClassPointers -XX:+UseCompressedOops -XX:-UseLargePagesIndividualAllocation -XX:+UseSerialGC第二种方式：jinfo查询
D:JavaEEJavaEE_2022_0311JVMTestsrc>jinfo -flag UseSerialGC 30360 -XX:+UseSerialGC D:JavaEEJavaEE_2022_0311JVMTestsrc>jinfo -flag UseSerialOldGC 30360 no such flag 'UseSerialOldGC'第三种方式：查看GC日志
-XX:+UseSerialGC -XX:+PrintGCDetails -Xms16m -Xmx16m
[GC (Allocation Failure) [DefNew: 4416K->511K(4928K), 0.0032825 secs] 4416K->2392K(15872K), 0.0033229 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
DefNew：表示使用的是串行垃圾收集器。
并行垃圾收集器并行垃圾收集器在串行垃圾收集器的基础之上做了改进，将单线程改为了多线程进行垃圾回收，这样可以缩短垃圾回收的时间。（这里是指，并行能力较强的机器）
并行垃圾收集器在收集的过程中也会暂停应用程序，和串行垃圾回收器一样，只是并行执行，速度更快些，暂停的时间更短一些。
新生代：ParNew回收器
Serial GC是年轻代中的单线程垃圾收集器，ParNew收集器是Serial收集器的多线程版本。
Par是Parallel的缩写，New:只能处理新生代
ParNew收集器除了采用并行回收的方式执行内存回收外，两款垃圾收集器之间几乎没有任何区别。ParNew收集器在年轻代中同样也是采用复制算法、“STW”机制。
对于新生代，回收次数频繁，使用并行方式高效。
对于老年代，回收次数少，使用串行方式节省资源。（CPU并行需要切换线程，串行可以省去切换线程的资源）
注：JDK9以后，ParNew不能搭配SerialOldGC，JDK13的时候，ParNew不能搭配CMS GC，于是ParNew没有可搭配的了。
使用ParNew垃圾回收器-XX:+UseParNewGC表示新生代使用ParNew垃圾收集器，老年代使用串行垃圾收集器。
-XX:+UseParNewGC -XX:+PrintGCDetails -Xms16m -Xmx16m
# ParNew可以和CMS搭配使用，JDK13的时候，ParNew不能再搭配CMS GC -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:+PrintGCDetails -Xms16m -Xmx16m -XX:+PrintCommandLineFlagsParallelGC垃圾收集器（吞吐量优先）
ParallelGC收集器工作机制和ParNewGC收集器一样，只是在此基础之上，新增了两个和 系统吞吐量相关的参数，使得其使用起来更加的灵活和高效。
-XX:+UseParallelGC -XX:+PrintGCDetails -Xms16m -Xmx16m
-XX:+UseParallelOldGC -XX:+PrintGCDetails -Xms16m -Xmx16m
UseParallelGC和UseParallelOldGC这两个参数启动一个，另一个默认启动。
相关参数如下：
-XX:MaxGCPauseMillis 设置最大的垃圾收集时的停顿时间（STW），单位为毫秒，
注意：ParallelGC为了达到设置的停顿时间，可能会调整堆大小或其他的参数，如果堆的大小设置的较小，就会导致GC工作变得很频繁，反而可能会影响到性能。该参数使用需谨慎。
-XX:GCTimeRatio 设置垃圾回收时间占程序运行时间的百分比，公式为1/(1+n)。 它的值为0~100之间的数字，默认值为99，也就是垃圾回收时间不能超过1%。
-XX:UseAdaptiveSizePolicy 自适应GC模式，垃圾回收器将自动调整年轻代、老年代等参数，达到吞吐量、堆大小、停顿时间之间的平衡。一般用于，手动调整参数比较困难的场景，让收集器自动进行调整。
C:Usersuser>jinfo -flag UseAdaptiveSizePolicy 38160 -XX:+UseAdaptiveSizePolicy C:Usersuser>jinfo -flag GCTimeRatio 38160 -XX:GCTimeRatio=99 C:Usersuser>jinfo -flag MaxGCPauseMillis 38160 -XX:MaxGCPauseMillis=18446744073709551615CMS垃圾收集器（低延迟）
CMS全称 Concurrent Mark Sweep，是一款并发的、使用标记-清除算法的垃圾回收器， 该回收器是针对老年代垃圾回收的，通过参数-XX:+UseConcMarkSweepGC进行设置。 CMS垃圾回收器的执行过程如下：
初始化标记(CMS-initial-mark) ,标记root，会导致stw；
并发标记(CMS-concurrent-mark)，与用户线程同时运行；
预清理（CMS-concurrent-preclean），与用户线程同时运行；
重新标记(CMS-remark) ，会导致stw；
并发清除(CMS-concurrent-sweep)，与用户线程同时运行；
调整堆大小，设置CMS在清理之后进行内存压缩，目的是清理内存中的碎片；
并发重置状态等待下次CMS的触发(CMS-concurrent-reset)，与用户线程同时运行；
CMS只能和ParNew、Serial收集器搭配，不能与Parallel搭配。
# JDK8下开启CMS，新生代默认是ParNew收集器 -XX:+UseConcMarkSweepGC -XX:+PrintGCDetails -Xms16m -Xmx16m -XX:+PrintCommandLineFlags
-XX:InitialHeapSize=16777216 -XX:MaxHeapSize=16777216 -XX:MaxNewSize=5595136 -XX:MaxTenuringThreshold=6 -XX:NewSize=5595136 -XX:OldPLABSize=16 -XX:OldSize=11182080 -XX:+PrintCommandLineFlags -XX:+PrintGCDetails -XX:+UseCompressedClassPointers -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC -XX:-UseLargePagesIndividualAllocation -XX:+UseParNewGC
CMS垃圾收集日志
#第一步，初始标记 [GC (CMS Initial Mark) [1 CMS-initial-mark: 7713K(10944K)] 8401K(15872K), 0.0004189 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] #第二步，并发标记 [CMS-concurrent-mark-start] [CMS-concurrent-mark: 0.003/0.003 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] #第三步，预处理 [CMS-concurrent-preclean-start] [CMS-concurrent-preclean: 0.000/0.000 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] #第四步，重新标记 [GC (CMS Final Remark) [YG occupancy: 2367 K (4928 K)][Rescan (parallel) , 0.0003683 secs][weak refs processing, 0.0000078 secs][class unloading, 0.0001505 secs][scrub symbol table, 0.0002457 secs][scrub string table, 0.0000694 secs][1 CMS-remark: 7713K(10944K)] 10080K(15872K), 0.0008829 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] #第五步，并发清理 [CMS-concurrent-sweep-start] [CMS-concurrent-sweep: 0.002/0.002 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] #第六步，重置 [CMS-concurrent-reset-start] [CMS-concurrent-reset: 0.000/0.000 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] [GC (Allocation Failure) [ParNew: 4928K->512K(4928K), 0.0009017 secs] 9781K->6339K(15872K), 0.0009251 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]G1垃圾收集器
G1垃圾收集器是在jdk1.7中正式使用的全新的垃圾收集器，oracle官方计划在jdk9中将 G1变成默认的垃圾收集器，以替代CMS。
G1的设计原则就是简化JVM性能调优，开发人员只需要简单的三步即可完成调优：
- 第一步，开启G1垃圾收集器第二步，设置堆的最大内存第三步，设置最大的停顿时间
G1中提供了三种模式垃圾回收模式，Young GC、Mixed GC 和 Full GC，在不同的条件下被触发。
G1垃圾收集器相对比其他收集器而言，最大的区别在于它取消了年轻代、老年代的物理划分，取而代之的是将堆划分为若干个区域（Region），这些区域中包含了有逻辑上的年轻代、老年代区域。这样做的好处就是，我们再也不用单独的空间对每个代进行设置了，不用担心每个代内存是否足够。
在G1划分的区域中，年轻代的垃圾收集依然采用暂停所有应用线程的方式，将存活对象拷贝到老年代或者Survivor空间，G1收集器通过将对象从一个区域复制到另外一个区域，完成了清理工作。
这就意味着，在正常的处理过程中，G1完成了堆的压缩（至少是部分堆的压缩），这样也就不会有cms内存碎片问题的存在了。
在G1中，有一种特殊的区域，叫Humongous区域。
如果一个对象占用的空间超过了分区容量50%以上，G1收集器就认为这是一个巨型对象。
这些巨型对象，默认直接会被分配在老年代，但是如果它是一个短期存在的巨型对象，就会对垃圾收集器造成负面影响。 为了解决这个问题，G1划分了一个Humongous区，它用来专门存放巨型对象。
如果一个H区装不下一个巨型对象，那么G1会寻找连续的H分区来存储。为了能找到连续的H区，有时候不得不启动Full GC。
Young GC
Young GC主要是对Eden区进行GC，它在Eden空间耗尽时会被触发。
Eden空间的数据移动到Survivor空间中，如果Survivor空间不够，Eden空间的部分数据会直接晋升到年老代空间。
Survivor区的数据移动到新的Survivor区中，也有部分数据晋升到老年代空间中。
最终Eden空间的数据为空，GC停止工作，应用线程继续执行。
Remembered Set（已记忆集合）
在GC年轻代的对象时，我们如何找到年轻代中对象的根对象呢？
根对象可能是在年轻代中，也可以在老年代中，那么老年代中的所有对象都是根么？
如果全量扫描老年代，那么这样扫描下来会耗费大量的时间。
于是，G1引进了RSet的概念。它的全称是Remembered Set，其作用是跟踪指向某个堆内的对象引用。
每个Region初始化时，会初始化一个RSet，该集合用来记录并跟踪其它Region指向该 Region中对象的引用，每个Region默认按照512Kb划分成多个Card，所以RSet需要记录的东西应该是 xx Region的 xx Card。
Mixed GC
当越来越多的对象晋升到老年代old region时，为了避免堆内存被耗尽，虚拟机会触发一个混合的垃圾收集器，即Mixed GC，该算法并不是一个Old GC，除了回收整个Young Region，还会回收一部分的Old Region，这里需要注意：是一部分老年代，而不是全部老年代，可以选择哪些old region进行收集，从而可以对垃圾回收的耗时时间进行控制。
也要注意的是Mixed GC 并不是 Full GC。
MixedGC什么时候触发？ 由参数 -XX:InitiatingHeapOccupancyPercent=n 决定。默认：45%，该参数的意思是：当老年代大小占整个堆大小百分比达到该阀值时触发。
它的GC步骤分2步：
- 全局并发标记（global concurrent marking）拷贝存活对象（evacuation）
全局并发标记
全局并发标记，执行过程分为五个步骤：
初始标记（initial mark，STW） 标记从根节点直接可达的对象，这个阶段会执行一次年轻代GC，会产生全局停顿。
根区域扫描（root region scan）
G1 GC 在初始标记的存活区扫描对老年代的引用，并标记被引用的对象。
该阶段与应用程序（非 STW）同时运行，并且只有完成该阶段后，才能开始下一次 STW 年轻代垃圾回收。
并发标记（Concurrent Marking） G1 GC 在整个堆中查找可访问的（存活的）对象。该阶段与应用程序同时运行， 可以被STW 年轻代垃圾回收中断。
重新标记（Remark，STW） 该阶段是 STW 回收，因为程序在运行，针对上一次的标记进行修正。
清除垃圾（Cleanup，STW） 清点和重置标记状态，该阶段会STW，这个阶段并不会实际上去做垃圾的收集，等待evacuation阶段来回收。
拷贝存活对象
Evacuation阶段是全暂停的。该阶段把一部分Region里的活对象拷贝到另一部分Region中，从而实现垃圾的回收清理。
G1收集器相关参数
-XX:+UseG1GC 使用 G1 垃圾收集器
-XX:MaxGCPauseMillis 设置期望达到的最大GC停顿时间指标（JVM会尽力实现，但不保证达到），默认值是 200 毫秒。
-XX:G1HeapRegionSize=n 设置的 G1区域的大小。值是2的幂，范围是1MB到32MB之间。目标是根据最小的 Java 堆大小划分出约 2048 个区域。默认是堆内存的1/2000。
-XX:ParallelGCThreads=n 设置 STW 工作线程数的值。将n的值设置为逻辑处理器的数量。n的值与逻辑处理器的数量相同，最多为 8。
-XX:ConcGCThreads=n 设置并行标记的线程数。将n设置为并行垃圾回收线程数 (ParallelGCThreads) 的1/4左右。
-XX:InitiatingHeapOccupancyPercent=n 设置触发标记周期的Java堆占用率阈值。默认占用率是整个Java堆的45%。
-XX:+UseG1GC -XX:MaxGCPauseMillis=100 -XX:+PrintGCDetails -Xmx16m
[GC pause (G1 Evacuation Pause) (young), 0.0034820 secs]
[Parallel Time: 1.5 ms, GC Workers: 10]
[GC Worker Start (ms): Min: 103.2, Avg: 103.3, Max: 103.3, Diff: 0.1]
#扫描根节点
[Ext Root Scanning (ms): Min: 0.1, Avg: 0.1, Max: 0.5, Diff: 0.4, Sum: 1.5]
#更新RS区域所消耗的时间
[Update RS (ms): Min: 0.0, Avg: 0.0, Max: 0.0, Diff: 0.0, Sum: 0.0]
[Processed Buffers: Min: 0, Avg: 0.0, Max: 0, Diff: 0, Sum: 0]
[Scan RS (ms): Min: 0.0, Avg: 0.0, Max: 0.0, Diff: 0.0, Sum: 0.0]
[Code Root Scanning (ms): Min: 0.0, Avg: 0.0, Max: 0.0, Diff: 0.0, Sum: 0.0]
#对象拷贝
[Object Copy (ms): Min: 0.4, Avg: 0.7, Max: 0.7, Diff: 0.3, Sum: 6.9]
[Termination (ms): Min: 0.0, Avg: 0.0, Max: 0.0, Diff: 0.0, Sum: 0.0]
[Termination Attempts: Min: 1, Avg: 1.0, Max: 1, Diff: 0, Sum: 10]
[GC Worker Other (ms): Min: 0.0, Avg: 0.0, Max: 0.0, Diff: 0.0, Sum: 0.2]
[GC Worker Total (ms): Min: 0.8, Avg: 0.9, Max: 0.9, Diff: 0.1, Sum: 8.7]
[GC Worker End (ms): Min: 104.1, Avg: 104.1, Max: 104.1, Diff: 0.0]
[Code Root Fixup: 0.0 ms]
[Code Root Purge: 0.0 ms]
[Clear CT: 0.8 ms] #清空CardTable
[Other: 1.2 ms]
[Choose CSet: 0.0 ms] #选取CSet
[Ref Proc: 0.5 ms] #弱引用、软引用的处理耗时
[Ref Enq: 0.0 ms] #弱引用、软引用的入队耗时
[Redirty Cards: 0.6 ms]
[Humongous Register: 0.0 ms] #大对象区域注册耗时
[Humongous Reclaim: 0.0 ms] #大对象区域回收耗时
[Free CSet: 0.0 ms]
#年轻代的大小统计
[Eden: 4096.0K(4096.0K)->0.0B(5120.0K) Survivors: 0.0B->1024.0K Heap: 4096.0K(16.0M)->2312.0K(16.0M)]
[Times: user=0.00 sys=0.00, real=0.00 secs]
对于G1垃圾收集器优化建议
年轻代大小
避免使用 -Xmn 选项或 -XX:NewRatio 等其他相关选项显式设置年轻代大小。
固定年轻代的大小会覆盖暂停时间目标。
暂停时间目标不要太过严苛
G1 GC 的吞吐量目标是 90% 的应用程序时间和 10%的垃圾回收时间。
评估 G1 GC 的吞吐量时，暂停时间目标不要太严苛。目标太过严苛表示您愿意承受更多的垃圾回收开销，而这会直接影响到吞吐量。
