垃圾回收器 Krains 2020-08-07

# 评估GC的主要性能指标

吞吐量：运行用户代码的时间占总运行时间的比例（总运行时间=程序运行时间+内存回收时间）
暂停时间：执行垃圾收集时，程序的工作线程被暂停的时间

# 吞吐量vs暂停时间

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

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

不幸的是“高吞吐量”和“低暂停时间”是一对相互竞争的目标（矛盾）。

因为如果选择以吞吐量优先，那么必然需要降低内存回收的执行频率，但是这样会导致GC需要更长的暂停时间来执行内存回收。

相反的，如果选择以低延迟优先为原则，那么为了降低每次执行内存回收时的暂停时间，也只能频繁地执行内存回收，但这又引起了年轻代内存的缩减和导致程序吞吐量的下降。

在设计（或使用）GC算法时，我们必须确定我们的目标：一个GC算法只可能针对两个目标之一（即只专注于较大吞吐量或最小暂停时间），或尝试找到一个二者的折衷。

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

# 7种经典的垃圾回收器

串行回收器：Serial、Serial old
并行回收器：ParNew、Parallel Scavenge、Parallel old
并发回收器：CMS、G1

串行和并行回收器会STW，并发回收器可以在执行垃圾回收的时候执行用户线程。

未来：ZGC

# 7种垃圾收集器的组合关系

按照分代分类

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

各垃圾回收器组合使用说明

其中Serial o1d作为CMS出现"Concurrent Mode Failure"失败的后备预案，即当垃圾产生的速度大于回收的速度时，CMS无法更快的垃圾回收，这时候启用Serial Old停掉用户线程全力做垃圾操作。
红色虚线：由于维护和兼容性测试的成本，在JDK8时将Serial+CMS、ParNew+Serial old这两个组合声明为废弃（JEP173），并在JDK9中完全取消了这些组合的支持（JEP214），即：移除。
绿色虚线：JDK14中：弃用Paralle1 Scavenge和Serialold GC组合（JEP366）
青色虚线：JDK14中：删除CMS垃圾回收器（JEP363）

查看使用的垃圾回收器

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

// 命令行
jps   // 查看运行的java线程
// 查看jvm是否使用了某个参数："+"表示使用了，"-"表示不使用
jinfo -flag 相关垃圾回收器参数 进程ID

# Serial回收器：串行回收

年轻代中：Serial收集器采用复制算法、串行回收和STW机制的方式执行内存回收。老年代中：Serial Old采用标记压缩算法、串行回收和STW机制

这个收集器是一个单线程的收集器，单线程不仅仅说明它只会使用一个CPU或一条收集线程去完成垃圾收集工作，而且在它回收垃圾时，必须要暂停其他所有工作线程，直到它收集结束(STW)。

优点：简单高效，没有线程切换的开销

配置使用Serial回收器，年轻代使用Serial，老年代使用Serial Old

-XX:+UseSerialGC

# ParNew回收器：并行回收

ParNew收集器是Serial收集器的多线程版本，ParNew收集器在年轻代使用的是复制算法、并行回收、STW机制。

对于新生代，回收次数频繁，使用并行方式高效。
对于老年代，回收次数少，使用串行方式节省资源。（CPU并行需要切换线程，串行可以省去切换线程的资源）

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

# Parallel回收器：吞吐量优先

HotSpot的年轻代中除了拥有ParNew收集器是基于并行回收的以外，Parallel Scavenge收集器同样也采用了复制算法、并行回收和"Stop the World"机制。

那么Parallel Scavenge收集器的出现是否多此一举？

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

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

Paralle1收集器在JDK1.6时提供了用于执行老年代垃圾收集的Paralle1o1d收集器，用来代替老年代的serialold收集器。

Parallel old收集器采用了标记-压缩算法，但同样也是基于并行回收和STW机制。

在程序吞吐量优先的场景下，Parallel Scavenge和Parallel Old收集器组合使用，在Server模式下的内存回收性能不错，JDK8中默认的收集器。

Parallel Scavenge回收器的参数设置

// 新生代中使用Parallel Scavenge
-XX:+UseParallelGC 

// 老年代中使用Parallel Old，两个参数相互激活
-XX:+UseParallelOldGC

// 设置年轻代并行收集器的线程数
-XX:+ParallelGCThreads

// 设置垃圾收集器最大停顿时间（即STW的时间），单位毫秒
-XX:MaxGCPauseMillis

// 垃圾收集时间占总时间的比例
-XX:GCTimeRatio

// 设置Parallel scavenge收集器具有自适应调节策略
// 在这种模式下，年轻代的大小、Eden和Survivor的比例、晋升老年代的对象年龄等参数会被自动调整，
// 已达到在堆大小、吞吐量和停顿时间之间的平衡点。
-XX:+UseAdaptivesizepplicy

# CMS回收器：低延时

CMS（Concurrent-Mark-Sweep）收集器采用标记-清除算法，并且也会STW，只是暂停的时间非常短，适合交互性较强的应用上。

CMS垃圾收集的过程分为4个阶段

初始标记（Initial Mark）阶段：这个阶段的任务只是标记出GCRoots能直接关联的对象，因此这个耗时非常短，在标记过程中会出现STW。
并发标记（Concurrent Mark）阶段：从GCRoots直接关联的对象开始遍历出所有与GCRoots间接关联的对象，耗时较长但是不需要停止用户线程。
重新标记（Remark）阶段：在上个阶段中，程序的工作线程和垃圾收集线程同时运行或者交叉运行，因此为了修正并发标记期间，因用户线程继续运作而导致标记产生变动的那一部分对象的标记记录，这个阶段会STW
并发清除（Concurrent Sweep）阶段：该阶段清理删除掉标记阶段判断的已经死亡的对象，释放内存空间。因为使用的是标记-清除算法，不需要移动存活对象，因此可以和用户线程并发执行

由于最耗时的并发标记和并发清除阶段都不需要停止用户线程，所以整体来说是低延时的。

另外在垃圾收集阶段用户线程没有中断，在CMS回收过程中，还应确保应用程序有足够的内存可用，因此当堆内存使用率达到某一阈值时，便要开始回收，要是在回收过程中预留的内存无法满足程序需求，就会出现"Concurrent Mode Failure"，这时候JVM将启动后备预案：临时启动Serial Old收集器来重新进行老年代的垃圾收集，而Serial Old是采用的是单线程、标记整理的方式回收垃圾，因此STW的时间较长。

CMS为什么不使用标记-整理算法？

在并发清理阶段，用户线程是和垃圾收集线程并发执行的，这个时候不能将用户线程正在使用的对象移动，否者就会出错。

优点

并发收集
低延时

缺点

会产生内存碎片，在无法分配大对象的情况下，不得不提前触发FullGC
对 CPU 资源敏感，垃圾收集器会占用一部分线程导致应用程序变慢，导致总体吞吐量降低
CMS收集器无法处理浮动垃圾。在垃圾回收过程中，CMS无法及时处理新产生的垃圾，在并发标记阶段由于程序和垃圾收集线程是同时或者交叉运行的，那么并发标记阶段如果产生新的垃圾对象，在重新标记阶段CMS无法对这些对象打上标记，导致不能够及时回收，而要等到下一次GC才能够回收。

参数设置

// 老年代使用CMS，新生代自动会配置为ParNew垃圾收集器
-XX:+UserConcMarkSweepGC

// 设置堆内存使用率的阈值，一旦达到该阈值，便开始进行回收。JDK5及以前默认是68%，JDK6及以上默认是92%
-XX:CMSInitiatingoccupanyFraction 

// 用于指定在执行完Full GC后对内存空间进行压缩整理，以此避免内存碎片的产生。
-XX：+UseCMSCompactAtFullCollection

//  设置在执行多少次Ful1GC后对内存空间进行压缩整理。
-XX:CMSFullGCsBeforecompaction

// CMS默认启动的线程数是（ParallelGCThreads+3）/ 4，ParallelGCThreads是年轻代并行收集器的线程数。
-XX:ParallelcMSThreads 设置CMS的线程数量。

小结

如果你想要最小化地使用内存和并行开销，请选Serial GC；
如果你想要最大化应用程序的吞吐量，请选Parallel GC；
如果你想要最小化GC的中断或停顿时间，请选CMS GC。

# G1回收器：区域分代化

官方给G1设定的目标是在延迟可控的情况下获得尽可能的吞吐量。