学习笔记（第15-17天）JVM-垃圾回收器

分类

1.按线程数分，可以分为串行垃圾回收器和并行垃圾回收器。

2.按工作模式分，可分为并发式垃圾回收器和独占式垃圾回收器。

3.按碎片处理方式分，可分为压缩式垃圾回收器和非压缩式垃圾回收器。

4.按工作的内存区间分，可分为年轻代垃圾回收器和老年代垃圾回收器。

评估GC的性能指标

• 吞吐量：运行用户代码的时间占总运行时间（程序运行时间+内存回收时间）的比例
• 垃圾收集开销：吞吐量的补数，垃圾收集所用时间与总运行时间的比例。
• 暂停时间：执行垃圾收集时，程序的工作线程被暂停的时间。
• 收集频率：相对于应用程序的执行，收集操作发生的频率。
• 内存占用：Java堆区所占的内存大小。
• 快速：一个对象从诞生到被回收所经历的时间。

标准：在最大吞吐量优先的情况下，降低停顿时间。

7款经典垃圾回收器

串行回收器：Serial，Serial Old
并行回收器：ParNew，Paraller Scavenge，Parallel Old
并发回收器：CMS，G1

垃圾回收器介绍

1.Serial GC和Serial Old GC：

• Serial回收器是最基本的，历史最悠久的垃圾收集器。
• Serial收集器作为HotSpot中Client模式下的默认新生代垃圾收集器。
• 采用复制算法，串行回收和STW机制的方式执行内存回收。
• 除了年轻代外，Serial收集器还提供执行老年代垃圾收集的Serial Old收集器。Serial Old收集器同样也采用了串行回收和STW机制，只不过内存回收使用的是标记-压缩算法。
• Serial Old是运行在client模式下默认的老年代垃圾回收器。
• Serial Old在Server模式下主要用两个用途。1：与新生代的Parallel Scavenge配合使用 2：作为老年代CMS收集器的后备垃圾收集方案。
• 在HotSpot虚拟机中，使用 -XX:+UseSerialGC 参数可以指定年轻代和老年代都是用串行收集器。新生代用Serial GC，老年代用Serial Old GC

优势：

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

• 运行在Client模式下的虚拟机是不错的选择。

• 在用户的桌面应用场景中，可用内存一般不大，可以在较短时间内完成垃圾收集，只要不频繁发生，使用串行回收器是可以接受的。

2.ParNew GC（并行）：

• 相当于多线程版本的Serial收集器。ParNew收集器除了采用并行回收方式外，两款垃圾回收器几乎没有任何区别。

• ParNew 是很多JVM运行在Serval模式下新生代的默认垃圾收集器。

• 除Serial外，目前只有ParNew GC能与CMS收集器配合工作。

• 在HotSpot虚拟机中，使用 -XX:+UseParNewGC 参数可以指定年轻代使用ParNew收集器执行内存回收任务。不影响老年代。

• -XX:ParallelGCThreads限制线程数量，默认开启和CPU数量相同的线程数。

3.Parallel Scavenge GC 和 Parallel Old GC（并行）：吞吐量优先

• 和ParNew收集器不同，Parallel Scavenge收集器的目标则是达到一个可控制的吞吐量，它也被称为吞吐量优先的垃圾收集器。自适应调节策略也是Parallel Scavenge与ParNew一个重要区别。

• 高吞吐量可以高效率地利用CPU时间，尽快完成程序的运算任务，主要适合在后台运算而不需要太多交互的任务。因此，场景在服务器环境中是用，例如，执行批量处理，订单处理，工资交付，科学计算的应用程序。

• Parallel GC在JDK1.6时提供用于执行老年代垃圾收集的Parallel Old GC，用于代替老年代的Serial Old GC。

• Parallel Old GC采用了标记-压缩算法。同样也是基于并行回收和STW机制。

• 在程序吞吐量优先的应用场景中，Parallel Scavenge GC 和 Parallel Old GC的组合，在Server模式下的内存回收性能很不错。

• 在Java8中，默认是此垃圾收集器。

• 在HotSpot虚拟机中，使用 -XX:+UseParallelGC 参数可以指定年轻代使用Parallel收集器执行内存回收任务。使用
  -XX:+UseParallelOldGC 参数可以指定老年代使用并行收集器执行内存回收任务。（两个参数默认开启一个，另一个也会被开启，即互相激活）

• -XX:ParallelGCThreads限制年轻代线程数量，默认开启，若CPU数量小于8个，开启和CPU数量相同的线程数。若大于8个，开启3+（5*CPU数量）/8个（向下取整）。

4.CMS GC（并发）：低延迟

• CMS GC是HotSpot虚拟机第一款真正意义上的并发收集器，它第一次实现了让垃圾收集线程与用户线程同时工作。

• CMS收集器的关注点是尽可能缩短垃圾收集时用户线程的停顿时间。停顿时间越短就越适合与用户交互的程序。

• 目前很大一部分的Java应用集中在互联网站或者B/S系统的服务端上，这类应用尤其重视服务的响应时间。CMS GC就非常符合这类应用的需求。

• CMS收集器的垃圾收集算法采用标记-清除算法，并且也会STW。

• CMS无法与Parallel Scavenge配合工作，只能选择ParNew或Serial收集器中的一个。

工作原理（4个阶段）：

• 初始标记阶段：在这个阶段中，程序中所有的工作线程都将会因为STW机制而出现短暂的暂停。这个阶段的主要任务仅仅只是标记出GC Roots能直接关联到的对象。一旦标记完成之后就会恢复之前被暂停的所有应用线程。由于直接关联对象较小，所以这里的速度非常快。
• 并发标记阶段：从GC Roots的直接关联对象开始遍历整个对象图的过程，这个过程耗时较长但是不需要停顿用户线程，可以与垃圾收集线程一起并发运行。
• 重新标记阶段：由于在并发标记阶段中，程序的工作线程会和垃圾收集线程同时运行或者交叉运行，因此为了修正并发标记期间，因用户程序继续运作而导致标记发生变动的那一部分对象的标记记录，需要进行STW，这个阶段的停顿时间通常会比初始标记阶段稍长一些，但也远比并发标记阶段的时间短。
• 并发清除阶段：此阶段清理删除掉标记阶段判断的已经死亡的对象，释放内存空间。由于不需要移动存活对象，所以这个阶段也是可以与用户线程同时并发的。

尽管CMS收集器采用的是并发回收，但是在其初始化标记和再次标记这两个阶段中仍然需要执行STW机制暂停程序中的工作线程，因此说明目前所有的垃圾收集器都做不到完全不需要STW，只是尽可能地缩短暂停时间。

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

由于在垃圾收集阶段用户线程没有中断，所以在CMS回收过程中，还应该确保应用程序线程有足够的内存可用。因此，CMS收集器不能像其他收集器那样等到老年代几乎被填满了再进行收集，而是当堆内存使用率达到某一阈值时，便开始进行回收，（JDK5及以前阈值默认值为68%，JDK6及以上默认值为92%）以确保应用程序在CMS工作过程中仍然有足够的空间支持应用程序运行。要是CMS运行期间预留的内存无法满足程序需要，就会出现一次“ConCurrent Mode Failure”失败。这时虚拟机将会启动后备预案，临时启用Serial Old收集器来重新进入老年代的垃圾收集，这样停顿时间就很长了。

由于CMS采用标记-清除算法，则在每次执行完内存回收后会不可避免的产生一些内存碎片。那么CMS在为新对象分配内存空间时，将无法使用指针碰撞技术，而只能够选择空闲列表执行内存分配。

JDK9时，CMS被标记为Deprecate，但可以用参数来开启CMS收集器。在JDK14后，CMS GC被移除。

CMS优点：

• 并发收集
• 低延迟

缺点：

• 会产生内存碎片，导致并发清除后，用户线程可用的空间不足。在无法分配大对象的情况下，不得不提前触发Full GC
• CMS收集器对CPU资源非常敏感。在并发阶段，它虽然不会导致用户停顿，但是会因为占用了一部分线程而导致应用程序变慢，总吞吐量降低。
• CMS处理器无法处理浮动垃圾。可能出现“ConCurrent Mode Failure”失败而导致另一次Full GC的产生。在并发标记阶段由于程序的工作线程和垃圾收集线程是同时运行或者交叉运行的，那么在并发标记阶段如果产生新的垃圾对象，CMS将无法对这些垃圾对象进行标记，最终会导致这些新产生的垃圾对象没有被及时回收，从而只能在下一次执行GC时释放这些之前未被回收的内存空间。

5.G1 GC（并行+并发）：区域化分代式

• G1是一个并行回收器，它把堆内存分割为很大不相关的区域（Region）（物理上不连续的）。使用不同的Region来表示Eden，S0区，S1区，老年代等。

• G1 GC有计划的避免在整个Java堆中进行全区域的垃圾收集。G1跟踪各个Region里面的垃圾堆积的价值大小（回收所获得的空间大小以及回收所需时间的经验值），在后台维护一个优先列表，每次根据运行的收集时间，优先回收价值最大的Region。

• 这种方法的侧重点在于回收垃圾最大量的区间，也是G1名字的由来（Garbage First）

• G1是一款面向服务端应用的垃圾收集器，主要针对配备多核CPU及大容量内存的机器，以极高概率满足GC停顿时间的同时，还兼具高吞吐量的性能特征。

• 在JDK7版本正式启用，JDK9后成为默认垃圾回收器。

优势：
并行与并发

• 并行性：G1在回收期间，可以有多个GC线程同时工作，有效利用多核计算能力。此时用户线程STW。
• 并发性：G1拥有与应用程序交替执行的能力，部分工作可以和应用程序同时执行，因此，一般来说，不会在整个回收阶段发生完全阻塞应用程序的情况。

分代收集

• 从分代上来，G1依然属于分代型垃圾回收器，它会区分年轻代和老年代，年轻代依然有Eden区和Survivor区。但从堆的结构上来看，它不要求整个Eden区，年轻代或者老年代都是连续的，也不再坚持固定大小和固定数量。
• 将堆空间分为若干个区域，这些区域中包含了逻辑上的年轻代和老年代。
• 和之前的各类回收器不同，它同时兼顾年轻代和老年代。

空间整合

• G1将内存划分为一个个region。内存的回收是以region作为基本单位的。Region之间是复制算法，但整体上实际可看作是标记-压缩算法。两种算法都可以避免内存碎片。这种特性有利于程序长时间运行，分配大对象时不会因为无法找到连续内存空间而提前触发下一次GC。尤其是当Java堆非常大的适合，G1优势更加明显。

可预测的停顿时间模式。

• 这是G1相对于CMS的另一大优势，G1除了追求低停顿外，还能建立可预测的停顿时间模型，能让使用者明确指定在一个M毫秒的时间片段内，消耗在垃圾收集上的时间不得超过N毫秒。
• 由于分区的原因，G1可以只选取部分区域进行内存回收，这样缩小了回收的范围，因此对于全局停顿情况的发生也能得到较好的控制。
• G1跟踪各个Region里面的垃圾堆积的价值大小（回收所获得的空间大小以及回收所需时间的经验值），在后台维护一个优先列表，每次根据运行的收集时间，优先回收价值最大的Region。保证了G1收集器在有限时间内可以获取尽可能高的收集效率。
• 相对于CMS，G1未必能做到CMS在最好情况下的延时停顿，但是最差情况要好很多。

缺点：

• 相较于CMS，G1还不具备全方位，压倒性优势。比如在用户程序运行过程中，G1无论是为了垃圾收集产生的内存占用还是程序运行时的额外执行负载都要比CMS要高。
• 从经验上来看，在小内存应用上CMS的表现大概率会优于G1，而G1在大内存应用上则发挥其优势。平衡点在6-8GB之间。

使用场景：

• 面向服务端应用，针对具有大内存，多处理器的机器（在普通大小的堆里表现并不惊喜）
• 最重要的应用是需要低GC延迟，并具有大堆的应用程序提供解决方案：如：在堆大小约6GB或更大时，可预测的暂停时间可以低于0.5秒；（G1通过每次只清理一部分而不是全部的Region的增量式清理来保证每次GC停顿时间不会过长）。
• 用来替换掉JDK1.5中的CMS收集器，在下面情况时，使用G1可能比CMS好：
  1.超过50%的Java堆被活动数据占用。
  2.对象分配频率或年代提升频率变化很大 GC停顿时间过长（长至0.5-1秒）
  3.HotSpot垃圾收集器里，除了G1以外，其他的垃圾收集器使用内置的JVM线程执行GC的多线程操作，而G1可以采用应用线程承担后台的GC工作，即当JVM的GC线程处理速度慢时，系统会调用应用程序线程帮助加速垃圾回收过程。

分区Region：化整为零

• 使用G1时，它将整个Java堆划分成约2048个大小相同的独立Region块，每个块大小根据堆空间的实际大小而定，整体被控制在1MB-32MB之间，且为2的次幂。可以通过-XXLG1HeapRegionSize设定。所有的块在JVM生命周期内不会被改变。
• 虽然还保留新生代和老年代的概念，但两者不再是物理隔离，它们都是一部分Region（不需要连续）的集合。通过Region的动态分配方式实现逻辑上的连续。一个region有可能属于Eden,Survivor或者old/tenured内存区域。但是一个region只可能属于一个角色。
• G1收集器还增加了一种新的内存区域，叫做Humongous内存区域。主要用于存储大对象。如果对象超过region的50%，就放到Humongous。如果一个H区装不下一个大对象，那么G1会寻找连续的H区来存储。为了能找到连续的H区，有时候不得不启动Full
  GC。G1的大多数行为都把H区作为老年代的一部分来看待。

G1回收器垃圾回收过程
G1 GC的垃圾回收过程主要包括三个环节

年轻代GC

• JVM启动时，G1先准备好Eden区，程序在运行过程中不断创建对象到Eden区，当Eden区空间耗尽时，G1会启动一次年顶戴垃圾回收过程。
  YGC时，首先G1进行STW，G1创建回收集（Collection
  Set），回收集是指需要被回收的内存分段集合，年轻代回收过程的回收集包含年轻代Eden区和Survivor区所有的内存分段。

回收过程：
第一阶段：扫描根

• 根是指static变量指向的对象，正在执行的方法调用链条上的局部变量等。根引用连同RSet记录的外部引用作为扫描存活对象的入口。

第二阶段：更新RSet

• 处理dirty card queue中的card,更新RSet。此阶段完成后，Rset可以准确的反应老年代对所在的内存分段中对象的引用。

第三阶段：处理RSet

• 识别被老年代对象指向的Eden中的对象，这些对象被认为是存活的。

第四阶段：复制对象

• 对象树被遍历，Eden区中存活的被复制到S区，S区中若年龄达到阈值会复制到Old区。如果S区空间不够，Eden区的部分数据直接晋升Old区。

第五阶段：处理引用

• 处理Soft，Weak，Phantom，Final，JNI
  Weak等引用。最终Eden空间数据为空，GC停止工作，而目标内存中的对象都是连续存储的。没有碎片，所以复制过程可以达到内存整理的效果。

老年代并发标记过程

• 初始标记阶段：标记从根节点直接可达的对象，该阶段是STW，并且会触发一次年轻代GC
• 根扫描阶段：G1 GC扫描S区直接可达的老年代区域对象，并标记被引用的对象。该对象必须在YGC前完成。
• 并发标记：在整个堆中进行并发标记（和应用程序并发），此过程可能被YGC中断。在并发标记阶段，若发现区域对象中的所有对象都是垃圾，那整个区域都会被立即回收。同时，并发标记过程中，会计算每个区域的对象活性（即存活对象的比例）
• 再次标记：由于应用程序持续进行，需要修正上一次的标记结果，该过程是STW的。G1中采用比CMS更快的初始快照算法：snaphot-at-the-beginning（SATB）。
• 独占清理：计算各个区域的存活对象和GC回收比例，并进行排序，识别可以混合回收的区域。为下阶段做铺垫，该阶段是STW的。这个阶段并不会实际上去做垃圾的收集。
• 并发清理阶段：识别并清理完全空闲的区域。

混合回收

• 当越来越多的都西昂晋升到老年代Old Region，为了避免堆内存被耗尽，虚拟机会触发一个混合的垃圾回收器。该算法除了回收整个Young
  Region，还会回收一部分的Old Region（注意是一部分）。可以选择哪些Old Region进行收集，从而可以对垃圾回收的耗时进行控制。注意此时是Mixed GC而不是Full GC.
• 并发标记结束以后，老年代中百分百为垃圾的内存分段被回收二零，部分为垃圾的内存分段被计算出来。默认情况下，这些老年代的内存分段会分8次被回收。
• 混合回收的回收集包括八分之一的老年代内存分段，Eden区内存分段，survivor区内存分段。混合回收的算法和年轻代回收的算法完全一样，只是多了老年代。
• 由于老年代中的内存分段默认分8次回收，G1会优先回收垃圾多的分段。并且有一个阈值决定内存分段是否被回收（默认为65%），意思是垃圾占内存分段比例要达65%才会被回收。如果垃圾占比太低，意味着存活对象占比高，复制会花费更多时间。
• 混合回收并不一定要进行8次，有一个阈值
  -XX:G1HeapWastePercent，默认为10%，意思是运行整个堆内存有10%的空间被浪费。意味着如果发现可以回收的垃圾占堆内存的比例低于10%，则不会进行混合回收。因为GC会花费很多时间但回收的内存却很少。

（如果需要，单线程，独占式，高强度的Full GC还是继续存在的。它针对GC的评估失败提供了一种失败保护机制，即强力回收。）
产生原因：
Evacution的时候没有足够的to-space来存放晋升的对象；
并发处理过程完成之前空间耗尽