JVM垃圾回收算法&回收器_jvm垃圾回收算法和垃圾回收器-优快云博客

class TestA{
  public TestB b;
}

class TestB{
  public TestA a;
}

public class Main{
    public static void main(String[] args){
        A a = new A();
        B b = new B();
        a.b=b;
        b.a=a;
        a = null; //释放资源
        b = null; //释放资源
    }
}

虽然a和b都为null，但是由于a和b存在循环引用，根据引用的理论，a和b永远都不会被回收。

事实上，以上代码我们在开发中是很可能存在的，我们的jvm也没有被撑爆。因为jvm没有采用这种算法。

那它用的啥呢？

3.2可达性分析

1）概述

通过一系列称为“GC Roots”的根对象作为起始节点集，从这些节点开始，根据引用关系向下搜索，搜索过程所走过的路径称为“引用链”（Reference Chain），如果某个对象到GC Roots间没有任何引用链相连，就说明从GC Roots到这个对象不可达时，则证明此对象是不可能再被使用的，就是可以回收的对象。

JVM用的是这种算法！

2）GC Roots清单

在JVM虚拟机中，可作为GC Roots的对象包括以下几种：

在虚拟机栈（栈帧中的本地变量表）中引用的对象
在方法区中类静态属性引用的对象（类变量）。
在方法区中常量引用的对象，譬如字符串常量池（String Table）里的引用。
在本地方法栈中JNI（即通常所说的Native方法）引用的对象。
所有被同步锁（synchronized关键字）持有的对象。
Java虚拟机内部的引用，如基本数据类型对应的Class对象，一些常驻的异常对象（比如NullPointExcepiton、OutOfMemoryError）等，还有系统类加载器。
反映Java虚拟机内部情况的JMXBean、JVMTI中注册的回调、本地代码缓存等。

3）附：再谈对象的四类引用

在java中，对象的引用主要有4种，从上到下级别依次降低。不同的引用回收的态度不同

强引用
- 在程序代码之中普遍存在的引用赋值，即类似“Object obj=new Object()”这种引用关系。
- 无论任何情况下，内存都不回收，够就够，不够抛内存溢出异常。
软引用
- 用来描述一些还有用，但非必须的对象。被SoftReference包装的那些类
- 先回收没用的对象，收完后发现还不够，再触发二次回收，对软引用对象下手。
弱引用
- 用来描述那些非必须对象，强度比软引用更弱。被WeakReference包装的那些类
- 无论当前内存是否足够，垃圾收集一旦发生，弱引用直接回收。
虚引用（实际开发基本不用）
- 最弱的一种引用关系，一个对象是否有虚引用的存在，完全不会对其生存时间构成影响，也无法通过虚引用来取得一个对象实例。
- 为一个对象设置虚引用关联的唯一目的只是为了能在这个对象被收集器回收时收到一个系统通知。

注意: 即使在可达性分析算法中判定为不可达的对象，也不是非死不可。java给我们提供了拯救方法finalize()。请正确使用此函数，不要使用它去做finally的事情。

回收算法（策略）

回收是做一件事情，要完成这件事，我们需要采用什么样的策略？用什么样的思想会更稳妥？

这就涉及到回收的具体算法

1.标记清除法

1）概述

标记清除算法，是将垃圾回收分为2个阶段，分别是标记和清除。

标记：从根节点开始标记引用的对象。
清除：未被标记引用的对象就是垃圾对象，清理掉。

标记清除法可以说是最基础的收集算法，因为后续的收集算法大多都是以标记-清除算法为基础，对其缺点进行改进而得到的

2）执行过程：

3）缺点：

执行效率较低，标记和清除两个动作都需要遍历所有的对象，并且在GC时，需要停止应用程序，对于交互性要求比较高的应用而言这个体验是非常差的。
通过标记清除算法清理出来的内存，碎片化较为严重，因为被回收的对象可能存在于内存的各个角落，所以清理出来的内存是不连贯的。

2.标记压缩算法

1）概述

也叫标记-整理，标记压缩算法是在标记清除算法的基础之上，做了优化改进的算法。

和标记清除算法一样，也是从根节点开始，对对象的引用进行标记

在清理阶段，并不是简单的清理未标记的对象，而是将存活的对象压缩到内存的一端，然后清理边界以外的垃圾，从而解决了碎片化的问题。

2）执行过程：

3.标记复制算法

1）概述

复制算法的核心就是，将原有的内存空间一分为二，每次只用其中的一块，在垃圾回收时，将正在使用的对象复制到另一个内存空间中，然后将该内存空间清空，交换两个内存的角色，完成垃圾的回收。

2）过程

3）优缺点

优点：

在垃圾对象多的情况下，效率较高，因为要把存活的全部移动一遍
清理后，内存无碎片

缺点：

在垃圾对象比例少的情况下，不适用，如：年轻代这么用可以，老年代就不合适
分配的2块内存空间，在同一个时刻，只能使用一半，内存使用率较低

4）附：年轻代的标记复制算法

年轻代内存的回收就是典型的标记复制法

sruvivor区有两个，一个from，另一个叫to，这俩交替互换角色
在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”区被填满之后，会将所有对象移动到年老代中。

4.分代

1）具体思想

确切的说，分代不算是一种算法，它是一种解决回收问题的思路：具体情况具体分析

在堆内存中，有些对象短暂存活有些则是长久存活，所以需要将堆内存进行分代，将短暂存活的对象放到一起，进行高频率的回收，长久存活的对象集中放到一起，进行低频率的回收

细粒度的控制不同区域，调节不同的回收频率，节约系统资源（回收期间系统要额外干活的！）。

分代算法其实就是这样的，根据回收对象的特点进行选择，在jvm中，年轻代适合使用复制算法，老年代适合使用标记清除或标记压缩算法。

2）相关概念

部分收集（Partial GC）
- 新生代收集（Minor GC/Young GC）：指目标只是新生代的垃圾收集。
- 老年代收集（Major GC/Old GC）：指目标只是老年代的垃圾收集。（CMS收集器）
- 混合收集（Mixed GC）：指目标是收集整个新生代以及部分老年代的垃圾收集。（G1收集器）
整堆收集（Full GC）
- 所有的内存整理一遍，包括堆和方法区。轻易不要触发

回收器（执行者）

前面文章了解了垃圾回收的算法，还需要有具体的实现。

策略有了，谁来执行呢？这事就落到任劳任怨的收集器头上了

在jvm中，实现了多种垃圾收集器，这些收集器种类繁多，看似乱七八糟，其实理清楚后很简单。

1）先明白几件事情

用户线程：java程序运行后，用户不停请求操作jvm内存，这些称为用户线程
GC线程：jvm系统进行垃圾回收启动的线程

串行：GC采用单线程，收集时停掉用户线程
并行：GC采用多线程，收集时同样要停掉用户线程
并发：用户线程和GC线程同步进行，这意义就不一样了

STW：stop the world ，暂停响应用户线程，只提供给GC线程工作来回收垃圾（很不爽的事情）
分代：垃圾收集器是要工作在某个代上的，可能是年轻代，老年代，有的可能两个代都能工作
组合：因为分代，所以得有组合，你懂得……

2）准备案例

在开始前，我们先准备一个内存堆积的案例，下面学习收集器，只需要在启动时指定不同的XX参数即可：

package com.test.jvm;

import java.util.ArrayList;
import java.util.List;
import java.util.Properties;
import java.util.Random;

public class TestGC {

    public static void main(String[] args) throws Exception {
        List<Object> list = new ArrayList<Object>();
        //模拟web中不停请求
        while (true){
            int sleep = new Random().nextInt(100);
          
            if(System.currentTimeMillis() % 2 ==0){
                //模拟释放，如果恰好请求时间是偶数，清空列表
                list.clear();
            }else{
                //模拟业务，从db中查询了10000条记录
                for (int i = 0; i < 10000; i++) {
                    Properties properties = new Properties();
                    properties.put("key_"+i, "value_" + System.currentTimeMillis() + i);
                    list.add(properties);
                }
            }

            System.out.println("list大小为：" + list.size());
          
                        //模拟请求间隔，0-100ms随机
            Thread.sleep(sleep);
        }
    }
}

1.串行

1）概述

其实是两个收集器，年轻代的叫 Serial ，老年代的叫 Serial Old，很好记！

这是最基础的，历史最悠久的收集器。

听名字就知道，这个属于串行收集器，即：GC时，停掉用户线程，同时，GC本身也是只有一个线程在跑

2）原理

很简单，GC时暂停用户进程，新生代 Serial 采用复制算法，Serial Old采用标记整理算法。

3）优缺点

单线程 + STW，那么这个收集器还有存在的价值吗？

答案是：有！我们在吐槽单线程的同时，不要忘了，单线程带来的便捷性

实际上，Serial收集器依然是hotspot在客户端模式下的默认收集器，因为它足够简单有效，没有多线程GC的协调和额外开销，在单核或资源有限的环境下，单线程甚至比多线程还要高效。

而Serial Old则作为下面几款垃圾收集器的兜底措施，比如CMS、G1等处理不了老年代时，他们会自动启用SOld来做FullGC进行收集。

4）配置参数

-XX:+UseSerialGC
- 指定年轻代和老年代都使用串行垃圾收集器
-XX:+PrintGCDetails
- 打印垃圾回收的详细信息

5）操作案例

# 为了测试GC，将堆的初始和最大内存都设置为16M
# java代码使用本节开头的例子
-XX:+UseSerialGC -XX:+PrintGCDetails -Xms16m -Xmx16m

6）启动程序，可以看到下面日志信息：

[GC (Allocation Failure) [DefNew: 4416K->512K(4928K), 0.0046102 secs] 4416K->1973K(15872K), 0.0046533 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 

[Full GC (Allocation Failure) [Tenured: 10944K->3107K(10944K), 0.0085637 secs] 15871K->3107K(15872K), [Metaspace: 3496K->3496K(1056768K)], 0.0085974 secs] [Times: user=0.02 sys=0.00, real=0.01 secs]

DefNew
- 表示使用的是串行垃圾收集器。
4416K->512K (4928K)
- 表示，年轻代GC前，堆内存占有4416K内存，GC后，占有512K内存，总大小4928K
0.0046102 secs
- 表示，GC所用的时间，单位为秒。
4416K->1973K (15872K)
- 表示，GC前，堆内存占有4416K，GC后，占有1973K，总大小为15872K
Full GC
- 表示，内存空间全部进行GC，老年代、元空间

2.并行

1）概述

ParNew收集器：

新生代的，无非就是将Serial的单线程换成多线程，它现在存在的唯一价值就是作为新生代收集器配合老年代的CMS收集器一起工作，并且在jdk9里也已不再推荐这套组合，而是推荐G1。

我们只需要知道的是：曾经，它存在过。
另外一对并行收集器：

Parallel Scavenge （新生代的） / Parallel Old （老年代的）

关于并行收集器，我们重点看Parallel这一对，这一对也是主流的jdk8下默认收集器

2）详解

Parallel这一对，它所关注的是系统的吞吐量。所谓吞吐量，反映的是用户线程在系统整体时间里可用的比例：

即：吞吐量 = 用户代码运行时间 / ( 用户代码运行时间 + 垃圾收集器运行时间 )

这一点，从它的配置参数上直接就能看出来

3）参数

-XX:+UseParallelGC
- 年轻代使用ParallelGC垃圾回收器，老年代使用串行回收器。
-XX:+UseParallelOldGC
- 年轻代使用ParallelGC垃圾回收器，老年代使用ParallelOldGC垃圾回收器。
-XX:MaxGCPauseMillis
- 设置最大的垃圾收集时的停顿时间，单位为毫秒
- 需要注意，ParallelGC为了达到设置的停顿时间，可能会调整堆大小或其他的参数，如果堆的大小设置的较小，就会导致GC工作变得很频繁，反而可能会影响到性能。
- 该参数使用需谨慎。
-XX:GCTimeRatio
- 直接设置垃圾回收时间占程序运行时间的最大百分比，公式为1/(1+n)。
- 它的值为0~100之间的数字，默认值为99，也就是垃圾回收时间不能超过1%
-XX:UseAdaptiveSizePolicy
- 自适应GC模式，垃圾回收器将自动调整年轻代、老年代等参数，达到吞吐量、堆大小、停顿时间之间的平衡。
- 一般用于，手动调整参数比较困难的场景，让收集器自动进行调整，这也是区别于ParNew的一个重要

3）调试

#参数
-XX:+UseParallelGC -XX:+UseParallelOldGC -XX:MaxGCPauseMillis=100 -XX:+PrintGCDetails -Xms16m -Xmx16m

#打印的信息
[GC (Allocation Failure) [PSYoungGen: 4096K->480K(4608K)] 4096K->1840K(15872K), 0.0034307 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 

[Full GC (Ergonomics) [PSYoungGen: 505K->0K(4608K)] [ParOldGen: 10332K->10751K(11264K)] 10837K->10751K(15872K), [Metaspace: 3491K->3491K(1056768K)], 0.0793622 secs] [Times: user=0.13 sys=0.00, real=0.08 secs]

PSYoungGen：年轻代，Parallel Scavenge

ParOldGen：老年代，Parallel Old

3.并发 - CMS

1）简介

CMS(Concurrent Mark Sweep)收集器，工作在老年代。 ParNew

前面的收集器都是要停止用户线程的，而CMS收集器这是真正意义上的并行处理器，也就是用户线程和GC线程在同一时间一起工作。

2）执行过程

初始化标记(CMS-initial-mark) ：标记root直接关联的对象，会导致stw，但是这个没多少对象，时间短
并发标记(CMS-concurrent-mark)：沿着上一步的root，往下追踪，这步耗时最长，但是与用户线程同时运行
重新标记(CMS-remark) ：因为上一步是并发进行的，所以再增量过一遍有变化的，会导致stw，但比上一步少很多
并发清除(CMS-concurrent-sweep)：标记完的干掉，因为是标记-清除算法，不需要移动存活对象，所以这一步与用户线程同时运行
重置线程：重置状态等待下次CMS的触发(CMS-concurrent-reset)，与用户线程同时运行

3）测试

#设置启动参数
-XX:+UseConcMarkSweepGC -XX:+PrintGCDetails -Xms16m -Xmx16m

#运行日志
#注意，cms默认搭配的新生代是 parnew ：
[GC (Allocation Failure) [ParNew: 4926K->512K(4928K), 0.0041843 secs] 9424K->6736K(15872K), 0.0042168 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 

#老年代开始：
#第一步，初始标记
[GC (CMS Initial Mark) [1 CMS-initial-mark: 6224K(10944K)] 6824K(15872K), 0.0004209 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
#第二步，并发标记
[CMS-concurrent-mark-start]
[CMS-concurrent-mark: 0.002/0.002 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: 1657 K (4928 K)][Rescan (parallel) , 0.0005811 secs][weak refs processing, 0.0000136 secs][class unloading, 0.0003671 secs][scrub symbol table, 0.0006813 secs][scrub string table, 0.0001216 secs][1 CMS-remark: 6224K(10944K)] 7881K(15872K), 0.0018324 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
#第五步，并发清理
[CMS-concurrent-sweep-start]
[CMS-concurrent-sweep: 0.004/0.004 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]

由以上日志信息，可以看出CMS执行的过程。

加强参数:

-XX:+UseCMS-CompactAtFullCollection 进行Full GC的时候开启整理，默认开启。

-XX:CMSFullGCsBefore-Compaction 不整理空间的Full GC之后，下次执行整理，默认为0。每次都整理

-XX:CMSInitiatingOccupancyFraction=80 老年代使用达到多少比例后，触发老年代回收

4）优缺点

优点：

不可否认，一款优秀的收集器，并发收集，低停顿。
互联网服务器上低停顿的现实要求很吻合，一个网站总不能告诉用户你用10分钟，歇会再来用。

但是，CMS也不是完美的：

它不能等到内存吃紧了才启动收集。因为收集期间用户线程还在跑，得预留。
浮动垃圾干不掉，在并发标记、并发清理时，产生的新垃圾必须到下一次收集时处理。
标记-清除算法，免不了产生碎片，可以开启压缩但这些参数在jdk9里也已废弃掉
最后，搭配CMS的年轻代现在只剩下了ParNew，是那么的苍白无力。实际上，jdk9开始已经把它逐步淘汰

那么替代它的是谁呢？G1出场……

4.并发 - G1

1）概述

为解决CMS算法产生空间碎片和其它一系列的问题缺陷，G1（Garbage First）算法，在JDK 7u4版本被正式推出

oracle官方计划在jdk9中将G1变成默认的垃圾收集器，以替代CMS。

JDK9默认G1为垃圾收集器的提案：JEP 248: Make G1 the Default Garbage Collector

将CMS标记为丢弃的提案：JEP 291: Deprecate the Concurrent Mark Sweep (CMS) Garbage Collector

G1的设计原则就是简化JVM性能调优，开发人员只需要简单的三步即可完成调优：

第一步，开启G1垃圾收集器
第二步，设置堆的最大内存
第三步，设置最大的停顿时间

2）原理

G1打破了之前的传统观念，它依然把内存划分为eden、survivor、old，同时多了一个humongous（巨大的）区来存巨型对象。

但是，这些区在物理地址上不再连续。而是把整个物理地址分成一个个大小相等的region，每一个region可以是上面角色中的一个，还可以在某个时刻转变角色，从eden变成old ！（就是个标签）

这样收集的时候，它收集某些性价比高的region回收就可以了。所以某个时刻，G1可能连老带少一起收拾。

这是一个划时代的改变！

那它是怎么做的呢？收拾哪些区块呢？

先看两个概念，容易搞混：

Remembered Set：记忆集，简称RS，每个 Region关联一个。RS 比较复杂，简单来说就是记录Region之间对象的引用关系。
Collection Set：简称CSet，在一次收集中，那些性价比高的Region揪出来组成一个回收集，将来一口气回收掉。这个集合里是筛选出来的一些Region

至于Region里面剩下的存活的对象，多个Region压缩到一个空闲Region里去，这样就完成了一次收集。

3）模式

G1中提供了三种模式垃圾回收模式，Young GC、Mixed GC 和 Full GC，在不同的条件下被触发。

所谓的模式，其实也就是G1收集的时候，Region选哪种，是只选年轻代的Region？还是两种都筛选？

Young GC

选定所有年轻代里的Region。通过控制年轻代的region个数，即年轻代内存大小，来控制young GC的时间开销。

Mixed GC

选定所有年轻代里的Region，外加统计的在用户指定的开销目标范围内选择收益高的老年代Region。

full GC

严格意义上讲，这不属于G1的模式。但是使用G1时是有可能发生的。

当mixed GC实在无法跟上程序分配内存的速度，导致老年代填满无法继续进行Mixed GC，就会改为使用serial old GC（full GC）来收集整个堆。

4）运行过程

初始标记：标记出 GC Roots 直接关联的对象，这个阶段速度较快，STW，单线程执行。
并发标记：从 GC Root 开始对堆中的对象进行可达新分析，找出存活对象，这个阶段耗时较长，但可以和用户线程并发执行。
重新标记：修正在并发标记阶段因用户程序执行而产生变动的标记记录。STW，并发执行。
筛选回收：筛选回收阶段会对各个 Region 的回收价值和成本进行排序，根据用户所期望的 GC 停顿时间来制定回收计划，筛出CSet后移动合并存活对象到空Region，清除旧的，完工。因为这个阶段需要移动对象内存地址，所以必须STW。

思考一下，这属于什么算法呢？？？

答：从Region的动作来看G1使用的是标记-复制算法。而在全局视角上，类似标记 - 整理

总结：

G1前面的几步和CMS差不多，只有在最后一步，CMS是标记清除，G1需要合并Region属于标记整理

5）优缺点

并发性：继承了CMS的优点，可以与用户线程并发执行。当然只是在并发标记阶段。其他还是需要STW
分代GC：G1依然是一个分代回收器，但是和之前的各类回收器不同，它同时兼顾年轻代和老年代。而其他回收器，或者工作在年轻代，或者工作在老年代；
空间整理：G1在回收过程中，会进行适当的对象移动，不像CMS只是简单地标记清理对象。在若干次GC后，CMS必须进行一次碎片整理。而G1不同，它每次回收都会有效地复制对象，减少空间碎片，进而提升内部循环速度。
可预见性：为了缩短停顿时间，G1建立可预存停顿的模型，这样在用户设置的停顿时间范围内，G1会选择适当的区域进行收集，确保停顿时间不超过用户指定时间。

6）建议

如果应用程序追求低停顿，可以尝试选择G1；
经验值上，小内存6G以内，CMS优于G1，超过8G，尽量选择G1
是否代替CMS只有需要实际场景测试才知道。（如果使用G1后发现性能还不如CMS，那么还是选择CMS）

7）附：配置参数清单

=======G1 让垃圾回收配置简单很多，只需要打开并指定你预计的时间要求即可=======

指定使用G1收集器：
"-XX:+UseG1GC"

为G1设置暂停时间目标，默认值为200毫秒；这个值不是越小越好。
太小的话会造成可供收集的Region数量偏少，跟不上对象产生的速度，反而会频繁触发GC降低吞吐量
G1会根据这个目标决定收集行为：
"-XX:MaxGCPauseMillis"


=======附：其他参数，一般采用默认即可=======

设置每个Region大小，范围1MB到32MB；目标是在最小Java堆时可以拥有约2048个Region:
"-XX:G1HeapRegionSize"

新生代最小值，默认值5%:
"-XX:G1NewSizePercent"

新生代最大值，默认值60%:
"-XX:G1MaxNewSizePercent"

设置STW期间，并行GC线程数:
"-XX:ParallelGCThreads"

设置并发标记阶段，并行执行的线程数:
"-XX:ConcGCThreads"

当整个Java堆的占用率达到参数值时，开始触发mix gc；默认为45：
"-XX:InitiatingHeapOccupancyPercent"

8）操作案例

-XX:+UseG1GC -XX:MaxGCPauseMillis=100 -XX:+PrintGCDetails -Xmx256m

#G1的日志不像CMS是严格按照事件顺序来的。
#属于分类统计，包含子操作

#总停顿时间
[GC pause (G1 Evacuation Pause) (young), 0.0044882 secs]
     #并发处理耗时，线程数
   [Parallel Time: 3.7 ms, GC Workers: 3]
        #各个子项耗时情况……
      [GC Worker Start (ms): Min: 14763.7, Avg: 14763.8, Max: 14763.8, Diff: 0.1]
      [Ext Root Scanning (ms): Min: 0.2, Avg: 0.3, Max: 0.3, Diff: 0.1, Sum: 0.8]
      [Update RS (ms): Min: 1.8, Avg: 1.9, Max: 1.9, Diff: 0.2, Sum: 5.6]
         [Processed Buffers: Min: 1, Avg: 1.7, Max: 3, Diff: 2, Sum: 5]
      [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: 1.1, Avg: 1.2, Max: 1.3, Diff: 0.2, Sum: 3.6]
      [Termination (ms): Min: 0.0, Avg: 0.1, Max: 0.2, Diff: 0.2, Sum: 0.2]
         [Termination Attempts: Min: 1, Avg: 1.0, Max: 1, Diff: 0, Sum: 3]
      [GC Worker Other (ms): Min: 0.0, Avg: 0.0, Max: 0.0, Diff: 0.0, Sum: 0.0]
      [GC Worker Total (ms): Min: 3.4, Avg: 3.4, Max: 3.5, Diff: 0.1, Sum: 10.3]
      [GC Worker End (ms): Min: 14767.2, Avg: 14767.2, Max: 14767.3, Diff: 0.1]
   [Code Root Fixup: 0.0 ms]
   [Code Root Purge: 0.0 ms]
   [Clear CT: 0.0 ms] 
   [Other: 0.7 ms]
      [Choose CSet: 0.0 ms]
      [Ref Proc: 0.5 ms] 
      [Ref Enq: 0.0 ms] 
      [Redirty Cards: 0.0 ms]
      [Humongous Register: 0.0 ms] 
      [Humongous Reclaim: 0.0 ms] 
      [Free CSet: 0.0 ms]
   #重点：总的各个区的收集情况  收集前使用空间（总空间） -> 收集后使用空间（总空间）
   [Eden: 7168.0K(7168.0K)->0.0B(13.0M) Survivors: 2048.0K->2048.0K Heap: 55.5M(192.0M)->48.5M(192.0M)] 
 [Times: user=0.00 sys=0.00, real=0.00 secs]

总结

1）我们先把所有的收集器做个汇总：

2）一些规律

新生代都是标记 - 复制算法，老年代采用标记 - 整理，或清除（CMS）
历史性的收集器大多针对某个代，但是G1，以及未来的ZGC都是全代可用
没有绝对好用的收集器，需要在吞吐量、延迟性、内存占用量上做权衡
- 数据分析、科学计算等场合，偏重吞吐量
- 互联网服务器、web网站，偏重服务的延迟度，不能出现严重顿挫
- 客户端、微型终端、嵌入式应用，内存占用低是关键

3）搭配组合

除了G1和ZGC这些全能选手，其他垃圾收集器需要搭配工作

但是组合不是想怎么来就怎么来的，下图展示可用组合，以及在某些版本中废弃掉的组合：

4）如何查看当前jdk的垃圾回收器呢？

java -XX:+PrintCommandLineFlags -version

#jdk8，默认Parallel
shawn@macpro:~ > java -XX:+PrintCommandLineFlags -version
-XX:InitialHeapSize=134217728 -XX:MaxHeapSize=2147483648 -XX:+PrintCommandLineFlags -XX:+UseCompressedClassPointers -XX:+UseCompressedOops -XX:+UseParallelGC
java version "1.8.0_181"
Java(TM) SE Runtime Environment (build 1.8.0_181-b13)
Java HotSpot(TM) 64-Bit Server VM (build 25.181-b13, mixed mode)

#jdk11，默认换成了G1
shawn@macpro:~ > java -XX:+PrintCommandLineFlags -version
-XX:G1ConcRefinementThreads=4 -XX:GCDrainStackTargetSize=64 -XX:InitialHeapSize=134217728 -XX:MaxHeapSize=2147483648 -XX:+PrintCommandLineFlags -XX:ReservedCodeCacheSize=251658240 -XX:+SegmentedCodeCache -XX:+UseCompressedClassPointers -XX:+UseCompressedOops -XX:+UseG1GC
java version "11.0.2" 2019-01-15 LTS
Java(TM) SE Runtime Environment 18.9 (build 11.0.2+9-LTS)
Java HotSpot(TM) 64-Bit Server VM 18.9 (build 11.0.2+9-LTS, mixed mode)

#jdk14，默认还是G1，但是已经支持ZGC了，需要打开实验性参数开关
shawn@macpro:~ > java -XX:+PrintCommandLineFlags -version
-XX:G1ConcRefinementThreads=4 -XX:GCDrainStackTargetSize=64 -XX:InitialHeapSize=134217728 -XX:MaxHeapSize=2147483648 -XX:MinHeapSize=6815736 -XX:+PrintCommandLineFlags -XX:ReservedCodeCacheSize=251658240 -XX:+SegmentedCodeCache -XX:+UseCompressedClassPointers -XX:+UseCompressedOops -XX:+UseG1GC
java version "14.0.2" 2020-07-14
Java(TM) SE Runtime Environment (build 14.0.2+12-46)
Java HotSpot(TM) 64-Bit Server VM (build 14.0.2+12-46, mixed mode, sharing)