【JVM】--常见的垃圾收集器
在【JVM】–对象是如何被定义为垃圾及回收算法一文中介绍了四种垃圾回收算法，分别为：
- 引用计数法
- 标记-清除法
- 标记-复制法
- 标记-整理法
垃圾收集器就是上面算法理论的具体实现。目前为止还没有出现完美的收集器，更没有万能的收集器，只是针对具体应用最合适的收集器，进行分代收集。
垃圾收集器
JVM是一个进程，垃圾收集器就是一个线程，垃圾收集线程是一个守护线程，优先级低，其在当前系统空闲或堆中老年代占用率较大时触发。
JDK7/8后，HotSpot虚拟机所有收集器及组合（连线），如下图：
串行、并行 和 并发
- 串行
按照一定顺序，顺序执行多个任务，即一个任务处理完成再开始下一个任务
小明刷完锅后再去洗碗- 并行（Parallel）
同一时间，同一人交替完成多个任务，交叉时间段只能选择一个任务来完成
小明刷一秒钟锅再跑去洗一秒钟碗，不断切换两个任务，看起来好像同时在刷锅和洗碗- 并发（Concurrent）
多个人同一时间，每个人一个任务的方式共同完成多个任务
小明和小红两个人，小明刷锅、小红洗碗，两人同时执行
Minor GC 和 Full GC
- Minor GC
又称新生代GC，指发生在新生代的垃圾收集动作；
因为Java对象大多是朝生夕灭，所以Minor GC非常频繁，一般回收速度也比较快；- Full GC
又称Major GC或老年代GC，指发生在老年代的GC；
出现Full GC经常会伴随至少一次的Minor GC（不是绝对，Parallel Sacvenge收集器就可以选择设置Major GC策略）；
Major GC速度一般比Minor GC慢10倍以上；
如何查看默认垃圾收集器
在命令行中：
java -XX:+PrintCommandLineFlags -version
-XX:InitialHeapSize=131286016 -XX:MaxHeapSize=2100576256 -XX:+PrintCommandLineFlags -XX:+UseCompressedClassPointers -XX:+UseCompressedOop
s -XX:-UseLargePagesIndividualAllocation -XX:+UseParallelGC
java version "1.8.0_151"
Java(TM) SE Runtime Environment (build 1.8.0_151-b12)
Java HotSpot(TM) 64-Bit Server VM (build 25.151-b12, mixed mode)
-XX:+UseParallelGC
默认使用并行收集器
Serial收集器
Serial（串行）垃圾收集器：JDK1.3.1前是HotSpot新生代收集的唯一选择，最基本、发展历史最悠久的收集器
特点
- 针对新生代
- 采用复制算法
- 单线程收集
- 串行
- 只会使用一个CPU或一条线程去完成垃圾收集工作
- 它进行垃圾收集时，必须暂停其他所有的工作线程，直到它收集结束为止，这个过程也称为
Stop The world
在用户不可见的情况下要把用户正常工作的线程全部停掉，这显然对很多应用是难以接受的
应用场景
HotSpot在Client模式下默认的新生代收集器
相比于其他收集器有明显优势：
- 简单高效（与其他收集器的单线程相比）
- 对于限定单个CPU的环境来说，Serial收集器由于没有线程交互的开销，专心做垃圾收集自然可以获得最高的单线程收集效率
- 在用户的桌面应用场景中，可用内存一般不大（几十M至一两百M），可以在较短时间内完成垃圾收集（几十MS至一百多MS）,只要不频繁发生，这是可以接受的
设置参数
-XX:+UseSerialGC：添加该参数来显式的使用串行垃圾收集器
开启后会使用Serial(Young区)+Serial Old(Old 区)的收集器组合
表示新生代、老年代都会使用串行回收器，新生代使用复制算法，老年代使用标记-整理算法
配置JVM：-Xmx10m -Xms10m -XX:+PrintCommandLineFlags -XX:+PrintGCDetails -XX:+UseSerialGC
public class GCDemo {
public static void main(String[] args) {
System.out.println("*******GCDemo***");
byte[] bytes = new byte[50 * 1024 * 1024];
}
}
运行结果：
使用串行垃圾回收器
- DefNew：def new generation 新生代
- tenured：老年代
-XX:InitialHeapSize=10485760 -XX:MaxHeapSize=10485760 -XX:+PrintCommandLineFlags -XX:+PrintGCDetails -XX:+UseCompressedClassPointers -XX:+UseCompressedOops -XX:-UseLargePagesIndividualAllocation -XX:+UseSerialGC
*******GCDemo***
[GC (Allocation Failure) [DefNew: 2127K->320K(3072K), 0.0028782 secs][Tenured: 379K->698K(6848K), 0.0028373 secs] 2127K->698K(9920K), [Metaspace: 3468K->3468K(1056768K)], 0.0057932 secs] [Times: user=0.01 sys=0.00, real=0.01 secs]
[Full GC (Allocation Failure) [Tenured: 698K->680K(6848K), 0.0022959 secs] 698K->680K(9920K), [Metaspace: 3468K->3468K(1056768K)], 0.0023261 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
Heap
def new generation total 3072K, used 77K [0x00000000ff600000, 0x00000000ff950000, 0x00000000ff950000)
eden space 2752K, 2% used [0x00000000ff600000, 0x00000000ff613620, 0x00000000ff8b0000)
from space 320K, 0% used [0x00000000ff900000, 0x00000000ff900000, 0x00000000ff950000)
to space 320K, 0% used [0x00000000ff8b0000, 0x00000000ff8b0000, 0x00000000ff900000)
tenured generation total 6848K, used 680K [0x00000000ff950000, 0x0000000100000000, 0x0000000100000000)
the space 6848K, 9% used [0x00000000ff950000, 0x00000000ff9fa248, 0x00000000ff9fa400, 0x0000000100000000)
Metaspace used 3499K, capacity 4496K, committed 4864K, reserved 1056768K
class space used 384K, capacity 388K, committed 512K, reserved 1048576K
Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
at com.fjw._12_GC.GCDemo.main(GCDemo.java:12)
Process finished with exit code 1
ParNew收集器
ParNew垃圾收集器是Serial收集器的多线程版本，除了使用多条线程进行垃圾收集外，其余行为和Serial收集器完全一样，包括Serial收集器可用的所有控制参数、收集算法、Stop The world、对象分配规则、回收策略等都一样。在实现上也共用了相当多的代码。
特点
- 针对新生代
- 采用复制算法
- 串行
- 多线程收集
应用场景
Server模式下的虚拟机中首选的新生代收集器
很重要的原因是： 除了Serial收集器之外，目前只有它能与CMS收集器配合工作。
在JDK1.5时期，HotSpot推出了一款几乎可以认为具有划时代意义的垃圾收集器-----CMS收集器，这款收集器是HotSpot虚拟机中第一款真正意义上的并发收集器，它第一次实现了让垃圾收集线程与用户线程同时工作。
为什么只有ParNew能与CMS收集器配合
- CMS作为老年代收集器，但却无法与JDK1.4已经存在的新生代收集器Parallel Scavenge配合工作；
因为Parallel Scavenge（以及G1）都没有使用传统的GC收集器代码框架，而另外独立实现；
而其余几种收集器则共用了部分的框架代码；
设置参数
-XX:+UseConcMarkSweepGC：指定使用CMS后，会默认使用ParNew作为新生代收集器-XX:+UseParNewGC：强制指定使用ParNew，只影响新生代收集，不影响老年代
即ParNew(新生代)+Serial Old(老年代)，新生代使用复制算法，老年代使用标记-整理算法，这个组合Java8不再推荐，会报出警告-XX:ParallelGCThreads：指定垃圾收集的线程数量，ParNew默认开启的收集线程与CPU的数量相同
配置JVM：-Xmx10m -Xms10m -XX:+PrintCommandLineFlags -XX:+PrintGCDetails -XX:+UseParNewGC
public class ParNewGC {
public static void main(String[] args) {
System.out.println("*******ParNewGC***");
byte[] bytes = new byte[50 * 1024 * 1024];
}
}
运行结果：
-XX:InitialHeapSize=10485760 -XX:MaxHeapSize=10485760 -XX:+PrintCommandLineFlags -XX:+PrintGCDetails -XX:+UseCompressedClassPointers -XX:+UseCompressedOops -XX:-UseLargePagesIndividualAllocation -XX:+UseParNewGC
*******ParNewGC***
[GC (Allocation Failure) [ParNew: 2127K->320K(3072K), 0.0291131 secs][Tenured: 403K->719K(6848K), 0.0034244 secs] 2127K->719K(9920K), [Metaspace: 3467K->3467K(1056768K)], 0.0326104 secs] [Times: user=0.03 sys=0.00, real=0.03 secs]
[Full GC (Allocation Failure) [Tenured: 719K->680K(6848K), 0.0032213 secs] 719K->680K(9920K), [Metaspace: 3467K->3467K(1056768K)], 0.0032524 secs] [Times: user=0.01 sys=0.00, real=0.00 secs]
Heap
par new generation total 3072K, used 77K [0x00000000ff600000, 0x00000000ff950000, 0x00000000ff950000)
eden space 2752K, 2% used [0x00000000ff600000, 0x00000000ff613620, 0x00000000ff8b0000)
from space 320K, 0% used [0x00000000ff900000, 0x00000000ff900000, 0x00000000ff950000)
to space 320K, 0% used [0x00000000ff8b0000, 0x00000000ff8b0000, 0x00000000ff900000)
tenured generation total 6848K, used 680K [0x00000000ff950000, 0x0000000100000000, 0x0000000100000000)
the space 6848K, 9% used [0x00000000ff950000, 0x00000000ff9fa0f8, 0x00000000ff9fa200, 0x0000000100000000)
Metaspace used 3497K, capacity 4496K, committed 4864K, reserved 1056768K
class space used 384K, capacity 388K, committed 512K, reserved 1048576K
Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
at com.fjw._12_GC.ParNewGC.main(ParNewGC.java:12)
Java HotSpot(TM) 64-Bit Server VM warning: Using the ParNew young collector with the Serial old collector is deprecated and will likely be removed in a future release
Process finished with exit code 1
Parallel Scavenge收集器
Parallel Scavenge收集器和ParNew类似，新生代的收集器，同样用的是复制算法，也是并行多线程收集。与ParNew最大的不同，它关注的是垃圾回收的吞吐量。
特点
- 高吞吐量
它的关注点与其他收集器不同
CMS等收集器的关注点是尽可能地缩短垃圾收集时用户线程的停顿时间；
而Parallel Scavenge收集器的目标则是达一个可控制的吞吐量
吞吐量 和 停顿时间
- 停顿时间优先：交互多，对响应速度要求高
- 吞吐量优先：交互少，计算多，适合在后台运算的场景。
应用场景
Server模式下的默认垃圾收集器。
高吞吐量为目标，即减少垃圾收集时间，让用户代码获得更长的运行时间，适合那种交互少、运算多的场景
例如，那些执行批量处理、订单处理、工资支付、科学计算的应用程序；
设置参数
-XX:+MaxGCPauseMillis：控制最大垃圾收集停顿时间，大于0的毫秒数；
这个参数设置的越小，停顿时间可能会缩短，但也会导致吞吐量下降，导致垃圾收集发生得更频繁-XX:GCTimeRatio：设置垃圾收集时间占总时间的比率，0-XX:+UseAdptiveSizePolicy：开启这个参数后，就不用手工指定一些细节参数，如：
新生代的大小（-Xmn）、Eden与Survivor区的比例（-XX:SurvivorRation）、晋升老年代的对象年龄（-XX:PretenureSizeThreshold）等；
JVM会根据当前系统运行情况收集性能监控信息，动态调整这些参数，以提供最合适的停顿时间或最大的吞吐量，这种调节方式称为GC自适应的调节策略（GC Ergonomiscs）
JVM中默认就是Paralle收集器，也可通过参数指定：
-XX:+UserParallelGC或-XX:+UserParallelOldGC（互相激活）
开启后新生代使用复制算法，老年代使用标记-整理算法
配置JVM：-Xmx10m -Xms10m -XX:+PrintCommandLineFlags -XX:+PrintGCDetails，使用默认垃圾回收器
public class ParallelDemo {
public static void main(String[] args) {
System.out.println("*******GCDemo***");
byte[] bytes = new byte[50 * 1024 * 1024];
}
}
运行结果：
-XX:InitialHeapSize=10485760 -XX:MaxHeapSize=10485760 -XX:+PrintCommandLineFlags -XX:+PrintGCDetails -XX:+UseCompressedClassPointers -XX:+UseCompressedOops -XX:-UseLargePagesIndividualAllocation -XX:+UseParallelGC
*******ParallelDemo***
[GC (Allocation Failure) [PSYoungGen: 1887K->488K(2560K)] 1887K->712K(9728K), 0.0213987 secs] [Times: user=0.03 sys=0.00, real=0.02 secs]
[GC (Allocation Failure) [PSYoungGen: 488K->488K(2560K)] 712K->712K(9728K), 0.0018043 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
[Full GC (Allocation Failure) [PSYoungGen: 488K->0K(2560K)] [ParOldGen: 224K->653K(7168K)] 712K->653K(9728K), [Metaspace: 3189K->3189K(1056768K)], 0.0357767 secs] [Times: user=0.06 sys=0.00, real=0.04 secs]
[GC (Allocation Failure) [PSYoungGen: 0K->0K(2560K)] 653K->653K(9728K), 0.0155193 secs] [Times: user=0.01 sys=0.00, real=0.02 secs]
[Full GC (Allocation Failure) [PSYoungGen: 0K->0K(2560K)] [ParOldGen: 653K->639K(7168K)] 653K->639K(9728K), [Metaspace: 3189K->3189K(1056768K)], 0.0090648 secs] [Times: user=0.02 sys=0.00, real=0.01 secs]
Heap
PSYoungGen total 2560K, used 121K [0x00000000ffd00000, 0x0000000100000000, 0x0000000100000000)
eden space 2048K, 5% used [0x00000000ffd00000,0x00000000ffd1e658,0x00000000fff00000)
from space 512K, 0% used [0x00000000fff00000,0x00000000fff00000,0x00000000fff80000)
to space 512K, 0% used [0x00000000fff80000,0x00000000fff80000,0x0000000100000000)
ParOldGen total 7168K, used 639K [0x00000000ff600000, 0x00000000ffd00000, 0x00000000ffd00000)
object space 7168K, 8% used [0x00000000ff600000,0x00000000ff69fe58,0x00000000ffd00000)
Metaspace used 3269K, capacity 4496K, committed 4864K, reserved 1056768K
class space used 359K, capacity 388K, committed 512K, reserved 1048576K
Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
at com.fjw._12_GC.ParallelDemo.main(ParallelDemo.java:10)
Process finished with exit code 1
Serial Old收集器
Serial Old是 Serial收集器的老年代版本，其他与Serial相同
特点
- 针对老年代
- 采用标记-整理算法
应用场景
- Client模式
Serial Old收集器的主要意义也是在于给Client模式下的虚拟机使用 - Server模式
- 在JDK1.5及之前，与Parallel Scavenge收集器搭配使用（JDK1.6有Parallel Old收集器可搭配）；
- 作为CMS收集器的后备预案，在并发收集发生Concurrent Mode Failure时使用
Parallel Old收集器
Parallel Old收集器是Parallel Scavenge收集器的老年版本，它也使用多线程和“标记-整理”算法。这个收集器是在JDK 1.6开始提供。
特点
- 采用"标记-整理"算法
- 高吞吐量
应用场景
- JDK1.6及之后用来代替老年代的Serial Old收集器
- 特别是在Server模式，多CPU的情况下；
- 这样在注重吞吐量以及CPU资源敏感的场景，就有了Parallel Scavenge加Parallel Old收集器的"给力"应用组合
设置参数
-XX:+UseParallelOldGC：指定使用Parallel Old收集器
CMS收集器
Concurrent Mark Sweep并发标记清除
也称为并发低停顿收集器（Concurrent Low Pause Collector）或低延迟（low-latency）垃圾收集器
CMS是HotSpot在JDK5推出的第一款真正意义上的并发（Concurrent）收集器，第一次实现了让垃圾收集线程与用户线程（基本上）同时工作
特点
- 针对老年代
- 标记-清除算法 (不进行压缩操作，产生内存碎片)
- 并发
- 多线程
- 收集过程中不需要暂停用户线程
- 以获取最短回收停顿时间为目标
应用场景
- 与用户交互较多的场景
- 希望系统停顿时间最短，注重服务的响应速度
CMS 收集器是一种以获取最短回收停顿时间为目标的收集器。目前很大一部分的Java应用集中在互联网或者B/S系统的服务端上，这类应用尤其注重服务的响应速度，希望系统停顿时间最短，以给用户带来极好的体验。CMS收集器就非常符合这类应用的需求。
运作过程
比前面几种收集器更复杂，可以分为4个步骤:
初始标记（initial mark）
- 单线程执行
- 需要“Stop The World”
- 但仅仅把GC Roots的直接关联可达的对象给标记一下，由于直接关联对象比较小，所以这里的速度非常快
并发标记（concurrent mark）
- 对于初始标记过程所标记的初始标记对象，进行并发追踪标记
- 此时其他线程仍可以继续工作
- 此处时间较长，但不停顿
- 并不能保证可以标记出所有的存活对象
重新标记（remark）
- 在并发标记的过程中，由于可能还会产生新的垃圾，所以此时需要重新标记新产生的垃圾
- 此处执行并行标记，与用户线程不并发，所以依然是“Stop The World”
- 且停顿时间比初始标记稍长，但远比并发标记短
并发清除（concurrent sweep）
- 并发清除之前所标记的垃圾
- 其他用户线程仍可以工作，不需要停顿
其中，初始标记和并发标记仍然需要Stop the World、初始标记仅仅标记一下GC Roots能直接关联到的对象，速度很快，并发标记就是进行GC RootsTracing的过程，而重新标记阶段则是为了修正并发标记期间因用户程序继续运行而导致标记产生变动的那一部分对象的标记记录，这个阶段的停顿时间一般会比初始标记阶段长，但远比并发标记的时间短。
由于整个过程中耗时最长的并发标记和并发清除过程收集器线程都可以与用户线程一起工作，所以整体上说，CMS收集器的内存回收过程是与用户线程一共并发执行的。
设置参数
-XX:+UseConcMarkSweepGC：指定使用CMS收集器-XX:+UseCMSCompactAtFullCollection：Full GC后，进行一次碎片整理；整理过程是独占的，会引起停顿时间变长-XX:+CMSFullGCsBeforeCompaction：设置进行几次Full GC后，进行一次碎片整理-XX:ParallelCMSThreads：设定CMS的线程数量（一般情况约等于可用CPU数量）
配置JVM：-Xmx10m -Xms10m -XX:+PrintCommandLineFlags -XX:+PrintGCDetails -XX:+UseConcMarkSweepGC
public class CMSDemo {
public static void main(String[] args) {
System.out.println("*******CMSDemo***");
byte[] bytes = new byte[50 * 1024 * 1024];
}
}
运行结果：
- 新生代：ParNew
- 老年代：CMS
-XX:InitialHeapSize=10485760 -XX:MaxHeapSize=10485760 -XX:MaxNewSize=3497984 -XX:MaxTenuringThreshold=6 -XX:NewSize=3497984 -XX:OldPLABSize=16 -XX:OldSize=6987776 -XX:+PrintCommandLineFlags -XX:+PrintGCDetails -XX:+UseCompressedClassPointers -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC -XX:-UseLargePagesIndividualAllocation -XX:+UseParNewGC
*******CMSDemo***
[GC (Allocation Failure) [ParNew: 2148K->320K(3072K), 0.0019102 secs][CMS: 371K->679K(6848K), 0.0037324 secs] 2148K->679K(9920K), [Metaspace: 3461K->3461K(1056768K)], 0.0057326 secs] [Times: user=0.02 sys=0.00, real=0.01 secs]
[Full GC (Allocation Failure) [CMS: 679K->660K(6848K), 0.0033454 secs] 679K->660K(9920K), [Metaspace: 3461K->3461K(1056768K)], 0.0033890 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
Heap
par new generation total 3072K, used 108K [0x00000000ff600000, 0x00000000ff950000, 0x00000000ff950000)
eden space 2752K, 3% used [0x00000000ff600000, 0x00000000ff61b118, 0x00000000ff8b0000)
from space 320K, 0% used [0x00000000ff900000, 0x00000000ff900000, 0x00000000ff950000)
to space 320K, 0% used [0x00000000ff8b0000, 0x00000000ff8b0000, 0x00000000ff900000)
concurrent mark-sweep generation total 6848K, used 660K [0x00000000ff950000, 0x0000000100000000, 0x0000000100000000)
Metaspace used 3498K, capacity 4496K, committed 4864K, reserved 1056768K
class space used 384K, capacity 388K, committed 512K, reserved 1048576K
Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
at com.fjw._12_GC.CMSDemo.main(CMSDemo.java:12)
Process finished with exit code 1
存在缺点
总体来看，与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动作。
解决方法
-XX:+UseCMSCompactAtFullCollection
使得CMS出现上面这种情况时不进行Full GC，而开启内存碎片的合并整理过程；
但合并整理过程无法并发，停顿时间会变长；
默认开启（但不会进行，结合下面的CMSFullGCsBeforeCompaction）；
-XX:+CMSFullGCsBeforeCompaction
设置执行多少次不压缩的Full GC后，来一次压缩整理；
为减少合并整理过程的停顿时间；
默认为0，也就是说每次都执行Full GC，不会进行压缩整理；
由于空间不再连续，CMS需要使用可用"空闲列表"内存分配方式，这比简单实用"碰撞指针"分配内存消耗大；
小结
总体来看，与Parallel Old垃圾收集器相比，CMS减少了执行老年代垃圾收集时应用暂停的时间；
但却增加了新生代垃圾收集时应用暂停的时间、降低了吞吐量而且需要占用更大的堆空间；
G1收集器
G1（Garbage-First）是JDK7-u4才推出商用的收集器；
G1（Garbage - First）名称的由来是G1跟踪各个Region里面的垃圾堆的价值大小（回收所获得的空间大小以及回收所需时间的经验值），在后台维护一个优先列表，每次根据允许的收集时间，优先回收价值最大的Region。
Region概念
- 横跨整个堆内存
在G1之前的其他收集器进行收集的范围都是整个新生代或者老生代，而G1不再是这样- G1在使用时，Java堆的内存布局与其他收集器有很大区别
- 它将整个Java堆划分为多个大小相等的独立区域（Region）
- 虽然还保留新生代和老年代的概念，但新生代和老年代不再是物理隔离的了，而都是一部分Region（可以不连续）的集合
G1遵循分代收集的理论设计，但其堆内存的布局与其他收集器有非常明显的差异：
- G1不在坚持固定大小以及固定数量的分代区域划分，而是把连续的Java堆划分为多个大小相等的独立区域（Region），每个Region都可以根据需要，扮演新生代的Eden空间、Survivor空间，或者老年代空间。收集器能够对扮演不同角色的Region采用不同的策略去处理，这样无论是新创建的对象还是已经存活了一段时间、熬过多次收集的旧对象都能获取很好的收集效果。
在G1中，还有一种特殊的区域，叫Humongous区域。 如果一个对象占用的空间超过了分区容量50%以上，G1收集器就认为这是一个巨型对象。这些巨型对象，默认直接会被分配在年老代，但是如果它是一个短期存在的巨型对象，就会对垃圾收集器造成负面影响。为了解决这个问题，G1划分了一个Humongous区，它用来专门存放巨型对象。如果一个H区装不下一个巨型对象，那么G1会寻找连续的H分区来存储。为了能找到连续的H区，有时候不得不启动Full GC。
特点
- 可并行，可并发
G1 能充分利用多CPU、多核环境下的硬件优势，使用多个CPU来缩短“Stop The World”停顿时间 - 分代收集，收集范围包括新生代和老年代
- 能独立管理整个GC堆（新生代和老年代），而不需要与其他收集器搭配
- 能够采用不同方式处理不同时期的对象
- 空间整合，不产生碎片
- 从整体看，是基于标记-整理算法；
- 从局部（两个Region间）看，是基于复制算法；
- 都不会产生内存碎片，有利于长时间运行；
- 这种特性有利于程序长时间运行，分配大对象时不会因为无法找到连续内存空间而提前触发下一次GC
- 可预测的停顿：低停顿的同时实现高吞吐量
- G1收集器之所以能建立可预测的停顿时间模型，是因为它可以有计划地避免在整个Java堆中进行全区域的垃圾收集。
- G1跟踪各个Region里面的垃圾堆积的价值大小（回收所获得的空间大小以及回收所需时间的经验值），在后台维护一个优先列表，
- 每次根据允许的收集时间，优先回收价值最大的Region，这样就保证了在有限的时间内尽可能提高效率。（这也就是Garbage-First名称的来由）。
- 这种使用Region划分内存空间以及有优先级的区域回收方式，保证了G1收集器在有限的时间内可以获取尽可能高的收集效率
应用场景
如果你的应用追求低停顿，那G1现在已经可以作为一个可尝试选择，如果你的应用追求吞吐量，那G1并不会为你带来什么特别的好处。
- 面向服务端应用，针对具有大内存、多处理器的机器；最主要的应用是为需要低GC延迟，并具有大堆的应用程序提供解决方案
如：在堆大小约6GB或更大时，可预测的暂停时间可以低于0.5秒； - 用来替换掉JDK1.5的CMS收集器
- 超过50%的Java堆被活动数据占用
- 对象分配频率或年代提升频率变化很大
- GC停顿时间过长（长与0.5至1秒）
设置参数
-XX:+UseG1GC：指定使用G1收集器-XX:InitiatingHeapOccupancyPercent：当整个Java堆的占用率达到参数值时，开始并发标记阶段；默认为45-XX:MaxGCPauseMillis：为G1设置暂停时间目标，默认值为200毫秒-XX:G1HeapRegionSize：设置每个Region大小，范围1MB到32MB；目标是在最小Java堆时可以拥有约2048个Region
运作过程
分为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，并且在此过程中压缩和释放内存；
- 可以并发进行，降低停顿时间，并增加吞吐量；
收集器总结
连线的收集器会互相配合使用
| 收集器 | 串行、并行or并发 | 新生代/老年代 | 算法 | 目标 | 适用场景 |
|---|---|---|---|---|---|
| Serial | 串行 | 新生代 | 复制算法 | 响应速度优先 | 单CPU环境下的Client模式 |
| Serial Old | 串行 | 老年代 | 标记-整理 | 响应速度优先 | 单CPU环境下的Client模式、CMS的后备预案 |
| ParNew | 并行 | 新生代 | 复制算法 | 响应速度优先 | 多CPU环境时在Server模式下与CMS配合 |
| Parallel Scavenge | 并行 | 新生代 | 复制算法 | 吞吐量优先 | 在后台运算而不需要太多交互的任务 |
| Parallel Old | 并行 | 老年代 | 标记-整理 | 吞吐量优先 | 在后台运算而不需要太多交互的任务 |
| CMS | 并发 | 老年代 | 标记-清除 | 响应速度优先 | 集中在互联网站或B/S系统服务端上的Java应用 |
| G1 | 并发 | both | 标记-整理+复制算法 | 响应速度优先 | 面向服务端应用，将来替换CMS |
参数总结
| 参数 | MinorGC | Full GC | 描述 |
|---|---|---|---|
| -XX:+UseSerialGC | Serial收集器串行回收 | Serial Old收集器串行回收 | 该选项可以手动指定Serial收集器+Serial Old收集器组合执行内存回收 |
| -XX:+UseParNewGC | ParNew收集器并行回收 | 该选项可以手动指定ParNew收集器+Serilal Old组合执行内存回收 | |
| -XX:+UseParallelGC | Parallel收集器并行回收 | 该选项可以手动指定Parallel收集器+Serial Old收集器组合执行内存回收 | |
| -XX:+UseParallelOldGC | Parallel收集器并行回收 | Parallel Old收集器并行回收 | 该选项可以手动指定Parallel收集器+Parallel Old收集器组合执行内存回收 |
| -XX:+UseConcMarkSweepGC | ParNew收集器并行回收 | 缺省使用CMS收集器并发回收，备用采用Serial Old收集器串行回收 | 该选项可以手动指定ParNew收集器+CMS收集器+Serial Old收集器组合执行内存回收。优先使用ParNew收集器+CMS收集器的组合，当出现ConcurrentMode Fail或者Promotion Failed时，则采用ParNew收集器+Serial Old收集器的组合 |
| -XX:+UseConcMarkSweepGC -XX:-UseParNewGC | Serial收集器串行回收 | ||
| -XX:+UseG1GC | G1收集器并发、并行执行内存回收 | 暂无 | |
参考文章：
Java虚拟机垃圾回收(三) 7种垃圾收集器
Java——七种垃圾收集器+JDK11最新ZGC