Java——七种垃圾收集器+JDK11最新ZGC

转自：https://blog.csdn.net/crankz/article/details/86009279#comments

JDK1.8之前的堆内存示意图：

从上图可以看出堆内存的分为新生代、老年代和永久代。新生代又被进一步分为：Eden 区＋Survior1 区＋Survior2 区。值得注意的是，在 JDK 1.8中移除整个永久代，取而代之的是一个叫元空间（Metaspace）的区域（永久代使用的是JVM的堆内存空间，而元空间使用的是物理内存，直接受到本机的物理内存限制）。

JVM为什么要进行垃圾回收？

如果不进行垃圾回收，内存迟早都会被消耗空，因为我们在不断的分配内存空间而不进行回收。除非内存无限大，我们可以任性的分配而不回收，但是事实并非如此。所以，垃圾回收是必须的。
垃圾收集的定义

    GC是垃圾收集的意思（Gabage Collection），Java提供的GC功能可以自动也只能自动地回收堆内存中不再使用的对象，释放资源（目的），Java语言没有提供释放已分配内存的显式操作方法（gc方法只是通知，不是立即执行）。
    对于GC来说，当程序员创建对象时，GC就开始监控这个对象的地址、大小以及使用情况。
    垃圾回收是一种动态存储管理技术，它自动地释放不再被程序引用的对象，当一个对象不再被引用的时候,按照特定的垃圾收集算法来实现资源自动回收的功能。

那什么时候进行垃圾回收呢？

1、第一种场景应该很明显，当年轻代或者老年代满了，Java虚拟机无法再为新的对象分配内存空间了，那么Java虚拟机就会触发一次GC去回收掉那些已经不会再被使用到的对象

2、手动调用System.gc()方法，通常这样会触发一次的Full GC以及至少一次的Minor GC

3、程序运行的时候有一条低优先级的GC线程，它是一条守护线程，当这条线程处于运行状态的时候，自然就触发了一次GC了。这点也很好证明，不过要用到WeakReference的知识，后面写WeakReference的时候会专门讲到这个。
我们可以主动垃圾回收吗？

    每个 Java 应用程序都有一个 Runtime 类实例，使应用程序能够与其运行的环境相连接。可以通过 getRuntime 方法获取当前运行。java.lang.System.gc()只是java.lang.Runtime.getRuntime().gc()的简写，两者的行为没有任何不同。
    唯一的区别就是System.gc()写起来比Runtime.getRuntime().gc()简单点. 其实基本没什么机会用得到这个命令, 因为这个命令只是建议JVM安排GC运行, 还有可能完全被拒绝。 GC本身是会周期性的自动运行的,由JVM决定运行的时机,而且现在的版本有多种更智能的模式可以选择,还会根据运行的机器自动去做选择,就算真的有性能上的需求,也应该去对GC的运行机制进行微调,而不是通过使用这个命令来实现性能的优化。

并行和并发的区别
并行（Parallel）

指多条垃圾收集线程并行工作，但此时用户线程仍然处于等待状态；

如ParNew、Parallel Scavenge、Parallel Old；

    Tips：通过名字就可以看出来，并行的都带有Parallel关键字，ParNew的Par也是Parallel缩写。

并发（Concurrent）

指用户线程与垃圾收集线程同时执行（但不一定是并行的，可能会交替执行）；

用户程序在继续运行，而垃圾收集程序线程运行于另一个CPU上；    

如CMS、G1（也有并行）；
Minor GC和Full GC的区别
Minor GC

    又称新生代GC，指发生在新生代的垃圾收集动作；
    因为Java对象大多是朝生夕灭，所以Minor GC非常频繁，一般回收速度也比较快；

Full GC

    又称老年代GC，指发生在老年代的GC；
    Full GC速度一般比Minor GC慢10倍以上；

吞吐量（Throughput）

吞吐量就是CPU用于运行用户代码的时间与CPU总消耗时间的比值，即

吞吐量 = 运行用户代码时间 /（运行用户代码时间 + 垃圾收集时间）。

假设虚拟机总共运行了100分钟，其中垃圾收集花掉1分钟，那吞吐量就是99%。
四种引用

Java 中的垃圾回收一般是在 Java 堆中进行，因为堆中几乎存放了 Java 中所有的对象实例。谈到 Java 堆中的垃圾回收，自然要谈到引用。在 JDK1.2 之后，Java 对引用的概念进行了扩充，将其分为强引用（Strong Reference）、软引用（Soft Reference）、弱引用（Weak Reference）、虚引用（Phantom Reference）四种，引用强度依次减弱。
有强到弱分为

    强引用(Strong Reference)
    软引用(Soft Reference)
    弱引用(Weak Reference)
    虚引用(Phantom Reference)

强引用（Strong Reference）

如“Object obj = new Object（）”，这类引用是 Java 程序中最普遍的。只要强引用还存在，垃圾收集器就永远不会回收掉被引用的对象。
强引用具备以下三个个特点：

    强引用可以直接访问目标对象；
    强引用所指向的对象在任何时候都不会被系统回收。JVM宁愿抛出OOM异常也不回收强引用所指向的对象；
    强引用可能导致内存泄露；

软引用（Soft Reference）

是用来描述一些还有用但并非必须的对象。对于软引用关联着的对象，在系统将要发生内存溢出异常之前，将会把这些对象列进回收范围之中进行第二次回收。如果这次回收还没有足够的内存，才会抛出内存溢出异常。在 JDK 1.2 之后，提供了 SoftReference 类来实现软引用。
弱引用(Weak Reference)

用来描述非必须的对象，但是它的强度比软引用更弱一些，被弱引用关联的对象只能生存到下一次垃圾收集发送之前。当垃圾收集器工作时，无论当前内存是否足够，都会回收掉只被弱引用关联的对象。一旦一个弱引用对象被垃圾回收器回收，便会加入到一个注册引用队列中。在 JDK 1.2 之后，提供了 WeakReference类来实现弱引用。

Tips：软引用、弱引用都非常适合来保存那些可有可无的缓存数据。如果这么做，当系统内存不足时，这些缓存数据会被回收，不会导致内存溢出。而当内存资源充足时，这些缓存数据又可以存在相当长的时间，从而起到加速系统的作用。
虚引用(Phantom Reference)

它是最弱的一种引用关系。一个持有虚引用的对象，和没有引用几乎是一样的，随时都有可能被垃圾回收器回收。当试图通过虚引用的get()方法取得强引用时，总是会失败。并且，虚引用必须和引用队列一起使用，它的作用在于跟踪垃圾回收过程。在 JDK 1.2 之后，提供了 PhantomReference类来实现虚引用。
Stop-The-World

GC在后台自动发起和自动完成的，在用户不可见的情况下，把用户正常的工作线程全部停掉，即GC停顿，会带给用户不良的体验；
为什么要Stop-The-World

可达性分析的时候为了确保快照的一致性，需要对整个系统进行冻结，不可以出现分析过程中对象引用关系还在不断变化的情况，也就是Stop-The-World。

Stop-The-World是导致GC卡顿的重要原因之一。
举个例子：

你在做家务，正在计算家里有多少垃圾的时候，是不能允许别人在这时候清理或者增加垃圾的，否则你的计算将毫无意义。所以在这个时候，你需要把家里的人都关在门外，等你计算好垃圾的数量之后才能让他们进来。
查看垃圾回收器

    我们知道JVM分Client 和 Server模式。
    如果启动JVM不指定模式，JDK会根据当前的操作系统配置来启动不同模式的JVM。
    默认64bit操作系统下都会是Server模式的JVM。

# java -XX: +PrintCommandLineFlags –version

垃圾收集器

JVM是一个进程，垃圾收集器就是一个线程，垃圾收集线程是一个守护线程，优先级低，其在当前系统空闲或堆中老年代占用率较大时触发。

JDK7/8后，HotSpot虚拟机所有收集器及组合（连线），如下图：

图中展示了7种不同分代的收集器：

    Serial
    ParNew （Serial的升级版，多线程）
    Parallel Scavenge
    Serial Old
    Parallel Old
    CMS
    G1

新生代收集器还是老年代收集器：

    新生代收集器：Serial、ParNew、Parallel Scavenge；
    老年代收集器：Serial Old、Parallel Old、CMS；
    整堆收集器：G1

吞吐量优先、停顿时间优先

    吞吐量优先：Parallel Scavenge收集器、Parallel Old 收集器。
    停顿时间优先：CMS（Concurrent Mark-Sweep）收集器。

吞吐量与停顿时间适用场景

    停顿时间优先：交互多，对响应速度要求高
    吞吐量优先：交互少，计算多，适合在后台运算的场景。

串行并行并发

    串行：Serial、Serial Old
    并行：ParNew、Parallel Scavenge、Parallel Old
    并发：CMS、G1

算法

    复制算法：Serial、ParNew、Parallel Scavenge、G1
    标记-清除：CMS
    标记-整理：Serial Old、Parallel Old、G1

1、Serial收集器

Serial（串行）垃圾收集器是最基本、发展历史最悠久的收集器；

JDK1.3.1前是HotSpot新生代收集的唯一选择；
特点

    针对新生代
    串行
    复制算法
    单线程一方面意味着它只会使用一个CPU或一条线程去完成垃圾收集工作，
    另一方面也意味着在它进行垃圾收集时，必须暂停其他所有的工作线程，直到它收集结束为止，这个过程也称为 Stop The world。
    后者意味着，在用户不可见的情况下要把用户正常工作的线程全部停掉，这显然对很多应用是难以接受的。

应用场景

对于限定单个CPU的环境来说，Serial收集器由于没有线程交互的开销，专心做垃圾收集自然可以获得最高的单线程收集效率。

Serial收集器依然是虚拟机运行在Client模式下的默认新生代收集器。 在用户的桌面应用场景中，可用内存一般不大（几十M至一两百M），可以在较短时间内完成垃圾收集（几十MS至一百多MS）,只要不频繁发生，这是可以接受的

    Tips：Stop the World是在用户不可见的情况下执行的，会造成某些应用响应变慢；

    Tips：因为新生代的特点是对象存活率低，所以收集算法用的是复制算法，把新生代存活对象复制到老年代，复制的内容不多，性能较好。

    Tips：单线程地好处就是减少上下文切换，减少系统资源的开销。但这种方式的缺点也很明显，在GC的过程中，会暂停程序的执行。若GC不是频繁发生，这或许是一个不错的选择，否则将会影响程序的执行性能。 对于新生代来说，区域比较小，停顿时间短，所以比较使用。

参数

    -XX:+UseSerialGC：串联收集器

    Tips：在JDK Client模式，不指定VM参数，默认是串行垃圾回收器

2、ParNew收集器

 

ParNew收集器就是Serial收集器的多线程版本，它也是一个新生代收集器。除了使用多线程进行垃圾收集外，其余行为包括Serial收集器可用的所有控制参数、收集算法（复制算法）、Stop The World、对象分配规则、回收策略等与Serial收集器完全相同，两者共用了相当多的代码。

ParNew收集器的工作过程如下图：

ParNew收集器除了使用多线程收集外，其他与Serial收集器相比并无太多创新之处，但它却是许多运行在Server模式下的虚拟机中首选的新生代收集器，其中有一个与性能无关的重要原因是，除了Serial收集器外，目前只有它能和CMS收集器（Concurrent Mark Sweep）配合工作，CMS收集器是JDK 1.5推出的一个具有划时代意义的收集器，具体内容将在稍后进行介绍。

ParNew 收集器在单CPU的环境中绝对不会有比Serial收集器有更好的效果，甚至由于存在线程交互的开销，该收集器在通过超线程技术实现的两个CPU的环境中都不能百分之百地保证可以超越。在多CPU环境下，随着CPU的数量增加，它对于GC时系统资源的有效利用是很有好处的。
特点

ParNew收集器其实就是Serial收集器的多线程版本，除了使用多条线程进行垃圾收集外，其余行为和Serial收集器完全一样，包括Serial收集器可用的所有控制参数、收集算法、Stop The world、对象分配规则、回收策略等都一样。在实现上也共用了相当多的代码。

    针对新生代
    复制算法
    串行
    多线程
    GC时需要暂停所有用户线程，直到GC结束
    Serial多线程版本，其他特点与Serial相同

应用场景

ParNew收集器是许多运行在Server模式下的虚拟机中首选的新生代收集器。很重要的原因是：除了Serial收集器之外，目前只有它能与CMS收集器配合工作（看图）。在JDK1.5时期，HotSpot推出了一款几乎可以认为具有划时代意义的垃圾收集器-----CMS收集器，这款收集器是HotSpot虚拟机中第一款真正意义上的并发收集器，它第一次实现了让垃圾收集线程与用户线程同时工作。
参数

    "-XX:+UseConcMarkSweepGC"：指定使用CMS后，会默认使用ParNew作为新生代收集器；
    "-XX:+UseParNewGC"：强制指定使用ParNew；    
    "-XX:ParallelGCThreads"：指定垃圾收集的线程数量，ParNew默认开启的收集线程与CPU的数量相同；

为什么只有ParNew能与CMS收集器配合

CMS是HotSpot在JDK1.5推出的第一款真正意义上的并发（Concurrent）收集器，第一次实现了让垃圾收集线程与用户线程（基本上）同时工作；

CMS作为老年代收集器，但却无法与JDK1.4已经存在的新生代收集器Parallel Scavenge配合工作；

因为Parallel Scavenge（以及G1）都没有使用传统的GC收集器代码框架，而另外独立实现；而其余几种收集器则共用了部分的框架代码；
3、Parallel Scavenge收集器

Parallel Scavenge收集器和ParNew类似，新生代的收集器，同样用的是复制算法，也是并行多线程收集。与ParNew最大的不同，它关注的是垃圾回收的吞吐量。
特点

    针对新生代
    复制算法
    并行
    多线程
    高吞吐量为目标

应用场景

Parallel Scavenge收集器是虚拟机运行在Server模式下的默认垃圾收集器。

高吞吐量为目标，即减少垃圾收集时间，让用户代码获得更长的运行时间；适合那种交互少、运算多的场景

例如，那些执行批量处理、订单处理、工资支付、科学计算的应用程序；
参数

    "-XX:+MaxGCPauseMillis"：控制最大垃圾收集停顿时间，大于0的毫秒数；这个参数设置的越小，停顿时间可能会缩短，但也会导致吞吐量下降，导致垃圾收集发生得更频繁。
    "-XX:GCTimeRatio"：设置垃圾收集时间占总时间的比率，0<n<100的整数，就相当于设置吞吐量的大小。

    先垃圾收集执行时间占应用程序执行时间的比例的计算方法是：
    1 / (1 + n)
    例如，选项-XX:GCTimeRatio=19，设置了垃圾收集时间占总时间的5%=1/(1+19)；
    默认值是1%--1/(1+99)，即n=99；
    垃圾收集所花费的时间是年轻一代和老年代收集的总时间；

此外，还有一个值得关注的参数：

"-XX:+UseAdptiveSizePolicy"

开启这个参数后，就不用手工指定一些细节参数，如：

新生代的大小（-Xmn）、Eden与Survivor区的比例（-XX:SurvivorRation）、晋升老年代的对象年龄（-XX:PretenureSizeThreshold）等；

JVM会根据当前系统运行情况收集性能监控信息，动态调整这些参数，以提供最合适的停顿时间或最大的吞吐量，这种调节方式称为GC自适应的调节策略（GC Ergonomiscs）；    

另外值得注意的一点是，Parallel Scavenge收集器无法与CMS收集器配合使用，所以在JDK 1.6推出Parallel Old之前，如果新生代选择Parallel Scavenge收集器，老年代只有Serial Old收集器能与之配合使用。
Parallel Scavenge收集器 VS CMS等收集器：

Parallel Scavenge收集器的特点是它的关注点与其他收集器不同，CMS等收集器的关注点是尽可能地缩短垃圾收集时用户线程的停顿时间，而Parallel Scavenge收集器的目标则是达到一个可控制的吞吐量（Throughput）。
由于与吞吐量关系密切，Parallel Scavenge收集器也经常称为“吞吐量优先”收集器。
Parallel Scavenge收集器 VS ParNew收集器：

Parallel Scavenge收集器与ParNew收集器的一个重要区别是它具有自适应调节策略。
4、Serial Old收集器(标记-整理算法)

Serial收集器的工作流程如下图：

如上图所示，Serial 收集器在新生代和老年代都有对应的版本，除了收集算法不同，两个版本并没有其他差异。

    Serial 新生代收集器采用的是复制算法。
    Serial Old 老年代采用的是标记 - 整理算法。

特性

    Serial Old是Serial的老年代版本，
    除了采用标记-整理算法，其他与Serial相同

应用场景

        Client模式
        Serial Old收集器的主要意义也是在于给Client模式下的虚拟机使用。
        Server模式
        如果在Server模式下，那么它主要还有两大用途：一种用途是在JDK 1.5以及之前的版本中与Parallel Scavenge收集器搭配使用；另一种用途就是作为CMS收集器的后备预案，在并发收集发生"Concurrent Mode Failure"时使用。

5、Parallel Old收集器

如上图所示，Parallel 收集器在新生代和老年代也都有对应的版本，除了收集算法不同，两个版本并没有其他差异。

Parallel Scavenge收集器的老年代版本，并行收集器，吞吐量优先

Parallel Old收集器是Parallel Scavenge收集器的老年版本，它也使用多线程和“标记-整理”算法。这个收集器是在JDK 1.6开始提供。

Mark-Compact
特点

    Parallel Old是Parallel Scavenge的老年代版本
    Parallel Old 老年代采用的是标记 - 整理算法，其他特点与Parallel Scavenge相同

使用场景

    在注重吞吐量以及CPU资源敏感的场合，都可以优先考虑Parallel Scavenge加Parallel Old收集器组合。
    JDK1.6及之后用来代替老年代的Serial Old收集器；
    特别是在Server模式，多CPU的情况下；

参数

    -XX:+UseParallelOldGC：指定使用Parallel Old收集器；

6、CMS(Concurrent Mark Sweep)收集器
概述

    CMS是HotSpot在JDK5推出的第一款真正意义上的并发（Concurrent）收集器，第一次实现了让垃圾收集线程与用户线程（基本上）同时工作；
    命名中用的是concurrent，而不是parallel，说明这个收集器是有与工作执行并发的能力的。MS则说明算法用的是Mark Sweep算法。
    它关注的是垃圾回收最短的停顿时间（低停顿），在老年代并不频繁GC的场景下，是比较适用的。

特点

    针对老年代
    标记-清除算法 (不进行压缩操作，产生内存碎片)；
    并发
    多线程
    收集过程中不需要暂停用户线程
    以获取最短回收停顿时间为目标

应用场景

与用户交互较多的场景。CMS 收集器是一种以获取最短回收停顿时间为目标的收集器。目前很大一部分的Java应用集中在互联网或者B/S系统的服务端上，这类应用尤其注重服务的响应速度，希望系统停顿时间最短，以给用户带来极好的体验。CMS收集器就非常符合这类应用的需求。

CMS是一种以获取最短回收停顿时间为目标的收集器。在重视响应速度和用户体验的应用中，CMS应用很多。
CMS GC过程分四步完成：

比前面几种收集器更复杂，可以分为4个步骤:
1、初始标记（initial mark）

    单线程执行
    需要“Stop The World”
    但仅仅把GC Roots的直接关联可达的对象给标记一下，由于直接关联对象比较小，所以这里的速度非常快

2、并发标记（concurrent mark）

    对于初始标记过程所标记的初始标记对象，进行并发追踪标记，
    此时其他线程仍可以继续工作。
    此处时间较长，但不停顿。
    并不能保证可以标记出所有的存活对象；

3、重新标记（remark）

    在并发标记的过程中，由于可能还会产生新的垃圾，所以此时需要重新标记新产生的垃圾。
    此处执行并行标记，与用户线程不并发，所以依然是“Stop The World”，
    且停顿时间比初始标记稍长，但远比并发标记短。

4、并发清除（concurrent sweep）

    并发清除之前所标记的垃圾。
    其他用户线程仍可以工作，不需要停顿。

    Tips：其中，初始标记和并发标记仍然需要Stop the World、初始标记仅仅标记一下GC Roots能直接关联到的对象，速度很快，并发标记就是进行GC RootsTracing的过程，而重新标记阶段则是为了修正并发标记期间因用户程序继续运行而导致标记产生变动的那一部分对象的标记记录，这个阶段的停顿时间一般会比初始标记阶段长，但远比并发标记的时间短。

    由于整个过程中耗时最长的并发标记和并发清除过程收集器线程都可以与用户线程一起工作，所以整体上说，CMS收集器的内存回收过程是与用户线程一共并发执行的。

参数

    -XX:+UseConcMarkSweepGC：使用CMS收集器
    -XX:+ UseCMSCompactAtFullCollection：Full GC后，进行一次碎片整理；整理过程是独占的，会引起停顿时间变长
    -XX:+CMSFullGCsBeforeCompaction：设置进行几次Full GC后，进行一次碎片整理
    -XX:ParallelCMSThreads：设定CMS的线程数量（一般情况约等于可用CPU数量）

缺点

总体来看，与Parallel Old垃圾收集器相比，CMS减少了执行老年代垃圾收集时应用暂停的时间；

但却增加了新生代垃圾收集时应用暂停的时间、降低了吞吐量而且需要占用更大的堆空间；

由于最耗费时间的并发标记与并发清除阶段都不需要暂停工作，所以整体的回收是低停顿的。

由于CMS以上特性，缺点也是比较明显的，
1、对CPU资源非常敏感

对CPU资源非常敏感 其实，面向并发设计的程序都对CPU资源比较敏感。

在并发阶段，它虽然不会导致用户线程停顿，但会因为占用了一部分线程（或者说CPU资源）而导致应用程序变慢，总吞吐量会降低。

CMS默认启动的回收线程数是（CPU数量+3）/4，也就是当CPU在4个以上时，并发回收时垃圾收集线程不少于25%的CPU资源，并且随着CPU数量的增加而下降。

但是当CPU不足4个时（比如2个），CMS对用户程序的影响就可能变得很大，如果本来CPU负载就比较大，还要分出一半的运算能力去执行收集器线程，就可能导致用户程序的执行速度忽然降低了50%，其实也让人无法接受。

并发收集虽然不会暂停用户线程，但因为占用一部分CPU资源，还是会导致应用程序变慢，总吞吐量降低。

CMS的默认收集线程数量是=(CPU数量+3)/4；

当CPU数量多于4个，收集线程占用的CPU资源多于25%，对用户程序影响可能较大；不足4个时，影响更大，可能无法接受。
2、浮动垃圾（Floating Garbage）

由于CMS并发清理阶段用户线程还在运行着，伴随程序运行自然就还会有新的垃圾不断产生，这一部分垃圾出现在标记过程之后，CMS无法在当次收集中处理掉它们，只好留待下一次GC时再清理掉。这一部分垃圾就称为“浮动垃圾”。

由于在垃圾收集阶段用户线程还需要运行，那就还需要预留有足够的内存空间给用户线程使用，因此CMS收集器不能像其他收集器那样等到老年代几乎完全被填满了再进行收集，也可以热为CMS所需要的空间比其他垃圾收集器大；

      "-XX:CMSInitiatingOccupancyFraction"：设置CMS预留内存空间；

      JDK1.5默认值为68%；

      JDK1.6变为大约92%；
3、"Concurrent Mode Failure"失败

如果CMS运行期间预留的内存无法满足程序需要，就会出现一次“Concurrent Mode Failure”失败，这时虚拟机将启动后备预案：临时启用Serial Old收集器来重新进行老年代的垃圾收集，这样会导致另一次Full GC的产生。这样停顿时间就更长了，代价会更大，所以 "-XX:CMSInitiatingOccupancyFraction"不能设置得太大。
4、产生大量内存碎片

这个问题并不是CMS的问题，而是算法的问题。由于CMS基于"标记-清除"算法，清除后不进行压缩操作，所以会产生碎片

"标记-清除"算法介绍时曾说过：

产生大量不连续的内存碎片会导致分配大内存对象时，无法找到足够的连续内存，从而需要提前触发另一次Full GC动作。
4.1碎片解决方法：

（1）、"-XX:+UseCMSCompactAtFullCollection"

      使得CMS出现上面这种情况时不进行Full GC，而开启内存碎片的合并整理过程；

      但合并整理过程无法并发，停顿时间会变长；

      默认开启（但不会进行，结合下面的CMSFullGCsBeforeCompaction）；

（2）、"-XX:+CMSFullGCsBeforeCompaction"

      设置执行多少次不压缩的Full GC后，来一次压缩整理；

      为减少合并整理过程的停顿时间；

      默认为0，也就是说每次都执行Full GC，不会进行压缩整理；

      由于空间不再连续，CMS需要使用可用"空闲列表"内存分配方式，这比简单实用"碰撞指针"分配内存消耗大；
7、G1收集器
概述

    G1（Garbage - First）名称的由来是G1跟踪各个Region里面的垃圾堆的价值大小（回收所获得的空间大小以及回收所需时间的经验值），在后台维护一个优先列表，每次根据允许的收集时间，优先回收价值最大的Region。
    G1（Garbage-First）是JDK7-u4才推出商用的收集器；

    注意：G1与前面的垃圾收集器有很大不同，它把新生代、老年代的划分取消了！

这样我们再也不用单独的空间对每个代进行设置了，不用担心每个代内存是否足够。

取而代之的是，G1算法将堆划分为若干个区域（Region），它仍然属于分代收集器。不过，这些区域的一部分包含新生代，新生代的垃圾收集依然采用暂停所有应用线程的方式，将存活对象拷贝到老年代或者Survivor空间。老年代也分成很多区域，G1收集器通过将对象从一个区域复制到另外一个区域，完成了清理工作。这就意味着，在正常的处理过程中，G1完成了堆的压缩（至少是部分堆的压缩），这样也就不会有CMS内存碎片问题的存在了。

在G1中，还有一种特殊的区域，叫Humongous区域。 如果一个对象占用的空间超过了分区容量50%以上，G1收集器就认为这是一个巨型对象。这些巨型对象，默认直接会被分配在年老代，但是如果它是一个短期存在的巨型对象，就会对垃圾收集器造成负面影响。为了解决这个问题，G1划分了一个Humongous区，它用来专门存放巨型对象。如果一个H区装不下一个巨型对象，那么G1会寻找连续的H分区来存储。为了能找到连续的H区，有时候不得不启动Full GC。

PS：在java 8中，持久代也移动到了普通的堆内存空间中，改为元空间。
特点

G1除了降低停顿外，还能建立可预测的停顿时间模型；
1、Region概念

    横跨整个堆内存
    在G1之前的其他收集器进行收集的范围都是整个新生代或者老生代，而G1不再是这样。
    G1在使用时，Java堆的内存布局与其他收集器有很大区别，
    它将整个Java堆划分为多个大小相等的独立区域（Region），
    虽然还保留新生代和老年代的概念，但新生代和老年代不再是物理隔离的了，而都是一部分Region（可以不连续）的集合。

2、可并行，可并发

能充分利用多CPU、多核环境下的硬件优势；

G1 能充分利用多CPU、多核环境下的硬件优势，使用多个CPU来缩短“Stop The World”停顿时间

并行：使用多个CPU来缩短Stop-The-World停顿的时间，

并发：也可以并发让垃圾收集与用户程序同时进行
3、分代收集，收集范围包括新生代和老年代

    能独立管理整个GC堆（新生代和老年代），而不需要与其他收集器搭配；
    能够采用不同方式处理不同时期的对象；

4、空间整合，不产生碎片

    从整体看，是基于标记-整理算法；
    从局部（两个Region间）看，是基于复制算法；
    都不会产生内存碎片，有利于长时间运行；
    这种特性有利于程序长时间运行，分配大对象时不会因为无法找到连续内存空间而提前触发下一次GC。

5、可预测的停顿：低停顿的同时实现高吞吐量

    G1收集器之所以能建立可预测的停顿时间模型，是因为它可以有计划地避免在整个Java堆中进行全区域的垃圾收集。
    G1跟踪各个Region里面的垃圾堆积的价值大小（回收所获得的空间大小以及回收所需时间的经验值），在后台维护一个优先列表，
    每次根据允许的收集时间，优先回收价值最大的Region，这样就保证了在有限的时间内尽可能提高效率。（这也就是Garbage-First名称的来由）。
    这种使用Region划分内存空间以及有优先级的区域回收方式，保证了G1收集器在有限的时间内可以获取尽可能高的收集效率。

应用场景

如果你的应用追求低停顿，那G1现在已经可以作为一个可尝试选择，如果你的应用追求吞吐量，那G1并不会为你带来什么特别的好处。

1.面向服务端应用，针对具有大内存、多处理器的机器；最主要的应用是为需要低GC延迟，并具有大堆的应用程序提供解决方案；
如：在堆大小约6GB或更大时，可预测的暂停时间可以低于0.5秒；
2.用来替换掉JDK1.5的CMS收集器；
（1）、超过50%的Java堆被活动数据占用；
（2）、对象分配频率或年代提升频率变化很大；
（3）、GC停顿时间过长（长与0.5至1秒）。
参数

    "-XX:+UseG1GC"：指定使用G1收集器；
    "-XX:InitiatingHeapOccupancyPercent"：当整个Java堆的占用率达到参数值时，开始并发标记阶段；默认为45；
    "-XX:MaxGCPauseMillis"：为G1设置暂停时间目标，默认值为200毫秒；
    "-XX:G1HeapRegionSize"：设置每个Region大小，范围1MB到32MB；目标是在最小Java堆时可以拥有约2048个Region；

为什么G1收集器可以实现可预测的停顿？

G1可以建立可预测的停顿时间模型，是因为：

可以有计划地避免在Java堆的进行全区域的垃圾收集；

G1跟踪各个Region获得其收集价值大小，在后台维护一个优先列表；

每次根据允许的收集时间，优先回收价值最大的Region（名称Garbage-First的由来）；

这就保证了在有限的时间内可以获取尽可能高的收集效率；
G1收集器运作过程

不计算维护Remembered Set的操作，可以分为4个步骤（与CMS较为相似）。
1、初始标记（Initial Marking）

    初始标记仅仅只是标记一下GC Roots能直接关联到的对象，
    速度很快，
    需要“Stop The World”。（OopMap）

2、并发标记（Concurrent Marking）

    进行GC Roots Tracing的过程，从刚才产生的集合中标记出存活对象；（也就是从GC Roots 开始对堆进行可达性分析，找出存活对象。）
    耗时较长，但应用程序也在运行；
    并不能保证可以标记出所有的存活对象；

3、最终标记（Final Marking）

    最终标记和CMS的重新标记阶段一样，也是为了修正并发标记期间因用户程序继续运作而导致标记产生变动的那一部分对象的标记记录，
    这个阶段的停顿时间一般会比初始标记阶段稍长一些，但远比并发标记的时间短，
    也需要“Stop The World”。（修正Remebered Set）

4、筛选回收（Live Data Counting and Evacuation）

    首先排序各个Region的回收价值和成本；
    然后根据用户期望的GC停顿时间来制定回收计划；
    最后按计划回收一些价值高的Region中垃圾对象；
    回收时采用"复制"算法，从一个或多个Region复制存活对象到堆上的另一个空的Region，并且在此过程中压缩和释放内存；
    可以并发进行，降低停顿时间，并增加吞吐量；

参数

    "-XX:+UseG1GC"：指定使用G1收集器；
    "-XX:InitiatingHeapOccupancyPercent"：当整个Java堆的占用率达到参数值时，开始并发标记阶段；默认为45；
    "-XX:MaxGCPauseMillis"：为G1设置暂停时间目标，默认值为200毫秒；
    "-XX:G1HeapRegionSize"：设置每个Region大小，范围1MB到32MB；目标是在最小Java堆时可以拥有约2048个

总结

图中展示了7种作用于不同分代的收集器，如果两个收集器之间存在连线，就说明它们可以搭配使用。

虚拟机所处的区域，则表示它是属于新生代收集器还是老年代收集器。
收集器总结

 

参数总结

 

ZGC
概述

在JDK 11当中，加入了实验性质的ZGC。它的回收耗时平均不到2毫秒。它是一款低停顿高并发的收集器。

ZGC几乎在所有地方并发执行的，除了初始标记的是STW的。所以停顿时间几乎就耗费在初始标记上，这部分的实际是非常少的。那么其他阶段是怎么做到可以并发执行的呢？

ZGC主要新增了两项技术，一个是着色指针Colored Pointer，另一个是读屏障Load Barrier。

ZGC 是一个并发、基于区域（region）、增量式压缩的收集器。Stop-The-World 阶段只会在根对象扫描（root scanning）阶段发生，这样的话 GC 暂停时间并不会随着堆和存活对象的数量而增加。
ZGC 的设计目标

    TB 级别的堆内存管理；
    最大 GC Pause 不高于 10ms；
    最大的吞吐率（Throughput）损耗不高于 15%；

关键点：GC Pause 不会随着 堆大小的增加 而增大。
ZGC 中关键技术

    加载屏障（Load barriers）技术；
    有色对象指针（Colored pointers）；
    单一分代内存管理（这一点很有意思）；
    基于区域的内存管理；
    部分内存压缩；
    即时内存复用。

并行化处理阶段

    标记(Marking);
    重定位（Relocation）/压缩（Compaction）；
    重新分配集的选择（Relocation set selection）；
    引用处理（Reference processing）；
    弱引用的清理（WeakRefs Cleaning）;
    字符串常量池（String Table）和符号表（Symbol Table）的清理；
    类卸载（Class unloading）。

着色指针Colored Pointer

ZGC利用指针的64位中的几位表示Finalizable、Remapped、Marked1、Marked0（ZGC仅支持64位平台），以标记该指向内存的存储状态。相当于在对象的指针上标注了对象的信息。注意，这里的指针相当于Java术语当中的引用。

在这个被指向的内存发生变化的时候（内存在Compact被移动时），颜色就会发生变化。

在G1的时候就说到过，Compact阶段是需要STW，否则会影响用户线程执行。那么怎么解决这个问题呢？
读屏障Load Barrier

由于着色指针的存在，在程序运行时访问对象的时候，可以轻易知道对象在内存的存储状态（通过指针访问对象），若请求读的内存在被着色了，那么则会触发读屏障。读屏障会更新指针再返回结果，此过程有一定的耗费，从而达到与用户线程并发的效果。

把这两项技术联合下理解，引用R大（RednaxelaFX）的话

与标记对象的传统算法相比，ZGC在指针上做标记，在访问指针时加入Load Barrier（读屏障），比如当对象正被GC移动，指针上的颜色就会不对，这个屏障就会先把指针更新为有效地址再返回，也就是，永远只有单个对象读取时有概率被减速，而不存在为了保持应用与GC一致而粗暴整体的Stop The World。

ZGC虽然目前还在JDK 11还在实验阶段，但由于算法与思想是一个非常大的提升，相信在未来不久会成为主流的GC收集器使用。
参数

ZGC回收机预计在jdk11支持，ZGC目前仅适用于Linux / x64 。和G1开启很像，用下面参数即可开启：

-XX:+UnlockExperimentalVMOptions -XX:+UseZGC