垃圾回收器
- GC分类与性能指标
- 不同垃圾回收器的概述
- Serial回收器(串行回收)
- ParNew回收器（并行回收）
- Parallel回收器(吞吐量优先)
- CMS回收器（低延迟）
- G1回收器(区域化分代式)
- 垃圾回收器总结
GC分类与性能指标
按线程数：
可以分为串行与并行垃圾回收器
- 串行回收指的是在同一时间段内只允许有一个CPU用于执行垃圾回收操作,此时工作线程被暂停,直至垃圾收集工作结束。
~在诸如单CPU处理器或者较小的应用内存等硬件平台不是特别优越的
场合,串行回收器的性能表现可以超过并行回收器和并发回收器。所
以,串行回收默认被应用在客户端的 Client模式下的JVM中
~在并发能力比较强的CPU上,并行回收器产生的停顿时间要短于串行回
收器。
- 并行收集可以运用多个CPU同时执行垃圾回收,因此提升了应用的吞吐量,不过并行回收仍然与串行回收一样,采用独占式,使用了“Stop-the- world”机制。
按工作模式：
可以分为并发式、独占式 垃圾回收器。
- 并发式垃圾回收器与应用程序线程交替工作,以尽可能减少应用程序的停顿时间。
- 独占式垃圾回收器( Stop the world)一旦运行,就停止应用程序中的所有用户线程,直到垃圾回收过程完全结束
按碎片处理方式分：
可分为压缩式、非压缩式垃圾回收器。
- 压缩式垃圾回收器会在回收完成后,对存活对象进行压缩整理,消除回收后的碎片，就不会产生内存碎片
- 非压缩式的垃圾回收器不进行这步操作 。
按工作内存分：
分为年轻代、老年代垃圾回收器
性能指标
一款优秀的垃圾收集器最多同时满足 上图3项红色中的2项
吞吐量、暂停时间，抓住这两个重点！
吞吐量
暂停时间
现在的标准：在最大吞吐量优先的情况下，尽量的降低停顿时间
不同垃圾回收器的概述
垃圾收集器的发展史
7款经典的垃圾收集器
垃圾收集器的组合关系
1、两个收集器有连线证明它们可以搭配使用
2、红色虚线的组合 由于维护和兼容性测试的成本在JDK8声明为 废弃。并且在JDK9中被移除了
3、绿色虚线的组合在JDK14中被弃用了
4、青色边框的虚线在JDK14中被删除了(CMS垃圾回收器被删除)
查看默认的垃圾收集器
Serial回收器(串行回收)
- Serial收集器采用复制算法、串行回收和“Stop-the-world”机制的方式执行内存回收。
- 除了年轻代之外, Serial收集器还提供用于执行老年代垃圾收集的
Serial Old收集器。 Serial Old收集器同样也采用了串行回收和 “ Stop the World” 机制,只不过内存回收算法使用的是标记-压缩算法。
Serial Old是运行在 Client模式下默认的老年代的垃圾回收器
Serial Old在 Server模式下主要有两个用途:
①与新生代的Parallel Scavenge配合使用
②作为老年代CMS收集器的后备垃圾收集方案
这个收集器是一个单线程的收集器,但它的“单线程”的意义并不仅仅说明它只会使用一个CPU或一条收集线程去完成垃圾收集工作,更重要的是在它进行垃圾收集时,必须暂停其他所有的工作线程,直到它收集结束( Stop The World)。
优势
简单而高效(与其他收集器的单线程比),对于限定单个CPU的环境来说, Serial收集器由于没有线程交互的开销,专心做垃圾收集自
然可以获得最高的单线程收集效率。
运行在 Client模式下的虚拟机是个不错的选择
总结
这种垃圾收集器了解即可,现在已经不用串行的了。而且在限定单核cpu才可以用。现在都不是单核的了。
对于交互较强的应用而言,这种垃圾收集器是不能接受的。一般在Java web应用程序中是不会采用串行垃圾收集器的。
ParNew回收器（并行回收）
- ParNew收集器除了采用并行回收的方式执行内存回收外,与Serial收集器之间几乎没有任何区别。 ParNew收集器在年轻代中同样也是采用复制算法、”Stop-the-World”机制。
- ParNew 是很多JVM在Server模式新生代的默认垃圾收集器。
- 对于新生代,回收次数频繁,使用并行方式高效
- 对于老年代,回收次数少,使用串行方式节省资源。(CPU并行需要切换线程,串行可以省去切换线程的资源)
- 虽然ParNew是基于并行回收，但并不代表回收效率在任何场景下都高于Serial。
但是在单个CPU的环境下, ParNew收集器不比 Serial收集器更高
效。虽然 Serial收集器是基于串行回收,但是由于CPU不需要频繁地
做任务切换,因此可以有效避免多线程交互过程中产生的一些额外开
销
- -XX:ParallelGCThreads限制线程数量,默认开启和CPU数据相同的线程数。
Parallel回收器(吞吐量优先)
Parallel Scavenge收集器同样也采用了复制算法、并行回收和”stop the world”机制
和 ParNew收集器不同,Parallel Scavenge收集器的目标则是达到一个可控制的吞吐量( Throughput),它也被称为吞吐量优先的垃圾收集器。
自适应调节策略也是Parallel Scavenge与 ParNew一个重要区别。
高吞吐量则可以高效率地利用CPU时间,尽快完成程序的运算任务,主要适合在后台运算而不需要太多交互的任务。因此,常见在服务器环境中
使用。例如,那些执行批量处理、订单处理、工资支付、科学计算的应用
程序。Parallel收集器在JDK1.6时提供了用于执行老年代垃圾收集的
ParallelOld收集器,用来代替老年代的 Serial Old收集器。Parallel Old收集器采用了标记-压缩算法,但同样也是基于并行回收和”Stop-the-World”机制。
这是Java8中的默认垃圾收集器
参数设置
CMS回收器（低延迟）
- 在JDK1.5时期, Hotspot推出了一款在强交互应用中几乎可认为有划时代意义的垃圾收集器:CMS (Concurrent-Mark- Sweep)收集器,这款收集器是 Hotspot虚拟机中第一款真正意义上的并发收集器,它第一次实现了让垃圾收集线程与用户线程同时工作
- CMS收集器的关注点是尽可能缩短垃圾收集时用户线程的停顿时间。
目前很大一部分的Java应用集中在互联网站或者B/S系统的服务端上,这类应用尤其重视服务的响应速度,希望系统停顿时间最短,以给用户带来较好的体验CMS收集器就非常符合这类应用的需求
- CMS的垃圾收集算法采用标记-清除算法,并且也会〃Stop-the-world〃
- CMS无法与新生代的 Parallel Scavenge搭配
- JDK9中被废弃
- JDK14被删除
工作原理：
CMS整个过程比之前的收集器要复杂,整个过程分为4个主要阶段,即初始标记阶段、并发标记阶段、重新标记阶段和并发清除阶段。
- 初始标记( Initial-Mark)阶段:在这个阶段中,程序中所有的工作线程都将会因为“Stop-the-Word”机制而出现短暂的暂停,这个阶段的主要任务仅仅只是标记出GC Roots能直接关联到的对象。一旦标记完成之后就会恢复之前被暂停的所有应用线程。由于直接关联对象比较小,所以这里的速度非常快。
- 并发标记( Concurrent-Mark)阶段:从 GC Roots的直接关联对象开始遍历整个对象图的过程,这个过程耗时较长但是不需要停顿用户线程,可以与垃圾收集线程一起并发运行。
- 重新标记( Remark)阶段:由于在并发标记阶段中,程序的工作线程会和垃圾收集线程同时运行或者交叉运行,导致GC不能确定有一些到底是不是垃圾，因此为了修正并发标记期间,因用户程序继续运作而导致标记产生变动的那一部分对象的标记记录,这个阶段的停顿时间通常会比初始标记阶段稍长一些,但也远比并发标记阶段的时间短。
- 并发清除( Concurrent-swep)阶段:此阶段清理删除掉标记阶段判断的已经死亡的对象,释放内存空间。由于不需要移动存活对象,所以这个阶段也是可以与用户线程同时并发的
由于在垃圾收集阶段用户线程没有中断,所以在CMS回收过程中,还应该确保应用程序用户线程有足够的内存可用。
因此,CMS收集器不能像其他收集器那样等到老年代几乎完全被填满了再进行收集,而是当堆内存使用率达到某一阈值时,便开始进行回收,以确保应用程序在CMS工作过程中依然有足够的空间支持应用程序运行。
要是CMS运行期间预留的内存无法满足程序需要,就会出现一次“current Mode failure”失败,这时虚拟机将启动后备预案:临时启用 Serial Old收集器来重新进行老年代的垃圾收集,这样停顿时间就很长了。
有人会觉得既然 Mark Sweep会造成内存碎片,那么为什么不把算法换成
Mark Compact呢?因为当并发清除的时候,用 Compact整理内存的话,原来的用户线程使用的内存还怎么用呢?要保证用户线程能继续执行,前提的它运行的资源不受影响。 Mark Compact更适合“ Stop the World”这种场景下使用
CMS优点
①并发收集
②低延迟
缺点
①会产生内存碎片,导致并发清除后,用户线程可用的空间不足。在无法分配大对象的情况下,不得不提前触发Full GC。
②CMS收集器对CPυ资源非常敏感。在并发阶段,它虽然不会导致用户停顿,但是会因为占用了一部分线程而导致应用程序变慢,总吞吐量会降低。
③CMS收集器无法处理浮动垃圾。可能出现“ Concurrent Mode Failure”失败而导致另一次Full GC的产生。
在重新标记阶段是标记是哪些在并发标记阶段不确定是不是垃圾的东西。而有一些在并发标记阶段并不是垃圾，但是却在后面的阶段变成了垃圾，CMS是无法处理这些垃圾的，称为浮动垃圾。
可设置的参数
小结
G1回收器(区域化分代式)
为什么要发布G1
①为了适应现在不断扩大的内存和不断增加的处理器数量,进一步降
低暂停时间( pause time),同时兼顾良好的吞吐量。
②官方给G1设定的目标是在延迟可控的情况下获得尽可能高的吞吐量,所以才担当起“全功能收集器”的重任与期望。
为什么叫做Garbage First(G1)
①G1主要针对配备多核CPU及大容量内存的机器,以极高概率满足GC停顿时间的同时,还兼具高吞吐量的性能特征。
②在JDK1.7版本正式启用,是JDK9以后的默认垃圾回收器,取代了CMS回收器以及Parallel+Parallel Old组合被Oracle官方称为“全功能的垃圾收集器”
③在jdk8中还不是默认的垃圾回收器,需要使用-XX:+UseG1GC来启用。
优势
- 并行与并发
并行性: G1在回收期间,可以有多个GC线程同时工作,有效利用多核计算能力。此时用户线程STW
并发性: G1拥有与应用程序交替执行的能力,部分工作可以和应用程序同时执行,
因此,一般来说,不会在整个回收阶段发生完全阻塞应用程序的情况
- 分代收集
①从分代上看,G1依然属于分代型垃圾回收器,它会区分年轻代和老年代,年轻代依然有Eden区和 Survivor区。但从堆的结构上看,它不要求整个Eden区、年轻代
或者老年代都是连续的,也不再坚持固定大小和固定数量。
②将堆空间分为若干个区域( Region),这些区域中包含了逻辑上的年轻代和老年代
③和之前的各类回收器不同,它同时 兼顾年轻代和老年代 。
- 空间整合
G1将内存划分为一个个的 region。内存的回收是以 region作为基本单位的。
Region之间是复制算法,但整体上实际可看作是标记-压缩(Mark- Compact）
算法,两种算法都可以避免内存碎片。这种特性有利于程序长时间运行,分配
大对象时不会因为无法找到连续内存空间而提前触发下一次GC。尤其是当
Java堆非常大的时候,G1的优势更加明显。
- 可预测停顿时间模型
缺点
相较于CMS,G1还不具备全方位、压倒性优势。比如在用户程序运行过程中,G1无论是为了垃圾收集产生的内存占用( Footprint)还是程序运行时的额外执行负载( Overload)都要比CMS要高。
从经验上来说,在小内存应用上CMS的表现大概率会优于G1,而G1在大内存应用上则发挥其优势。平衡点在6-8GB之间。
参数设置
G1的垃圾回收过程
①年轻代GC( Young GC)
②老年代并发标记过程( Concurrent Marking)
③混合回收( Mixed GC)
斯(如果需要,单线程、独占式、高强度的Full GC还是继续存在的。它针对GC的评估失败提供了一种失败保护机制,即强力回收。)
G1的设计原则就是简化JVM性能调优,开发人员只需要简单的三步即可完成调优
第一步:开启1垃圾收集器
第二步:设置堆的最大内存
第三步:设置最大的停顿时间
rememberd Set
分区(Region)
- 使用G1收集器时,它将整个Java堆划分成约2048个大小相同的独立 Region块,每个 Region块大小根据堆空间的实际大小而定,整体被控制在1MB到32MB之间,且为2的N次幂,即 1MB,2MB,4MB,8MB,16MB,32MB。可以通过-XX:G1 HeapRegionSize设定。所有的 Region大小相同,且在JVM生命周期内不会被改变。
- 虽然还保留有新生代和老年代的概念,但新生代和老年代不再是物理隔离的了它们都是一部分 Region(不需要连续)的集合。通过 Region的动态分配方式实现逻辑上的连续。
G1垃圾收集器还增加了一种新的内存区域,叫做 Humongous内存区域,如图中的H块。主要用于存储大对象,如果超过1.5个 region,就放到H。
设置H的原因:
对于堆中的大对象,默认直接会被分配到老年代,但是如果它是一个短期存在的大对象就会对垃圾收集器造成负面影响。为了解决这个问题,G1划分了一个 Humongous区,它用来专门存放大对象。如果一个H区装不下一个大对象,那么G1会寻找连续的H区来存储。为了能找到连续的H区,有时候不得不启动Full GC。G1的大多数行为都把H区作为老年代的一部分来看待。
垃圾回收器总结
