十三、垃圾回收篇——垃圾回收器

1、串行vs并行

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

2、并发式vs独占式

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

• 并发式垃圾回收器与应用程序线程交替工作，以尽可能减少应用程序的停顿时间。


• 独占式垃圾回收器（ Stop the world)一旦运行，就停止应用程序中的其他所有线程，直到垃圾回收过程完全结束。

3、压缩式vs非压缩式

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

• 压缩式垃圾回收器会在回收完成后，对存活对象进行压缩整理，消除回收后的碎片。


• 非压缩式的垃圾回收器不进行这步操作。

4、年轻代vs老年代

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

• （重点）吞吐量：程序的运行时间（程序的运行时间＋内存回收的时间）。
   


• 垃圾收集开销：吞吐量的补数，垃圾收集器所占时间与总时间的比例。


• （重点）暂停时间：执行垃圾收集时，程序的工作线程被暂停的时间。


• 收集频率：相对于应用程序的执行，收集操作发生的频率。


• （重点）内存占用： Java 堆区所占的内存大小。


• 快速： 一个对象从诞生到被回收所经历的时间。

红色的三项共同构成一个“不可能三角”。三者总体的表现会随着技术进步而越来越好。一款优秀的收集器通常最多同时满足其中的两项。这三项里，低延迟的重要性日益凸显（暂停时间 -> 响应时间 -> 追求低延迟）。

1、面试题

• 请问吞吐量的优化和响应优先的垃圾收集器是如何选择的呢？


• 吞吐量优先选择什么垃圾回收器?响应时间优先呢？

2、吞吐量

比如：虚拟机总共运行了100分钟，其中垃圾收集花掉1分钟，那吞吐量就是99%。

3、暂停时间

比如：GC期间100毫秒的暂停时间意味着在这100毫秒期间内没有应用程序线程是活动的。

4、吞吐量vs暂停时间

1. 高吞吐量较好，因为这会让应用程序的最终用户感觉只有应用程序线程在做"生产性"工作。直觉上，吞吐量越高程序运行越快


2. 低暂停时间(低延迟)较好，因为从最终用户的角度来看不管是GC还是其他原因导致一个应用被挂起始终是不好的。这取决于应用程序的类型，有时候甚至短暂的20毫秒暂停都可能打断终端用户体验。因此，具有低的较大暂停时间是非常重要的，特别是对于一个交互式应用程序。


3. 不幸的是"高吞吐量"和"低暂停时间"是一对相互竞争的目标(矛盾)。
   
   
   
   • 如果选择以吞吐量优先，那么必然需要降低内存回收的执行频率，但是这样会导致一次GC需要更长的暂停时间来执行内存回收。
   
   
   • 如果选择以低延迟优先，那么为了降低每次执行内存回收时的暂停时间，也只能频繁地执行内存回收，但这又引起了年轻代内存的缩减和导致程序吞吐量的下降。
   
   
   
   

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

线程分类： 

• 串行回收器： Serial、 Serial Old


• 并行回收器： ParNew、 Parallel Scavenge、Parallel Old


• 并发回收器：CMS、G1

分代分类：

• 新生代收集器： Serial、 ParNew、Parallel Scavenge


• 老年代收集器： Serial Old、Parallel old、CMS


• 整堆收集器：G1

1、面试题

• GC收集器有哪些？


• 几种垃圾回收器


• 垃圾回收器有哪些？都有哪些算法来实现？项目中用的垃圾回收器是什么？


• 垃圾回收器的基本原理是什么？垃圾回收器可以马上回收内存吗？有什么办法主动通知虚拟机进行垃圾回收？


• 你知道那些垃圾回收器


• 有哪些垃圾方法，垃圾收集器是什么。


• JVM有哪三种垃圾回收器？

2、为什么这么多GC？

• 因为Java的使用场景很多，移动端，服务器等。所以就需要针对不同的场景，提供不同的垃圾收集器，提高垃圾收集的性能。


• 虽然我们会对各个收集器进行比较，但并非为了挑选一个最好的收集器出来。没有一种放之四海皆准、任何场景下都适用的完美收集器存在，更加没有万能的收集器。所以我们选择的只是对具体应用最合适的收集器。

3、如何查看默认GC？

• -XX:+PrintCommandLineFlags:查看命令行相关参数（包含使用的垃圾收集器)


• 使用命令行指令:jinfo - flag相关垃圾回收器参数进程ID

4、Serial GC：串行回收

（1）概述

• Serial收集器作为HotSpot中client模式下的默认新生代垃圾收集器。


• Serial收集器采用复制算法、串行回收和"stop-the-World"机制的方式执行内存回收。


• Serial收集器还提供用于执行老年代垃圾收集的Serial old收集器。Serial old收集器同样也采用了串行回收和"stop the World"机制，只不过内存回收算法使用的是标记-压缩算法。

  
  
  
  • Serial old是运行在Client模式下默认的老年代的垃圾回收器。
  
  
  • Serial old在Server模式下主要有两个用途：
    
    
    
    • 与新生代的Parallel scavenge配合使用。
    
    
    • 作为老年代CMS收集器的后备垃圾收集方案
    
    
    
    
  
  
  
  

（2）优势

• 简单而高效（与其他收集器的单线程比），对于限定单个CPU的环境来说，Serial收集器由于没有线程交互的开销，专心做垃圾收集自然可以获得最高的单线程收集效率。
  运行在Client模式下的虚拟机是个不错的选择。


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

（3）参数

在HotSpot虚拟机中，使用 -XX:+UseSerialGC 参数可以指定年轻代和老年代都使用串行收集器。

（4）小结

1. 这种垃圾收集器大家了解，现在已经不用串行的了。而且在限定单核cpu才可以用。现在都不是单核的了。

   
   



2. 对于交互较强的应用而言，这种垃圾收集器是不能接受的。一般在Java web应用程序中是不会采用串行垃圾收集器的。

   
   

5、ParNew GC：并行回收

（1）概述

• Par是Parallel的缩写，New：只能处理的是新生代。


• ParNew收集器则是Serial收集器的多线程版本。


• ParNew 收集器除了采用并行回收的方式执行内存回收外，两款垃圾收集器之间几乎没有任何区别。ParNew收集器在年轻代中同样也是采用复制算法、"stop-the-World"机制。


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

（2）ParNew GC比Serial GC 更高效？

• ParNew收集器运行在多CPU的环境下，由于可以充分利用多CPU、多核心等物理硬件资源优势，可以更快速地完成垃圾收集，提升程序的吞吐量。


• 但是在单个CPU的环境下，ParNew收集器不比Serial收集器更高效。虽然Serial收集器是基于串行回收，但是由于CPU不需要频繁地做任务切换，因此可以有效避免多线程交互过程中产生的一些额外开销。


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

（3）参数

• 在程序中，开发人员可以通过选项"-XX:+UseParNewGC"手动指定使用ParNew收集器执行内存回收任务。它表示年轻代使用并行收集器，不影响老年代。


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

6、Parallel GC：吞吐量优先

（1）概述

• Java8的默认垃圾收集器。


• Parallel GC同样也采用了复制算法、并行回收和"Stop the World"机制。


• Parallel 收集器在JDK1.6时提供了用于执行老年代垃圾收集的Parallel old收集器，用来代替老年代的Serial old收集器。采用了标记-压缩算法，但同样也是基于并行回收和"stop-the-World"机制。


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


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

（2）参数

• -XX：+UseParallelGC ，手动指定年轻代使用Parallel并行收集器执行内存回收任务。


• -XX：+UseParallelOldGC，手动指定老年代都是使用并行回收收集器。


• 分别适用于新生代和老年代。默认jdk8是开启的。


• 上面两个参数，默认开启一个，另一个也会被开启。（互相激活)


• -XX:ParallelGCThreads设置年轻代并行收集器的线程数。一般地，最好与CPU数量相等,以避免过多的线程数影响垃圾收集性能。


• 当CPU数量小于8个，ParallelGCThreads 的值等于CPU 数量。


• 当CPU数量大于8个，ParallelGCThreads 的值等于3+[5*CPU_Count]/8]。


• -XX:MaxGCPauseMillis 设置垃圾收集器最大停顿时间(即STW的时间)。单位是毫秒。


• 为了尽可能地把停顿时间控制在MaxGCPauseMills以内，收集器在工作时会调整Java堆大小或者其他一些参数。


• 对于用户来讲，停顿时间越短体验越好。但是在服务器端，我们注重高并发，整体的吞吐量。所以服务器端适合Parallel，进行控制。


• 该参数使用需谨慎。


• -XX:GCTimeRatio垃圾收集时间占总时间的比例(= 1/ (N + 1))。用于衡量吞吐量的大小。


• 取值范围（0,100）。默认值99，也就是垃圾回收时间不超过1%。


• 与前一个-XX:MaxGCPauseMillis参数有一定矛盾性。暂停时间越长，Radio参数就容易超过设定的比例。


• -XX:+UseAdaptiveSizePolicy设置Parallel Scavenge收集器具有自适应调节策略


• 在这种模式下，年轻代的大小、Eden和Survivor的比例、晋升老年代的对象年龄等参数会被自动调整，已达到在堆大小、吞吐量和停顿时间之间的平衡点。使用ParallelGC的情况下，不管是否开启了UseAdaptiveSizePoLicy参数，默认Eden与Survivor的比例都为:6:1:1


• 在手动调优比较困难的场合，可以直接使用这种自适应的方式，仅指定虚拟机的最大堆、目标的吞吐量(GCTimeRatio）和停顿时间（MaxGCPauseMills）,让虚拟机自己完成调优工作。 



• 对于面向外部的大流量、低延迟系统，不建议启用此参数，建议关闭该参数。

  
  

7、CMS：低延迟

1、概述

• 在JDK 1.5时期，HotSpot推出了一款在强交互应用中几乎可认为有划时代意义的垃圾收集器：CMS (Concurrent-Mark-Sweep)收集器，这款收集器是HotSpot虚拟机中第一款真正意义上的并发收集器，它第一次实现了让垃圾收集线程与用户线程同时工作。


• CMS收集器的关注点是尽可能缩短垃圾收集时用户线程的停顿时间。停顿时间越短（低延迟）就越适合与用户交互的程序，良好的响应速度能提升用户体验。
  
  
  
  • 目前很大一部分的Java应用集中在互联网站或者B/S系统的服务端上，这类应用尤其重视服务的响应速度，希望系统停顿时间最短，以给用户带来较好的体验。CMS收集器就非常符合这类应用的需求。
  
  
  
  


• CMS的垃圾收集算法采用标记-清除算法，并且也会”Stop-the-world”


• 在G1出现之前，CMS使用还是非常广泛的。一直到今天，仍然有很多系统使用CMS GC

2、收集过程

1. 初始标记：（会发生STW）暂停时间非常短，标记与GC Roots直接关联的对象。


2. 并发标记：（最耗时）从GC Roots的直接关联对象开始遍历整个对象图的过程，可以与垃圾收集线程一起并发运行。


3. 重新标记：（会发生STW）修复并发标记环节,因为用户线程的执行，导致数据的不一致性问题。


4. 并发清除：（最耗时）此阶段清理删除掉标记阶段判断的已经死亡的对象，释放内存空间。由于不需要移动存活对象，所以这个阶段也是可以与用户线程同时并发的。

3、为什么不使用Mark-Compact标记-压缩？

因为当并发清除的时候，用Compact整理内存的话，原来的用户线程使用的内存还怎么用呢？要保证用户线程能继续执行，前提的它运行的资源不受影响。Mark-Compact更适合“Stop the World”这种场景下使用

4、优缺点

优点：

• 并发收集


• 低延迟

弊端：

• 会产生内存碎片，导致并发清除后，用户线程可用的空间不足。在无法分配大对象的情况下，不得不提前触发Full GC。


• CMS收集器对CPU资源非常敏感。在并发阶段，它虽然不会导致用户停顿，但是会因为古用了一部分线程而导致应用程序变慢，总吞吐量会降低。


• CMS收集器无法处理浮动垃圾。可能出现“Concurrent Mode Failure”失败而导致另一次 Full GC 的产生。在并发标记阶段由于程序的工作线程和垃圾收集线程是同时运行或者交叉运行的，那么在并发标记阶段如果产生新的垃圾对象，CMS将无法对这些垃圾对象进行标记，最终会导致这些新产生的垃圾对象没有被及时回收，从而只能在下一次执行GC时释放这些之前未被回收的内存空间。

5、参数

• -XX:+UseConcMarkSweepGC手动指定使用CMS 收集器执行内存回收任务。
  
  
  
  • 开启该参数后会自动将-XX:+UseParNewGC打开。即:ParNew(Young区用)+CMS(Old区用)+Serial old的组合。
  
  
  
  


• -XX:CMSlnitiatingOccupanyFraction，设置堆内存使用率的阈值，一旦达到该阈值，便开始进行回收。
  
  
  

  • JDK5及以前版本的默认值为68,即当老年代的空间使用率达到68%时，会执行一次CMS 回收。JDK6及以上版本默认值为92%。

    
    
  
  

  • 如果内存增长缓慢，则可以设置一个稍大的值，大的阈值可以有效降低CMS的触发频率，减少老年代回收的次数可以较为明显地改善应用程序性能。反之，如果应用程序内存使用率增长很快，则应该降低这个阈值，以避免频繁触发老年代串行收集器。因此通过该选项便可以有效降低Full GC的执行次数。

    
    
  
  
  
  


• -XX:+UseCMSCompactAtFullCollection，用于指定在执行完Full GC后对内存空间进行压缩整理，以此避免内存碎片的产生。不过由于内存压缩整理过程无法并发执行，所带来的问题就是停顿时间变得更长了。


• -XX:CMSFullGCsBeforeCompaction，设置在执行多少次Full GC后对内存空间进行压缩整理。

6、小结

Serial GC、Parallel GC、CMS GC这三个GC有什么不同呢？请记住以下口令：

• 如果你想要最小化地使用内存和并行开销，请选Serial GC；


• 如果你想要最大化应用程序的吞吐量，请选Parallel GC；


• 如果你想要最小化GC的中断或停顿时间，请选CMS GC。

8、G1 GC：区域化分代式

1、为什么需要G1？

• 为了适应现在不断扩大的内存和不断增加的处理器数量，进一步降低暂停时间（pause time），同时兼顾良好的吞吐量。


• 官方给G1设定的目标是在延迟可控的情况下获得尽可能高的吞吐量，所以才担当起“全功能收集器”的重任与期望。

2、为什么叫G1（Garbage First）？

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


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


• 由于这种方式的侧重点在于回收垃圾最大量的区间（Region)，所以我们给G1一个名字：垃圾优先（Garbage First） 。

3、概述

• G1 是一款面向服务端应用的垃圾收集器，兼顾吞吐量和停顿时间的GC实现。


• 在JDK1.7版本正式启用，是JDK9以后的默认GC选项，取代了CMS回收器。

4、特点

与其他GC收集器相比，G1使用了全新的分区算法，其特点如下所示：

（1）并行与并发

• 并行性：G1在回收期间，可以有多个GC线程同时工作，有效利用多核计算能力。此时用户线程STW


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

（2）分代收集

• 从分代上看，G1依然属于分代型垃圾回收器，它会区分年轻代和老年代，年轻代依然有Eden区和Survivor区。但从堆的结构上看，它不要求整个Eden区、年轻代或者老年代都是连续的，也不再坚持固定大小和固定数量。


• 将堆空间分为若干个区域（ Region) ,这些区域中包含了逻辑上的年轻代和老年代。


• 和之前的各类回收器不同，它同时兼顾年轻代和老年代。对比其他回收器，或者工作在年轻代，或者工作在老年代

（3）空间整合

• CMS：“标记-清除”算法、内存碎片、若干次GC后进行一次碎片整理


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

（4）可预测的停顿时间模型（即:软实时soft real-time）

这是 G1相对于CMS的另一大优势，G1除了追求低停顿外，还能建立可预测的停顿时间模型，能让使用者明确指定在一个长度为M毫秒的时间片段内，消耗在垃圾收集上的时间不得超过N毫秒。

• 由于分区的原因，G1可以只选取部分区域进行内存回收，这样缩小了回收的范围


• G1跟踪各个Region里面的垃圾堆积的价值大小（回收所获得的空间大小以及回收所需时间的经验值），在后台维护一个优先列表，每次根据允许的收集时间，优先回收价值最大的Region。保证了G1收集器在有限的时间内可以获取尽可能高的收集效率。


• 相比于CMS GC，G1未必能做到CMS在最好情况下的延时停顿，但是最差情况要好很多。

5、缺点

• 相较于CMS，G1还不具备全方位、压倒性优势。比如在用户程序运行过程中，G1无论是为了垃圾收集产生的内存占用（Footprint）还是程序运行时的额外执行负载（Overload）都要比CMS要高。


• 从经验上来说，在小内存应用上CMS的表现大概率会优于G1，而G1在大内存应用上则发挥其优势。平衡点在6-8GB之间。

6、参数

• -XX:+UseG1GC，手动指定使用G1收集器执行内存回收任务。


• -XX:G1HeapRegionSize，设置每个Region的大小。值是2的幂，范围是1MB到32MB之间，目标是根据最小的Java堆大小划分出约2048个区域。默认是堆内存的1/2000。


• -XX:MaxGCPauseMillis，设置期望达到的最大GC停顿时间指标(JVM会尽力实现，但不保证达到)。默认值是200ms


• -XX:ParallelGCThread，设置STW时GC线程数的值。最多设置为8


• -XX:ConcGCThreads，设置并发标记的线程数。将n设置为并行垃圾回收线程数(ParallelGCThreads)的1/4左右。


• -XX:InitiatingHeapOccupancyPercent，设置触发并发GC周期的Java堆占用率阈值。超过此值，就触发GC。默认值是45。

7、操作步骤

第一步：开启G1垃圾收集器

第二步：设置堆的最大内存

第三步：设置最大的停顿时间

G1中提供了三种垃圾回收模式: YoungGC、Mixed GC和Full GC，在不同的条件下被触发。

8、适用场景

• 面向服务端应用，针对具有大内存、多处理器的机器。(在普通大小的堆里表现并不惊喜)


• 在下面的情况时，使用G1可能比CMS好：
  
  
  
  1. 超过50%的Java堆被活动数据占用
  
  
  2. 对象分配频率或年代提升频率变化很大;
  
  
  3. GC停顿时间过长（长于0.5至1秒）。
  
  
  
  


• HotSpot垃圾收集器里，除了G1以外，其他的垃圾收集器使用内置的JVM线程执行GC的多线程操作，而G1 GC可以采用应用线程承担后台运行的GC工作，即当JVM的GC线程处理速度慢时，系统会调用应用程序线程帮助加速垃圾回收过程。

9、分区Region

• 使用G1收集器时，它将整个Java堆划分成约2048个大小相同的独立Region块，每个Region块大小根据堆空间的实际大小而定，整体被控制在1MB到32NB之间，且为2的N次幂，即1MB,2MB,4MB,8MB,16MB,32MB。可以通过-XX:61HeapRegionSize设定。所有的Region大小相同，且在VM生命周期内不会被改变。


• G1垃圾收集器还增加了一种新的内存区域，叫做 Humongous内存区域，如图中的H块。主要用于存储大对象，如果超过1.5个region，就放到H。

设置H的原因：

对于堆中的大对象，默认直接会被分配到老年代，但是如果它是一个短期存在的大对象，就会对垃圾收集器造成负面影响。为了解决这个问题，G1划分了一个Humongous区，它用来专门存放大对象。如果一个H区装不下一个大对象，那么G1会寻找连续的H区来存储。为了能找到连续的H区，有时候不得不启动Full GC。G1的大多数行为都把H区作为老年代的一部分来看待。

10、垃圾回收过程

过程1：年轻代GC

过程2：并发标记过程

过程3：混合回收

过程4：FullGC

11、G1优化建议

年轻代大小：

• 避免使用-Xmn或-XX:NewRatio等相关选项显式设置年轻代大小。


• 固定年轻代的大小会覆盖。

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

• G1 GC的吞吐量目标是90%的应用程序时间和10%的垃圾回收时间。


• 评估G1 GC的吞吐量时，暂停时间目标不要太严苛。目标太过严苛表示你愿意承受更多的垃圾回收开销，而这些会直接影响到吞吐量。

• 优先调整堆的大小让JVM自适应完成。如果内存小于100M，使用串行收集器


• 如果是单核、单机程序，并且没有停顿时间的要求，串行收集器


• 如果是多CPU、需要高吞吐量、允许停顿时间超过1秒，选择并行收集器


• 如果是多CPU、追求低停顿时间，需快速响应（比如延迟不能超过1秒，如互联网应用)，使用并发收集器


• 官方推荐G1，性能高。现在互联网的项目，基本都是使用G1。

1、日志参数

• -verbose:gc，输出gc日志信息，默认输出到标准输出


• -XX:+PrintGC，输出GC日志。类似: -verbose:gc


• -XX:+PrintGCDetails，在发生垃圾回收时打印内存回收详细的日志，并在进程退出时输出当前内存各区域分配情况


• -XX:+PrintGCTimeStamps，输出GC发生时的时间戳


• -XX:+PrintGCDateStamps，输出GC发生时的时间戳（以日期的形式，如2013-05-04T21:53:59.234+0800)


• -XX:+PrintHeapAtGC，每一次GC前和GC后，都打印堆信息


• -Xloggc:表示把GC日志写入到一个文件中去，而不是打印到标准输出中

2、日志分析网站

https://gceasy.io/

原文链接：https://www.cnblogs.com/shiblog/p/15976317.html