引言
垃圾在大家的眼里并不陌生，我们称不再在关心，暂时没有可用价值的事物为垃圾。了解过JVM的内存结构后，我们知道了JVM的内存使用率也是限度的，那么如何控制有限的内存，保证Java程序的健壮呢？答案：自然就是垃圾回收咯，在JVM中已经植入了对应的垃圾收集器，并默认配置了。为了系统中更好的发挥不同的收集器的特性，提供更好的服务。我们就来一起认识一下这些垃圾收集器，了解它们的特性与原理。
垃圾回收(Garbage Collection)是Java虚拟机(JVM)垃圾回收器提供的一种用于在空闲时间不定时回收无任何对象引用的对象占据的内存空间的一种机制
如何判断一个对象为垃圾？
判断一个对象是否为垃圾，一般有两种方式：1）引用计数法；2）可达性分析。JVM中使用的是可达性分析。那么我们来认识一下这两种方式吧！
- 引用计数法： 给对象添加一个引用计数器，当对象增加一个引用时计数器加 1，引用失效时计数器减 1。引用计数为 0 的对象可被回收（Python 在用，但主流虚拟机没有使用）
- 优点：快，方便，实现简单
- 缺陷：对象相互引 否该回收
- 可达性分析： 来判定对象是否存活的。这个算法的基本思路就是通过一系列的称为“GC Roots”的对象作为起始点，从这些节点开始向下搜索，搜索所走过的路径称为引用链（Reference Chain），当一个对象到 GC Roots 之间没有任何引用链相连时，则证明此对象是不可用的。
作为 GC Roots 的对象包括下面几种：
1）当前虚拟机栈中局部变量表中的引用的对象
2）方法区中类静态属性引用的对象
3）方法区中的常量引用的对象
GC类型与垃圾回收算法
-
GC分类
- Minor GC
- 特点：发生在新生代上，发生的较为频繁，执行的速度较快。
- 触发条件：
1）Eden区空间不足
2）空间分配担保失败
- Full GC
- 特点：主要发在老年代上（新生代也会回收），较少发生，执行速度较慢
- 触发条件：
1）调用System.gc()
2）老年代区域空间不足
3）空间分配担保失败
4）JDK 1.7及以前的永久代（方法区）空间不足
- Minor GC
-
回收算法
-
复制算法（Copying）
将可用内存按容量划分为大小相等的两块，每次只使用其中的一块。当这一块的内存用完了，就将还存活着的对象复制到另外一块上面，然后再把已使用过的内存空间一次清理掉。这样使得每次都是对整个半区进行内存回收，内存分配时也就不用考虑内存碎片等复杂情况，只要按顺序分配内存即可，实现简单，运行高效。只是这种算法的代价是将内存缩小为了原来的一半。
在新生代中，将内存空间划分为了 Eden 和 Survicor 两块内存区域。其中，Survicor 区又被划分为 Survicor1 和 Survicor2（常说的 From区和 To区）。在 HotSpot 虚拟机中，Eden与Survivor的大小比例是 8:1，也就是每次的内存利用率是90%（80% + 10%），仅有10%的内存会被“浪费”。
- 优点：简单高效，不会出现内存碎片
- 缺点：a）内存利用率低；b）存活对象较多时效率明显降低，因为需要移动每个不可回收数据的内存实际位置。
-
标记-清除算法（Mark-Sweep）
该算法，第一次会遍历所有的对象，为标记对象是可回收还是不可回；第二次，对标记为可回收的对象，执行回收并释放内存资源的操作。
- 优点：利用率100%
- 缺点：a）标记和清除效率都不高（相比复制算法）；b）会产生大量不连续的内存碎片
-
标记-整理算法（Mark-Compact）
首先标记出所有需要回收的对象，在标记完成后，后续步骤不是直接对可回收对象进行清理，而是让所有存活的对象都向一端移动，然后直接清理掉端边界以外的内存。
- 优点：a）利用率100%；b）没有内存碎片
- 缺点：标记和清除效率都不高（对比复制算法及标记清楚算法）
-
垃圾回收器的执行方式
JVM垃圾回收器基于分代管理和回收算法，结合回收的方式，实现了串行回收器、并行回收器、CMS、G1、ZGC和Shenandoah。这些垃圾回收器从程序执行方式的角度可以分为以下3类：
1）串行执行：
应用程序和垃圾回收器交替执行，垃圾回收器执行的时候应用程序暂停执行。串行执行指的是垃圾回收器有且仅有一个后台线程执行垃圾对象的识别和回收。
2）并行执行：
应用程序和垃圾回收器交替执行，垃圾回收器执行的时候应用程序暂停执行。并行执行指的是垃圾回收器有多个后台线程执行垃圾对象的识别和回收，多个线程并行执行。
3）并发执行：
应用程序和垃圾回收器同时运行，除了在某些必要的情况下垃圾回收器需要暂停应用程序的执行，其余的时候在应用程序运行的同时，垃圾回收器的后台线程也运行，如标识垃圾对象并回收垃圾对象所占的空间。
常用垃圾回收器介绍
Serial收集器
Serial收集器是一个基本的，古老的新生代垃圾收集器。这个垃圾收集器是一个单线程的收集器，在它进行垃圾回收的时候，其他的工作线程都会被暂停，直到它收集结束。这也就是说，如果Jvm参数配置有问题或者内存不够，导致频繁的gc，可能每隔一段时间应用就会暂停响应。如果暂停的时间太长，用户就无法接受了，而且这个过程是不可控制的，是虚拟机在后台自动发起和自动完成的。整个运行过程如下所示：
尽管Serial收集器有如此多的缺点，但是从JDK1.3开始到JDK1.7都一直是默认的运行在Client模式下的新生代收集器。原因在于Serial收集器是一个简单高效的收集器，没有线程切换的开销等等，在一般的Client应用中需要回收的内存也不是很大，垃圾回收停顿的时间不是很长，是可以接受的。所以，Serial收集器对于运行在Client模式下的虚拟机来说是一个很好的选择。
ParNew收集器
ParNew收集器是Serial收集器的多线程版本，除了使用多线程进行垃圾收集之外，其余行为包括Serial收集器可用的所有控制参数、收集算法、Stop The World、对象分配规则、回收策略等都与Serial收集器完全一样，它的工作过程如下：
ParNew收集器除了多线程收集之外，其他与Serial收集器相比并没有太多创新之处，但他却是许多运行在Server模式下的虚拟机中首选的新生代收集器，其中有一个与性能无关但很重要的原因是，除了Serial收集器外，目前只有它能与CMS收集器配合工作。
虽然ParNew收集器是多线程收集，但是它的性能并不一定比Serial收集器好。因为线程切换等开销的因素，在单CPU环境中它的性能是不如Serial收集器的，就算有2个CPU也不一定能说绝对比Serial好。但是随着CPU核数的增多，其最终效果肯定是优于Serial收集器的。
ParNew收集器默认会开启与CPU相同数量的线程来进行垃圾收集，可以通过-XX:ParallelGCThreads参数来限制垃圾收集的线程数。
Parallel Scavenge收集器
Parallel Scavenge收集器是一个新生代收集器，它也是使用复制算法的收集器，也是并行的多线程收集器。看上去与ParNew收集器类似，实际上它们的关注点并不一样。
ParNew收集器主要关注的是回收内存的速度，尽可能地缩短垃圾收集时用户线程的停顿时间，而Parallel Scavenge收集器的目标则是达到一个可控制的吞吐量。
停顿时间越短越适合需要与用户交互的程序，而高吞吐量可以高效率地利用CPU时间，尽快完成程序的任务，主要适合在后台运输而不需要太多交互的任务。
Parallel Scavenge收集器提供了两个参数用于精确控制吞吐量，分别是控制最大垃圾收集停顿时间的-XX:MaxGCPauseMillis参数以及直接设置吞吐量大小的-XX:GCTimeRatio参数。如果对Parallel Scavenge收集器不太熟悉，可以设置-XX:+UseAdaptiveSizePolicy，这个参数是一个开关。打开之后不需要手工指定新生代的大小（-Xmn）、Eden与Survivor区的比例（-XX:SuvivorRatio）、晋升老年代对象大小（-XX:PretenureSizeThreshold）等细节参数了，虚拟机会根据当前系统的运行情况收集性能监控信息，动态调整这些参数以提供最合适的停顿时间或者最大的吞吐量。
Parallel Scavenge收集器的工作过程如图所示：
Serial Old收集器
Serial Old是Serial收集器的老年代版本，它同样是一个单线程收集器，使用“标记-整理”算法。这个收集器的主要意义也是在于给Client模式下的虚拟机使用。如果在Server模式下，那么它主要还有两个用途：一种用途是在JDK1.5以及之前的版本中与Parallel Scavenge收集器搭配使用，另一种用途就是作为CMS收集器的后备预案，在并发收集发生Concurrent Mode Failure时使用。Serial Old收集器的工作过程如图所示：
Parallel Old收集器
Parallel Old收集器是Parallel Scavenge收集器的老年代版本，使用多线程和“标记-整理”算法。这个收集器是在JDK1.6中才开始提供的，在此之前，新生代的Parallel Scavenge收集器一直处于比较尴尬的状态。原因是，如果新生代选择Parallel Scavenge收集器，老年代除了Serial Old收集器外别无选择。直到Parallel Old收集器出现后，“吞吐量优先”收集器终于有了比较名副其实的应用组合，在注重吞吐量以及CPU资源敏感的场合，都可以优先考虑Parallel Scavenge加Parallel Old收集器。Parallel Old收集器的工作过程如图所示：
CMS收集器
CMS收集器是一种以获取最短回收停顿时间为目标的收集器。是基于“标记-清除”算法实现的，它的运作过程相对于前面几种收集器来说更复杂一些，分为4个步骤：1）初始标记；2）并发标记；3） 重新标记；4） 并发清除。
其中初始标记和重新标记这两个步骤仍然需要“Stop the world”。初始标记仅仅只是标记一下GC Roots能直接关联到的对象，速度很快，并发标记阶段就是GC Roots Tracing的过程，而重新标记阶段则是为了修正并发标记期间因用户程序继续运作而导致标记产生变动的那一部分对象的标记记录，这个阶段的停顿时间一般会比初始标记阶段稍长一些，但远比并发标记的时间短。
由于整个过程中耗时最长的并发标记和并发清除过程收集器线程都可以与用户线程一起工作，所以，从总体上来说，CMS收集器的内存回收过程是用户线程一起并发执行的。CMS收集器的工作过程如图所示：
CMS是一款优秀的收集器，它的优点有：并发收集、低停顿，但它有以下3个明显的缺点：
- CMS收集器对CPU资源非常敏感。在并发阶段，它虽然不会导致用户停顿，但是会因为占用了一部分线程而导致应用程序变慢，总吞吐量会降低。
- CMS收集器无法处理浮动垃圾，可能出现“Concurrent Mode Failure”失败而导致另一次Full GC的产生。由于CMS并发清理阶段用户线程还在运行着，伴随着程序运行自然就还会有新的垃圾不断产生，这部分垃圾出现在标记过程之后，CMS无法在当次收集中处理掉它们，只好留待下一次GC时再清理掉。这一部分垃圾就称为“浮动垃圾”。
- 最后一个缺点是，CMS是基于“标记-清除”算法实现的收集器，容易产生大量的空间碎片，导致没有足够大的连续空间来分配当前对象，不得不提前触发一次Full GC。
G1 收集器
G1收集器是当今收集器技术发展的最前沿成果之一，是一款面向服务端应用的垃圾收集器，它有如下特点：
- 并行与并发：G1能充分利用多CPU，多核环境下的硬件优势，使用多个CPU来缩短Stop-The-World停顿的时间，部分其他收集器原来需要停顿Java线程执行的GC动作，G1收集器仍然可以通过并发的方式让Java程序继续执行。
- 分代收集：与其他收集器一样，分代概念在G1中依然得以保留。虽然G1可以不需要其他收集器配合就能独立管理整个GC堆，但它能够采用不同的方式去处理新创建的对象和已经存活了一段时间、熬过多次GC的旧对象以获取更好的收集效果。
- 空间整合：与CMS的“标记——清理”算法不同，G1从整体来看是基于“标记——整理”算法实现的收集器，从局部上来看是基于“复制”算法实现的，但无论如何，这两种算法都意味着G1运作期间不会产生内存空间碎片，收集后能提供规整的可用内存。
- 可预测的停顿：这是G1相对于CMS的另一大优势，降低停顿时间是G1和CMS共同的关注点，但G1除了追求低停顿外，还能建立可预测的停顿时间模型，能让使用者明确指定在一个长度为M毫秒的时间片段内，消耗在垃圾收集上的时间不得超过N毫秒。
G1收集器的运作大致可划分为以下几个步骤：1）初始标记；2）并发标记；3）最终标记；4）筛选标记。
初始标记阶段仅仅只是标记一下GC Roots能直接关联到的对象，并且修改TAMS（Next Top at Mart Start）的值，让下一阶段用户程序并发运行时，能在正确可用的Region中创建新对象，这阶段需要停顿线程，但耗时很短。
并发标记阶段是从GC Root开始对堆中对象进行可达性分析，找出存活的对象，这阶段耗时较长，但可与用户程序并发执行。
最终标记阶段则是为了修正在并发标记期间因用户程序继续运作而导致标记产生变动的那一部分，这个阶段需要停顿线程，但是可并行执行。
在筛选回收阶段首先对各个Region的回收价值和成本进行排序，根据用户所期望的GC停顿时间来制定回收计划。
G1收集器的工作过程如图所示：
各个垃圾回收器的协作图
介绍了那么多的垃圾回收器，他们按照各自的特点都有自己的工作范围。这就要求在使用时，我们需要将他们组合起来使用，来换取更高的工作性能。下图列出了常见的垃圾回收器之间的协作图。在使用时，可以参考下图来组合。
目前也涌现了很多新的实验阶段的垃圾回收器（例如ZGC），感兴趣的你可以自己查阅资料区了解。
540
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
