JVM之垃圾收集器

1、概述

垃圾收集器（Garbage Collection），大部分我们都喜欢称之为GC。GC的职责主要围绕三个问题：

• 哪些内存需要回收
• 什么时候回收
• 如何回收

在Java中GC是系统自动完成的，并且在Java中GC只关注Java堆和方法区，因为在这两个区域只有在程序运行期间才知道创建了哪些对象，内存分配和回收都是动态的。而Java虚拟机栈，程序计数器，本地方法栈这几个区域由于内存分配和回收都具有确定性，故GC不需要过多关注这几个区域。

2、对象可回收判定方法

引用计数算法

思路：给对象添加一个计数器，每当一个地方引用它时，计数器就加1；当引用失效时，计数值就减1；任何时刻计数器为0的对象就不可能再被使用，即计数器为0的对象可回收。

缺点：很难解决对象之间相互循环引用的问题

可达性分析算法

思路：从“GC Roots”的对象为起始点，从这些节点向下搜索，所走过的路径称为引用链（Reference Chain），当一个对象到GC Roots没有任何引用链时，即该对象不可达时，则证明该对象是可回收对象。

而在Java中可作为GC Roots的对象有下面四种：

• 虚拟机栈中引用的对象
• native方法引用的对象
• 方法区中类静态属性引用的对象
• 方法区中常量引用的对象

引用

无论是引用计数算法还是可达性分析算法，判定对象是否可回收都与“引用”有关，而引用主要分为四种：

• 强引用：类似 Object obj= new Object()这种引用，只要强引用还在，则对象就不会被回收
• 软引用：有用但非必须的对象。在系统将要发生内存溢出之前，将进行二次回收，如果这次回收还没有足够内存，才会抛出内存溢出异常。
• 弱引用：非必须对象，只能生存到下一次垃圾回收发生之前。当垃圾收集器工作时，无论内存是否足够，都会回收掉只被弱引用关联的对象
• 虚引用：幽灵引用，最弱的引用。唯一目的是能在这个对象被gc时收到一个系统通知。

3、对象死亡

判断对象死亡还是生存的整体流程如下图所示：

关键点：至少两次标记

第一次标记

如果对象在进行可达性分析后发现没有与GC Roots相连接的引用链，则会被第一次标记并进行筛选。筛选的条件是此对象是否有必要执行finalize方法，当对象没有覆盖finalize方法或者finalize已经被虚拟机执行过一次，都认为是没必要执行finalize方法，此时对象死亡，虚拟机将会对该对象进行回收。

第二次标记

如果该对象是有必要执行finalize（）方法，则虚拟机会将该对象放置到F-Queue队列中，并稍后由虚拟机的Finalizer线程执行finalize方法。finalize方法是对象逃脱死亡命运的最后一次机会，稍后GC会对F-Queue中的对象进行第二次标记，如果对象要在finalize中成功拯救自己-只要在finalize方法中重新与引用链上的对象建立关联即可。那么在第二次标记时，该对象将从”即将回收“集合中移除。如果对象这时候还未逃脱，则基本上被回收。

注：任何一个对象的finalize（)方法只会被系统自动调用一次，并且在《深入Java虚拟机第二版》中也建议不使用该方法来拯救对象

4、垃圾收集算法

4.1 标记-清除算法

思路：最基础的收集算法，后续收集算法都基于该算法进行改进。算法分为两个阶段：

• 标记：标记出所有需要回收的对象
• 清除：统一回收所有被标记的对象

标记-清除算法示意图：

不足：一是效率不高；二是标记清除后会产生大量不连续的内存空间，导致以后在分配较大对象时，可能会提前触发GC

4.2 复制算法

思路：将可用的空间划分为两个大小相等的两块，每次只使用其中一块，当这一块用完时，就将当前用完的这块内存的所有存活对象复制到另外一块上面，然后把当前用完的内存一次清理掉。复制算法执行过程如下图：

优点：实现简单，运行高效

缺点：内存缩小为原来的一半，代价较高，并且当存活对象比较多时，要进行较多的复制操作，效率会降低

总结：适用于对象存活率较低的新生代

4.3 标记-整理算法

思路：过程与标记-清除一致，但标记后并不是直接对可回收对象进行清理，而是让所有存活的对象都向一端移动，然后直接清理掉端边界以外的内存。标记-整理执行过程如下图：

总结：适用于对象存活率高的老年代

4.4 分代收集算法

思路：根据各个年代的特点采用最适当的收集算法。

• 新生代：每次GC时有大批对象死亡，只有少量存活，因此适合使用复制算法
• 老年代：对象存活率高，没有额外空间对它进行分配担保，必须使用“标记-整理”算法或者“标记-清除”算法进行回收

5 、垃圾收集器

垃圾收集器是内存回收的具体实现，一个虚拟机可以有多个垃圾收集器，下图为HotSpot虚拟机的垃圾收集器以及组合情况：如果两个收集器之间存在连线，则说明它们可以搭配使用。

5.1 Serial收集器

含义：单线程收集器，在进行垃圾收集时，必须暂停其他所有的工作线程，直到它收集结束

特点：简单高效，是运行在Client模式下的默认新生代的收集器

5.2 ParNew收集器

含义：Serial收集器的多线程版本

特点：运行在Server模式下的虚拟机首选的新生代收集器，除Serial收集器外，目前只有它能与CMS收集器配合工作。

5.3 Parallel Scavenge收集器

含义：使用复制算法、并行多线程、吞吐量优先的新生代收集器

特点：关注点与其他收集器不同，CMS等收集器的关注点是尽可能地缩短垃圾收集时用户线程的停顿时间，Parallel Scavenge收集器的目标则是达到一个可控制的吞吐量（吞吐量=运行用户代码时间/（运行用户代码时间+垃圾收集时间））。

停顿时间越短就越适合需要与用户交互的程序，提升用户体验。高吞吐量可以高效地利用CPU时间，尽快完成程序的运算任务，适用在后台运算而不需要太多交互的任务

5.4 Serial Old收集器

含义：Serial收集器的老年代版本，使用标记-整理算法的单线程收集器

特点：给Client模式下的虚拟机使用，如果在Server模式下，则有两大用途：一种是JDK1.5以前的版本中与Parallel Scavenge收集器搭配使用，另一种是作为CMS收集器的后备预案

5.5 Parallel Old收集器

Parallel Scavenge收集器的老年代版本，JDK1.6后提供。主要使用多线程标记－整理算法。在注重吞吐量以及CPU资源敏感的场合优先考虑Parallel Scavenge+Parallel Old收集器。

5.6 CMS收集器

含义：一种以获取最短回收停顿时间为目标的收集器

特点：基于标记－清除算法，过程分为4个步骤：

• 初始标记
• 并发标记
• 重新标记
• 并发清除

初始标记和重新标记需要“Stop the World”,即停止其它线程。

总结：

• 优点：并发收集，低停顿
• 缺点：对CPU资源非常敏感，无法处理浮动垃圾，基于标记－清除算法，故收集结束会有大量空间碎片产生。

5.7 G１收集器

含义：面向服务端应用的垃圾收集器

特点：并行和并发，分代收集，空间整合，可预测的停顿。运行分为4个步骤：

• 初始标记
• 并发标记
• 最终标记
• 筛选回收

6、内存分配与回收策略

对象的内存分配，大方向讲就是在堆上进行分配，对象主要分配在新生代的Eden区，如果启动了本地线程分配缓冲，则按线程优先在TLAB上分配，少数对象也会直接分配到老年代。根据垃圾收集器的不同组合以及虚拟机内存相关参数的设置，会导致分配策略有所不同，下面为Serial／Serial　Old收集器组合下的内存分配和回收策略。

GC类别：

Minor GC：新生代GC，指发生在新生代的垃圾收集动作

Full GC／Major GC：老年代GC，经常伴随至少一次的Minor GC，Full GC速度一般比Minor GC慢10倍以上

6.1 对象优先在新生代Eden区分配

大多数情况下，对象在新生代的Eden区进行分配，当Eden区没有内存进行分配时，将会进行一次Minor GC。

6.2 大对象直接进入老年代

大对象指的是需要大量连续内存的Java对象，典型代表为很长的字符串以及数组。

应避免创建一群短命大对象，当出现大对象时容易导致内存还有不少空间就提前触发GC以获取足够的连续空间来安置它们

6.3 长期存活的对象进入老年代

每个对象定义了一个对象年龄计数器。如果对象在Eden出生并经历第一次的Minor GC后仍然存活，并且能够被Survivor容纳的话，对象将移到Survivor空间，并且对象年龄计为1。后续对象每经历一次Minor GC后仍然存活，则年龄依次加1。当年龄增大到一定程度时（默认为15岁），该对象将转移到老年代。

对象晋升老年代的年龄可以通过参数设置

6.4 动态对象年龄判定

对象的年龄并非一定要达到阈值才能晋升到老年代。如果Survivor空间中相同年龄所有对象大小的总和大于Survivor空间的一半，则大于或等于该年龄的对象就可以直接进入到老年代。

6.5 空间分配担保

空间分配担保流程图如下：

老年代进行担保的原因：当进行Minor GC时，前提是老年代本身还有容纳这些对象的剩余空间，因为新生代中有多少对象会存活下来在实际完成Minor GC是不知道的，所以只好取之前回收晋升到老年代对象的平均大小作为经验值，与老年代剩余空间进行比较，决定是否进行Full GC来让老年代腾出更多的空间。