垃圾回收器
垃圾回收算法是内存回收的方法论，垃圾回收器是内存回收的实践者。不同的垃圾回收器有不同的特性，并没有一个万能或最好的垃圾回收器，只能根据不同的业务场景选择最合适的垃圾回收器，所以这节就来了解下各个垃圾回收器的特性。
1、Stop The World（STW）
先看看jvm的 “Stop The World” 问题。
1）STW：
可达性分析算法从 GC Roots 集合找引用链时，需要枚举根节点，然后从根节点标记存活的对象，根节点枚举以及整理内存碎片时，都会发生 Stop The World，此时 jvm 会直接暂停应用程序的所有用户线程，然后进行垃圾回收。因为垃圾回收时如果还在继续创建对象或更新对象引用，就会导致这些对象可能无法跟踪和回收、跟节点不断变化等比较复杂的问题，因此垃圾回收过程必须暂停所有用户线程，进入 STW 状态。垃圾回收完成后，jvm 会恢复应用程序的所有用户线程。
所有垃圾回收器都无法避免 STW，只能尽量缩短用户线程的停顿时间。系统停顿期间，无法处理任何请求，所有用户请求都会出现短暂的卡顿。如果因为内存分配不合理或垃圾回收器使用不合理，导致频繁的垃圾回收，而且每次回收系统停顿时间过长，这会让用户体验极差。jvm 最重要的一个优化就是通过合理的内存分配，使用合适的垃圾回收器，使得垃圾回收频率最小、停顿时间最短，避免影响系统正常运行。
2）安全点（Safe Point）：
用户程序执行时并非在代码指令流的任意位置都能够停顿下来开始垃圾收集，而是强制要求必须执行到达安全点后才能够暂停。安全点可以理解成是在代码执行过程中的一些特殊位置，当线程执行到这些位置的时候，说明虚拟机当前的状态是安全的，如果有需要，可以在这个位置暂停。
安全点位置的选取基本上是以“是否具有让程序长时间执行的特征”为标准进行选定的，“长时间执行”的最明显特征就是指令序列的复用，例如方法调用、循环跳转、异常跳转等都属于指令序列复用，所以只有具有这些功能的指令才会产生安全点。
jvm 采用主动式中断的方式，在垃圾回收发生时让所有线程都跑到最近的安全点。主动式中断的思想是当垃圾回收需要中断线程的时候，不直接对线程操作，仅仅简单地设置一个标志位，各个线程执行过程时会不停地主动去轮询这个标志，一旦发现中断标志为真时就自己在最近的安全点上主动中断挂起。
3）安全区域（Safe Region）：
安全点机制保证了程序执行时，在不太长的时间内就会遇到可进入垃圾回收过程的安全点。但是，程序“不执行”的时候，线程就无法响应虚拟机的中断请求，如用户线程处于Sleep状态或者Blocked状态，这个时候就没法再走到安全的地方去中断挂起自己。这就需要安全区域来解决了。
安全区域是指能够确保在某一段代码片段之中，引用关系不会发生变化，因此，在这个区域中任意地方开始垃圾回收都是安全的。当用户线程执行到安全区域里面的代码时，首先会标识自己已经进入了安全区域，那样当这段时间里虚拟机要发起垃圾回收时就不必去管这些已声明自己在安全区域内的线程了。当线程要离开安全区域时，它要检查虚拟机是否已经完成了需要暂停用户线程的阶段，如果完成了，那线程就继续执行；否则它就必须一直等待，直到收到可以离开安全区域的信号为止。
2、Serial 垃圾回收器
Serial 垃圾回收器是一个单线程回收器，它进行垃圾回收时，必须暂停其他所有用户线程，直到它回收结束。Serial 主要用于新生代垃圾回收，采用复制算法实现。
服务端程序几乎不会使用 Serial 回收器，服务端程序一般会分配较大的内存，可能几个G，如果使用 Serial 回收器，由于是单线程，标记、清理阶段就会花费很长的时间，就会导致系统较长时间的停顿。
Serial 一般用在客户端程序或占用内存较小的微服务，因为客户端程序一般分配的内存都比较小，可能几十兆或一两百兆，回收时的停顿时间是完全可以接受的。而且 Serial 是所有回收器里额外消耗内存最小的，也没有线程切换的开销，非常简单高效。
3、Serial Old 垃圾回收器
Serial Old 是 Serial 的老年代版本，它同样是一个单线程回收器，主要用于客户端程序。Serial Old 用于老年代垃圾回收，采用标记-整理算法实现。
Serial Old 也可以用在服务端程序，主要有两种用途：一种是与 Parallel Scavenge 回收器搭配使用，另外一种就是作为 CMS 回收器发生失败时的后备预案，在并发收集发生 Concurrent Mode Failure 时使用。
4、ParNew 垃圾回收器
ParNew 回收器实质上是 Serial 回收器的多线程并行版本，除了同时使用多条线程进行垃圾收集之外，其余的行为都与 Serial 回收完全一致，控制参数、回收算法、对象分配规则等都是一致的。除了 Serial 回收器外，目前只有 ParNew 回收器能与 CMS 回收器配合工作，ParNew 是激活CMS后的默认新生代回收器。
ParNew 默认开启的回收线程数与处理器核心数量相同，在处理器核心非常多的环境中，可以使用 -XX: ParallelGCThreads 参数来限制垃圾回收的线程数。
5、Parallel Scavenge 垃圾回收器
Parallel Scavenge是新生代回收器，采用复制算法实现，也是能够并行回收的多线程回收器。Parallel Scavenge 主要关注可控制的吞吐量，其它回收器的关注点是尽可能地缩短垃圾回收时的停顿时间。吞吐量就是处理器用于运行程序代码的时间与处理器总消耗时间的比值，总消耗时间等于运行程序代码的时间加上垃圾回收的时间。
Parallel Scavenge 提供了两个参数用于精确控制吞吐量：
- -XX: MaxGCPauseMillis：控制最大垃圾回收停顿时间，参数值是一个大于0的毫秒数，回收器将尽力保证垃圾回收花费的时间不超过这个值。
- -XX: GCTimeRatio：直接设置吞吐量大小，参数值是一个大于0小于100的整数，就是垃圾回收时间占总时间的比率。默认值为 99，即允许最大1%（即1/(1+99)）的垃圾收集时间。
Parallel Scavenge 还有一个参数 -XX: +UseAdaptiveSizePolicy，当设置这个参数之后，就不需要人工指定新生代的大小、Eden与Survivor区的比例等细节参数了，虚拟机会根据当前系统的运行情况收集性能监控信息，动态调整这些参数以提供最合适的停顿时间或者最大的吞吐量。
6、Parallel Old 垃圾回收器
Parallel Old 是 Parallel Scavenge 的老年代版本，支持多线程并发回收，采用标记-整理算法实现。在注重吞吐量或者处理器资源较为稀缺的场合，可以优先考虑 Parallel Scavenge 加 Parallel Old 这个组合。
7、CMS 垃圾回收器
CMS（Concurrent Mark Sweep）是一种以获取最短回收停顿时间为目标的回收器。CMS 用于老年代垃圾回收，采用标记-清除算法实现。
1）CMS 回收过程：
CMS 垃圾回收总体分为四个步骤：
- 1）初始标记（会STW）：初始标记需要 Stop The World，初始标记仅仅只是标记一下 GC Roots 能直接关联到的对象，速度很快。
- 2）并发标记：并发标记阶段就是从 GC Roots 的直接关联对象开始遍历整个对象引用链的过程，这个过程耗时较长但是不需要停顿用户线程，可以与垃圾回收线程一起并发运行。
- 3）重新标记（会STW）：重新标记需要 Stop The World，重新标记阶段是为了修正并发标记期间，因程序继续运行而导致标记产生变动的那一部分对象的标记记录，这个阶段的停顿时间通常会比初始标记阶段稍长一些，但也远比并发标记阶段的时间短。
- 4）并发清除：清除阶段是清理删除掉标记阶段判断的已经死亡的对象，由于不需要移动存活对象，所以这个阶段也是可以与用户线程同时并发进行的。
- 最耗时的并发标记和并发清除阶段是和用户线程并发进行的，总体上来说，CMS 回收过程是与用户线程一起并发执行的，是一款并发低停顿的回收器。
2）触发CMS的条件
CMS GC 在实现上分成 foreground collector 和 background collector。
① foreground collector
foreground collector 触发条件比较简单，一般是遇到对象分配但空间不够，就会直接触发 GC，来立即进行空间回收。采用的算法是 mark sweep，不压缩。
② background collector
background collector 是通过 CMS 后台线程不断的去扫描，过程中主要是判断是否符合 background collector 的触发条件，一旦有符合的情况，就会进行一次 background 的 collect。每次扫描过程中，先等 CMSWaitDuration 时间（默认2秒），然后再判断是否满足 background collector 的触发条件。
background collector 的触发条件：
- 并行 Full GC，如调用了 System.gc()
- 未配置 UseCMSInitiatingOccupancyOnly 时，会根据统计数据动态判断是否需要进行一次 CMS GC。如果预测 CMS GC 完成所需要的时间大于预计的老年代将要填满的时间，则进行 GC。这些判断是需要基于历史的 CMS GC 统计指标，第一次 CMS GC 时，统计数据还没有形成，是无效的，这时会跟据 Old Gen 的使用占比来判断是否要进行 GC。
- 未配置 UseCMSInitiatingOccupancyOnly 时，判断 CMS 的使用率大于 CMSBootstrapOccupancy（默认50%）时触发 Old GC。
- 老年代内存使用率阀值超过 CMSInitiatingOccupancyFraction（默认为92%）时触发 OldGC，CMSInitiatingOccupancyFraction 默认值为 -1，没有配置时默认阀值为 92%。
未配置 UseCMSInitiatingOccupancyOnly 时，因为分配对象时内存不足导致的扩容等触发GC
③ CMS参数设置
在没有配置 UseCMSInitiatingOccupancyOnly 参数的情况下，会多出很多种触发可能，一般在生产环境会配置 UseCMSInitiatingOccupancyOnly 参数，配了之后就不用设置 CMSBootstrapOccupancy 参数了。
CMSInitiatingOccupancyFraction 设置得太高将会很容易导致频繁的并发失败，性能反而降低；太低又可能频繁触发CMS background collector，一般在生产环境中应根据实际应用情况来权衡设置。
-XX:+UseConcMarkSweepGC -XX:CMSInitiatingOccupancyFraction=92 -XX:+UseCMSInitiatingOccupancyOnly -XX:CMSBootstrapOccupancy=92 -xx:CMSWaitDuration=2000
3）CMS 的问题：
① 并发回收导致CPU资源紧张：
在并发阶段，它虽然不会导致用户线程停顿，但却会因为占用了一部分线程而导致应用程序变慢，降低程序总吞吐量。CMS默认启动的回收线程数是：（CPU核数 + 3）/ 4，当CPU核数不足四个时，CMS对用户程序的影响就可能变得很大。
② 无法清理浮动垃圾：
在CMS的并发标记和并发清理阶段，用户线程还在继续运行，就还会伴随有新的垃圾对象不断产生，但这一部分垃圾对象是出现在标记过程结束以后，CMS无法在当次收集中处理掉它们，只好留到下一次垃圾收集时再清理掉。这一部分垃圾称为“浮动垃圾”。
③ 并发失败（Concurrent Mode Failure）：
由于在垃圾回收阶段用户线程还在并发运行，那就还需要预留足够的内存空间提供给用户线程使用，因此CMS不能像其他回收器那样等到老年代几乎完全被填满了再进行回收，必须预留一部分空间供并发回收时的程序运行使用。默认情况下，当老年代使用了 92% 的空间后就会触发 CMS 垃圾回收，这个值可以通过 -XX: CMSInitiatingOccupancyFraction 参数来设置。
这里会有一个风险：要是CMS运行期间预留的内存无法满足程序分配新对象的需要，就会出现一次“并发失败”（Concurrent Mode Failure），这时候虚拟机将不得不启动后备预案：Stop The World，临时启用 Serial Old 来重新进行老年代的垃圾回收，这样一来停顿时间就很长了。
④ 内存碎片问题：
CMS是一款基于“标记-清除”算法实现的回收器，这意味着回收结束时会有内存碎片产生。内存碎片过多时，将会给大对象分配带来麻烦，往往会出现老年代还有很多剩余空间，但就是无法找到足够大的连续空间来分配当前对象，而不得不提前触发一次 Full GC 的情况。
为了解决这个问题，CMS收集器提供了一个 -XX:+UseCMSCompactAtFullCollection 开关参数（默认开启），用于在 Full GC 时开启内存碎片的合并整理过程，由于这个内存整理必须移动存活对象，是无法并发的，这样停顿时间就会变长。还有另外一个参数 -XX:CMSFullGCsBeforeCompaction，这个参数的作用是要求CMS在执行过若干次不整理空间的 Full GC 之后，下一次进入 Full GC 前会先进行碎片整理（默认值为0，表示每次进入 Full GC 时都进行碎片整理）。
8、G1 垃圾回收器
G1（Garbage First）回收器采用面向局部收集的设计思路和基于Region的内存布局形式，是一款主要面向服务端应用的垃圾回收器。G1设计初衷就是替换 CMS，成为一种全功能收集器。G1 在JDK9 之后成为服务端模式下的默认垃圾回收器，取代了 Parallel Scavenge 加 Parallel Old 的默认组合，而 CMS 被声明为不推荐使用的垃圾回收器。G1从整体来看是基于 标记-整理 算法实现的回收器，但从局部（两个Region之间）上看又是基于 标记-复制 算法实现的。
1）可预期的回收停顿时间
G1 可以指定垃圾回收的停顿时间，通过 -XX: MaxGCPauseMillis 参数指定，默认为 200 毫秒。这个值不宜设置过低，否则会导致每次回收只占堆内存很小的一部分，回收器的回收速度逐渐赶不上对象分配速度，导致垃圾慢慢堆积，最终占满堆内存导致 Full GC 反而降低性能。
G1之所以能建立可预测的停顿时间模型，是因为它将 Region 作为单次回收的最小单元，即每次回收到的内存空间都是 Region 大小的整数倍，这样可以有计划地避免在整个Java堆中进行全区域的垃圾回收。G1会去跟踪各个Region的垃圾回收价值，价值即回收所获得的空间大小以及回收所需时间的经验值，然后在后台维护一个优先级列表，每次根据用户设定允许的回收停顿时间，优先处理回收价值收益最大的那些Region。这种使用Region划分内存空间，以及具有优先级的区域回收方式，保证了G1回收器在有限的时间内得到尽可能高的回收效率。
由于Region数量比传统回收器的分代数量明显要多得多，因此G1回收器要比其他的传统垃圾回收器有着更高的内存占用负担。G1至少要耗费大约相当于Java堆容量10%至20%的额外内存来维持回收器工作。
2）G1内存布局
G1不再是固定大小以及固定数量的分代区域划分，而是把堆划分为多个大小相等的Region，每个Region的大小默认情况下是堆内存大小除以2048，因为JVM最多可以有2048个Region，而且每个Region的大小必须是2的N次冥。每个Region的大小也可以通过参数 -XX:G1HeapRegionSize 设定，取值范围为1MB～32MB，且应为2的N次幂。
G1也有新生代和老年代的概念，不过是逻辑上的区分，每一个 Region 都可以根据需要，作为新生代的Eden空间、Survivor空间，或者老年代空间。新生代默认占堆内存的5%，但最多不超过60%，这个默认值可以使用 -XX:G1NewSizePercent 参数设置，最大值可以通过 -XX:G1MaxNewSizePercent 参数设置。新生代 Region 的数量并不是固定的，随着使用和垃圾回收会动态的变化。同样的，G1新生代也有 eden 区和 survivor 区的划分，也可以通过 -XX:SurvivorRatio 设置其比例，默认为8。
3）大对象Region
Region中还有一类特殊的 Humongous 区域，专门用来存储大对象，而不是直接进入老年代的Region。G1认为一个对象只要大小超过了一个Region容量的一半就判定为大对象。而对于那些超过了整个Region容量的超级大对象，将会被存放在N个连续的 Humongous Region 之中，G1的大多数行为都把 Humongous Region 作为老年代的一部分来看待。
4）G1 回收过程
G1 回收器的运作过程大致可分为四个步骤：
- 1）初始标记（会STW）：仅仅只是标记一下 GC Roots 能直接关联到的对象，并且修改TAMS指针的值，让下一阶段用户线程并发运行时，能正确地在可用的Region中分配新对象。这个阶段需要停顿线程，但耗时很短，而且是借用进行Minor GC的时候同步完成的，所以G1收集器在这个阶段实际并没有额外的停顿。
- 2）并发标记：从 GC Roots 开始对堆中对象进行可达性分析，递归扫描整个堆里的对象图，找出要回收的对象，这阶段耗时较长，但可与用户程序并发执行。当对象图扫描完成以后，还要重新处理在并发时有引用变动的对象。
- 3）最终标记（会STW）：对用户线程做短暂的暂停，处理并发阶段结束后仍有引用变动的对象。
- 4）清理阶段（会STW）：更新Region的统计数据，对各个Region的回收价值和成本进行排序，根据用户所期望的停顿时间来制定回收计划，可以自由选择任意多个Region构成回收集，然后把决定回收的那一部分Region的存活对象复制到空的Region中，再清理掉整个旧Region的全部空间。这里的操作涉及存活对象的移动，必须暂停用户线程，由多条回收器线程并行完成的。
5）G1新生代回收
根据G1的内存布局举个例子，例如：设置堆内存 4G，就是 4096M，除以2048个Region，每个Region就是2M；新生代期初占5%，就是约100个Region，此时eden区占80个Region，两个survivor区各占10个Region；不过随着对象的在新生代分配，属于新生代的Region会不断增加，eden和survivor对应的Region也会不断增加。直到新生代占用60%，也就是约1200个Region，就会触发新生代的GC，这个时候就会采用复制算法将eden对应Region存活的对象复制到 from survivor 对应的Region。只不过这里会根据用户期望的停顿时间来选取部分最有回收价值的Region进行回收。
6）G1混合回收
G1有一个参数，-XX:InitiatingHeapOccupancyPercent，它的默认值是45%，就是如果老年代占堆内存45%的Region的时候，此时就会触发一次年轻代+老年代的混合回收。
混合回收阶段，因为我们设定了最大停顿时间，所以 G1 会从新生代、老年代、大对象里挑选一些 Region，保证指定的时间内回收尽可能多的垃圾。所以 G1 可能一次无法将所有Region回收完，它就会执行多次混合回收，先停止程序，执行一次混合回收回收掉一些Region，接着恢复系统运行，然后再次停止系统运行，再执行一次混合回收回收掉一些Region。可以通过参数 -XX:G1MixedGCCountTarget 设置一次回收的过程中，最后一个阶段最多执行几次混合回收，默认值是8次。通过这种反复回收的方式，避免系统长时间的停顿。
G1还有一个参数 -XX:G1HeapWastePercent，默认值是 5%。就是在混合回收时，Region回收后，就会不断的有新的Region空出来，一旦空闲出来的Region数量超过堆内存的5%，就会立即停止混合回收，即本次混合回收就结束了。
G1还有一个参数 -XX:G1MixedGCLiveThresholdPercent，默认值是85%。意思是回收Region的时候，必须存活对象低于Region大小的85%时才可以进行回收，一个Region存活对象超过85%，就不必回收它了，因为要复制大部分存活对象到别的Region，这个成本是比较高的。
7）回收失败
① 并发回收失败
在并发标记阶段，用户线程还在并发运行，程序继续运行就会持续有新对象产生，也需要预留足够的空间提供给用户线程使用。G1为每一个Region设计了两个名为TAMS（Top at Mark Start）的指针，把Region中的一部分空间划分出来用于并发回收过程中的新对象分配，并发回收时新分配的对象地址都必须要在这两个指针位置以上。G1默认在这个地址以上的对象是被隐式标记过的，即默认它们是存活的，不纳入回收范围。如果内存回收的速度赶不上内存分配的速度，跟CMS会发生并发失败一样，G1也要被迫暂停程序，导致 Full GC 而产生长时间 Stop The World。
② 混合回收失败
混合回收阶段，年轻代和老年代都是基于复制算法进行回收，复制的过程中如果没有空闲的Region了，就会触发失败。一旦失败，就会停止程序，然后采用单线程标记、清理和内存碎片整理，然后空闲出来一批Region。这个过程是很慢的，因此要尽量调优避免混合回收失败的发生。
9、总结对比
1）垃圾回收器间的配合使用
2）各个垃圾回收器对比
10、GC性能衡量指标
一个垃圾收集器在不同场景下表现出的性能也不一样，我们可以借助下面的一些指标来衡量GC的性能。
1）吞吐量
吞吐量是指应用程序所花费的时间和系统总运行时间的比值。系统总运行时间 = 应用程序耗时 +GC 耗时。如果系统运行了 100 分钟，GC 耗时 1 分钟，则系统吞吐量为 99%。GC 的吞吐量一般不能低于 95%。
2）停顿时间
指垃圾收集器正在运行时，应用程序的暂停时间。对于串行回收器而言，停顿时间可能会比较长；而使用并发回收器，由于垃圾收集器和应用程序交替运行，程序的停顿时间就会变短，但其效率很可能不如独占垃圾收集器，系统的吞吐量也很可能会降低。
3）垃圾回收频率
通常垃圾回收的频率越低越好，增大堆内存空间可以有效降低垃圾回收发生的频率，但同时也意味着堆积的回收对象越多，最终也会增加回收时的停顿时间。所以我们只要适当地增大堆内存空间，保证正常的垃圾回收频率即可。
