1. 串行垃圾收集器

串行垃圾收集器，是指使用单线程进行垃圾回收，垃圾回收时，只有一个线程在工作，并且java应用中的所有线程都要暂停，等待垃圾回收的完成。这种现象称之为STW（Stop-The-World）。
对于交互性较强的应用而言，这种垃圾收集器是不能够接受的。
一般在Javaweb应用中是不会采用该收集器的。
Serial是新生代的，Serial Old是老年代的

a. 编写测试代码


public class TestGC {
    //不断的产生新的对象，随机的废弃对象，模拟程序正常运行
    public static void main(String[] args) throws Exception {
        List<Object> list = new ArrayList<Object>();
        while (true){
            int sleep = new Random().nextInt(100);
            if(System.currentTimeMillis() % 2 ==0){
                list.clear();
            }else{
                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());
            Thread.sleep(sleep);
        }
    }
}

b. 设置垃圾回收为串行收集器

在程序运行参数中添加2个参数，如下：

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

为了测试GC，将堆的初始和最大内存都设置为16M

-Dfile.encoding=UTF-8 -XX:+UseSerialGC -XX:+PrintGCDetails -Xms16m -Xmx16m

启动程序，可以看到下面信息：

[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]

GC日志信息解读：

GC后面的括号表示执行GC的原因，Allocation Failure代表申请失败
DefNew表示使用的是串行垃圾收集器
年轻代的内存GC前后的大小：4416K->512K(4928K)
表示年轻代GC前，占有4416K内存，GC后，占有512K内存，总大小4928K
0.0046102 secs表示，GC所用的时间，单位为毫秒。
4416K->1973K(15872K)表示，GC前，堆内存占有4416K，GC后，占有1973K，总大小为15872K
Full GC表示，内存空间全部进行GC
Metaspace代表元空间

2. 并行垃圾收集器（ParNew）

并行垃圾收集器在串行垃圾收集器的基础之上做了改进，将单线程改为了多线程进行垃圾回收，这样可以缩短垃圾回收的时间。（这里是指，并行能力较强的机器）
当然了，并行垃圾收集器在收集的过程中也会暂停应用程序，这个和串行垃圾回收器是一样的，只是并行执行，速度更快些，暂停的时间更短一些。
是service模式下默认的新生代垃圾回收期，因为只有他能与CMS配合工作

ParNew垃圾收集器

ParNew垃圾收集器是工作在年轻代上的，只是将串行的垃圾收集器改为了并行。
通过 -XX:+UseParNewGC 参数设置年轻代使用ParNew回收器，老年代使用的依然是串行收集器。

测试：

#打印出的信息
[GC (Allocation Failure) [ParNew: 4416K‐>512K(4928K), 0.0032106 secs]
4416K‐>1988K(15872K), 0.0032697 secs] [Times: user=0.00 sys=0.00,
real=0.00 secs]

由以上信息可以看出， ParNew: 使用的是ParNew收集器。其他信息和串行收集器一致

3. ParallelGC垃圾收集器(一般使用这个)

是一个新生代和老年代的
ParallelGC收集器工作机制和ParNewGC收集器一样，只是在此基础之上，新增了两个和系统吞吐量相关的参数，使得其使用起来更加的灵活和高效。
主要目的为了达到吞吐量（CPU执行程序的时间如果99s，执行GC1s，吞吐量则为99%）
适用于高效率利用CPU的程序，如后台计算的程序

相关参数如下：

-XX:+UseParallelGC（常用）
年轻代使用ParallelGC垃圾回收器，老年代使用串行回收器。
-XX:+UseParallelOldGC（常用）
年轻代使用ParallelGC垃圾回收器，老年代使用ParallelOldGC垃圾回收器。
-XX:MaxGCPauseMillis（常用）
设置最大的垃圾收集时的停顿时间，单位为毫秒

需要注意的时，ParallelGC为了达到设置的停顿时间，可能会调整堆大小或其他的参数，如果堆的大小设置的较小，就会导致GC工作变得很频繁，反而可能会影响到性能。该参数使用需谨慎。

-XX:GCTimeRatio
设置垃圾回收时间占程序运行时间的百分比，公式为1/(1+n)。
它的值为0~100之间的数字，默认值为99，也就是垃圾回收时间不能超过1%
-XX:UseAdaptiveSizePolicy
自适应GC模式，垃圾回收器将自动调整年轻代、老年代等参数，达到吞吐量、堆大小、停顿时间之间的平衡。

一般用于，手动调整参数比较困难的场景，让收集器自动进行调整。

-Dfile.encoding=UTF-8
-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代表着并行的垃圾收集器

4. CMS垃圾收集器（重点）

CMS全称 Concurrent Mark Sweep，是一款并发的、使用标记-清除算法的垃圾回收器，该回收器是针对老年代垃圾回收的，通过参数-XX:+UseConcMarkSweepGC进行设置。
解决了垃圾收集时的STW，在垃圾回收时，程序可以继续运行
目的：获取最短的STW

CMS垃圾回收器的执行过程如下：

初始化标记(CMS-initial-mark) ,标记root，会导致stw；
并发标记(CMS-concurrent-mark)，与用户线程同时运行；
预清理（CMS-concurrent-preclean），与用户线程同时运行；
重新标记(CMS-remark) ， 会导致stw；（在预处理结束后，可能会产生新的垃圾）
并发清除(CMS-concurrent-sweep)，与用户线程同时运行；
调整堆大小，设置CMS在清理之后进行内存压缩，目的是清理内存中的碎片；
并发重置状态等待下次CMS的触发(CMS-concurrent-reset)，与用户线程同时运行

测试

#运行日志
[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执行的过程。

缺点：

特别依赖CPU资源，如果CPU资源紧张，则会导致GC时间变长，影响吞吐量
无法清除浮动垃圾。在标记完成后，可能又出现了垃圾，导致会触发第二次的Full GC
默认是基于标记-清除算法，会造成碎片化；如果使用标记-整理，会使STW时间变长

5. G1垃圾收集器（重点）

G1垃圾收集器是在jdk1.7中正式使用的全新的垃圾收集器，oracle官方计划在jdk9中将G1变成默认的垃圾收集器，以替代CMS
G1的设计原则就是简化JVM性能调优，开发人员只需要简单的三步即可完成调优：

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

特点

并行与并发。利用CPU多核的来缩短STW的时间
分代收集。对不同代的对象采用不同的垃圾回收策略。
空间整合。综合了复制和标记-整理算法，解决了碎片化。
可预测的停顿。可以让使用者设置在一个时间段内STW的时间
G1中提供了三种模式垃圾回收模式，Young GC、Mixed GC 和 Full GC，在不同的条件下被触发。

原理

加入了Remembered Set，当不同的代发生了引用时，会记录该引用信息。保证了即使不扫描全部的堆也不会有遗漏
会对每个Region计算一个回收价值，价值越大，越先被回收
G1垃圾收集器相对比其他收集器而言，最大的区别在于它取消了年轻代、老年代的物理划分，取而代之的是将堆划分为若干个区域（Region），这些区域中包含了有逻辑上的年轻代、老年代区域。
这样做的好处就是，我们再也不用单独的空间对每个代进行设置了，不用担心每个代内存是否足够。
在G1划分的区域中，年轻代的垃圾收集依然采用暂停所有应用线程的方式，将存活对象拷贝到老年代或者Survivor空间，G1收集器通过将对象从一个区域复制到另外一个区域，完成了清理工作。(复制算法)
这就意味着，在正常的处理过程中，G1完成了堆的压缩（至少是部分堆的压缩），这样也就不会有cms内存碎片问题的存在了。
在G1中，有一种特殊的区域，叫Humongous区域。
如果一个对象占用的空间超过了分区容量50%以上，G1收集器就认为这是一个巨型对象。
这些巨型对象，默认直接会被分配在老年代，但是如果它是一个短期存在的巨型对象，就会对垃圾收集器造成负面影响。
为了解决这个问题，G1划分了一个Humongous区，它用来专门存放巨型对象。如果
一个H区装不下一个巨型对象，那么G1会寻找连续的H分区来存储。为了能找到连续的H区，有时候不得不启动Full GC。

步骤：

初始化标记（STW）
并发标记
最终标记（可能STW）
筛选回收

a. 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。

b. Mixed GC

当越来越多的对象晋升到老年代old region时，为了避免堆内存被耗尽，虚拟机会触发一个混合的垃圾收集器，即Mixed GC，该算法并不是一个Old GC，除了回收整个YoungRegion，还会回收一部分的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）。该阶段与应用程序同时运行，可以被 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 的幂，范围是 1 MB 到 32 MB 之间。目标是根据最小的 Java 堆大小划分出约 2048 个区域。
默认是堆内存的1/2000。(每一个Region的大小)
-XX:ParallelGCThreads=n
设置 STW 工作线程数的值。将 n 的值设置为逻辑处理器的数量。n 的值与逻辑处理器的数量相同，最多为 8。
-XX:ConcGCThreads=n
设置并行标记的线程数。将 n 设置为并行垃圾回收线程数 (ParallelGCThreads)的 1/4 左右。
-XX:InitiatingHeapOccupancyPercent=n
设置触发标记周期的 Java 堆占用率阈值。默认占用率是整个 Java 堆的 45%。

测试

#日志
[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]
#更新RS区域所消耗的时间
[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] #清空CardTable
[Other: 0.7 ms]
[Choose CSet: 0.0 ms] #选取CSet
[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]

c. 对于G1垃圾收集器优化建议

年轻代大小

避免使用 -Xmn 选项或 -XX:NewRatio 等其他相关选项显式设置年轻代大小。
固定年轻代的大小会覆盖暂停时间目标。
因为没有年轻代的概念，而变成了区域的概念

暂停时间目标不要太过严苛

G1 GC 的吞吐量目标是 90% 的应用程序时间和 10%的垃圾回收时间。
评估 G1 GC 的吞吐量时，暂停时间目标不要太严苛。目标太过严苛表示您愿意承受更多的垃圾回收开销，而这会直接影响到吞吐量

可视化GC日志分析工具

前面通过-XX:+PrintGCDetails可以对GC日志进行打印，我们就可以在控制台查看，这样虽然可以查看GC的信息，但是并不直观，可以借助于第三方的GC日志分析工具进行查看。
在日志打印输出涉及到的参数如下

‐XX:+PrintGC 输出GC日志
‐XX:+PrintGCDetails 输出GC的详细日志
‐XX:+PrintGCTimeStamps 输出GC的时间戳（以基准时间的形式）
‐XX:+PrintGCDateStamps 输出GC的时间戳（以日期的形式，如 2013‐05‐
04T21:53:59.234+0800）
‐XX:+PrintHeapAtGC 在进行GC的前后打印出堆的信息
‐Xloggc:…/logs/gc.log 日志文件的输出路径