JVM解析——垃圾收集

本系列主要记录笔者在学习 [深入理解Java虚拟机] 一书时的理解
我们都知道在Java中，我们并不需要过多的在意内存的管理，这一切都交给了虚拟机自动管理，我们并不需要操心何时需要去释放一个对象的内存。
当然，如果出现了内存溢出或泄漏，我们就必须去了解一下Java虚拟机的内存管理机制以便于我们解决问题
[笔者仍为Android初学者。如有解释错误的地方，欢迎评论区指正探讨]

本篇为该系列第三篇，介绍虚拟机中常用的垃圾收集机制。

---

我们知道，在Java中，内存的管理主要交给了虚拟机自动管理，这其中就包括了内存分配和内存回收，前面我们也学到，虚拟机中的内存布局分有程序计数器，虚拟机栈，本地方法栈，方法区，堆，而其中程序计数器和虚拟机栈和本地方法栈为线程私有，随着线程的销毁而回收，并不需要过多的关心，方法区虽为全局共享，但一般不会发生内存溢出，不过堆不同，堆频繁的发生对象的创建，也就容易发生异常，垃圾收集主要管理的也真是这部分内存。

判断对象存活

虚拟机在进行垃圾收集之前，需要做的事标记那些对象可以被回收，也就是已死亡，不再被需要。一般而言有两种常见的算法。

引用计数法

这个算法是这样的：给对象中添加一个引用计数器，每当有一个地方引用它时，计数器值就加1；当引用失效时，计数器值就减1；任何时刻计数器为0的对象就是不可能再被使用的。

引用计数法的思想思路很简单，效率也很高，但却存在一个bug，但A引用B，B引用A时，就造成了循环引用，此时两个对象的计数都为1，无法被回收。

在phyon中采用了这种算法，而在Java虚拟机中，并没有采取这种算法，而是采用了另外一种：

可达性分析算法

这个算法的基本思路就是通过一系列的称为“GC Roots”的对象作为起始点，从这些节点开始向下搜索，搜索所走过的路径称为引用链（Reference Chain），当一个对象到GC Roots没有任何引用链相连（用图论的话来说，就是从GC Roots到这个对象不可达）时，则证明此对象是不可用的。

Paste_Image.png

在Java语言中，可作为GC Roots的对象包括下面几种：

1. 虚拟机栈（栈帧中的本地变量表）中引用的对象。
2. 方法区中类静态属性引用的对象。
3. 方法区中常量引用的对象。
4. 本地方法栈中JNI（即一般说的Native方法）引用的对象。

死亡标记

我们知道，虚拟机可以通过上述两种算法来找到可以被杀死的对象，并作好标记，这里一共需要标记两次：

1. 如果对象在进行可达性分析后发现没有与GC Roots相连接的引用链，那它将会被第一次标记并且进行一次筛选，筛选的条件是此对象是否有必要执行finalize（）方法。当对象没有覆盖finalize（）方法，或者finalize（）方法已经被虚拟机调用过，虚拟机将这两种情况都视为“没有必要执行”。

2. 如果这个对象被判定为有必要执行finalize（）方法，那么这个对象将会放置在一个叫做F-Queue的队列之中，并在稍后由一个由虚拟机自动建立的、低优先级的Finalizer线程去执行它。这里所谓的“执行”是指虚拟机会触发这个方法，但并不承诺会等待它运行结束，这样做的原因是，如果一个对象在finalize（）方法中执行缓慢，或者发生了死循环（更极端的情况），将很可能会导致F-Queue队列中其他对象永久处于等待，甚至导致整个内存回收系统崩溃。如果对象要在finalize（）中成功拯救自己——只要重新与引用链上的任何一个对象建立关联即可，譬如把自己（this关键字）赋值给某个类变量或者对象的成员变量，那在第二次标记时它将被移除出“即将回收”的集合；如果对象这时候还没有逃脱，那基本上它就真的被回收了。

垃圾收集算法

了解完判断对象存活的算法之后，我们将进入垃圾收集算法的学习。

标记-清除

如同名字一样，这个算法分为标记和清楚两个阶段：首先标记出所有需要被回收的对象，然后统一回收。这是最基础的垃圾回收算法。
但是他存在两个严重的问题。一个是效率问题，不管是标记还是清楚，效率都不高，另一个是空间问题，清除之后会产生大量内存碎片，导致虚拟机在分配较大的对象时可能找不到足够大的连续内存而触发一次完整的垃圾收集。

标记-清除

复制算法

复制算法将内存划分为等大的两部分，每次只使用其中一部分，当这块内存用完之后之后，将还存活着的对象复制到另一块内存上，再把这块内存一次性全部清除掉，这样使得每次都是对半块区域进行回收，内存分配也不会导致碎片的问题。使得效率十分高效，但同时弊端也很明显，空间利用率十分低下。

复制算法

标记-整理

类似于标记-清除算法，不过该算法并不是直接清除被回收的对象，而是让所有存活的对象向一端移动（比如左上方），然后清除端边界外的内存。

标记整理

分代收集算法

当前商业虚拟机的垃圾收集都采用分代收集算法，其实没有什么特别的地方，只是根据对象的生命周期，将内存划分为几个区域，一般分为：新生代和老年代，根据各个年代的特点选择适当的算法。

• 新生代
  朝生夕灭的对象，频繁创建和回收的对象。比如某一方法内的局部变量等。
  显然这个时代需要频繁的发生垃圾回收，对效率要求较高，所以适合使用复制算法，前面说到复制算法需要将内存划分成两份，但实际上这样浪费了太多内存，虚拟机将新生代的内存划分为三块，一块较大的Eden和两块较小的Survivor（S0，S1），每次只使用Eden和其中的一块Survivor，当进行回收时，将Eden和正在用的Survivor空间里存活的对象一口气复制到另一块Survivor里。HotSpot虚拟机默认Eden和Survivor的比例为8：1；也就是每次只有10%的内存会被浪费。
  不过，我们并没有办法保证90%(80+10)的空间就足够使用，所以当新生代空间不足时，就需要老年代来进行分配担保，将多余的对象分配到老年代的当中。
  一般而言，我们将发生在新生代的GC称之为Minor GC，发生得非常频繁，回收速度也快。

• 老年代
  相对存活时间较旧的对象，比如单例，缓存对象等。
  老年代因为对象存活率高，适合使用标记-清除或标记-整理算法来进行回收.
  一般而言，我们将发生在老年代的GC称之为Full GC/Major GC，通常而言一次Full GC会伴随着至少一次Minor GC，（但非绝对的）。Major GC的速度一般会比Minor GC慢10倍以上。

回收策略

当虚拟机采用分代收集算法时，那么就需要制定一套策略，什么样的对象属于哪一个时代。

对象优先分配在Eden

大多数情况下，对象会被分配在新生区的Eden。

1. 当Eden的空间不足时，虚拟机将发生一次Minor GC。
2. 将Eden仍然存活的对象复制到S0，清空Eden，此后一段时间里，Minor GC后Eden的对象都会进入S0。
3. 当S0的空间不足时，虚拟机将发生一次Minor GC，将Eden和S0仍然存活的对象复制到S1，清空Eden和S0，此后一段时间里Minor GC后Eden的对象都会进入S1

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

为了区分哪些对象适合老年代哪些对象适合新生代，虚拟机给每个对象设置了一个年龄计数器，每经过一次Minor GC，就为年龄+1，当一个对象的年龄到达设置的阀值（默认15）之后，他就将升级到老年代。
当然为了适应不同程序的不同情况，虚拟机并不是永远的要求对象必须达到阀值才能升级到老年代，如果在Survivor空间中相同年龄所有对象大小的总和大于Survivor空间的一半，年龄大于或等于该年龄的对象就可以直接进入老年代。

大对象直接进入老年代

所谓大对象，指的是需要大量连续空间的Java对象，譬如数组，字符串等，虚拟机遇到这类大对象时，并不会将其分配在Eden区，而是直接进入老年代，所以为了避免Full GC的频繁发生，我们应该尽量避免创建命短的大对象。

分配担保

前面已经提到，Minor GC之后虚拟机会将年龄到达阀值的对象转移到老年代，或者Survivor空间不足时会先老年代申请担保，将多于的对象转移到老年代。那么就存在一个问题，如果老年代的空间不足呢？

1. 在发生Minor GC之前，虚拟机会先检查老年代最大可用的连续空间是否大于新生代所有对象总空间，如果大于，则是安全的。
2. 如果小于那么虚拟机将检查是否允许担保失败，如果不允许，那么进行一次Full GC
3. 如果允许，那么虚拟机将检查老年代的最大可用连续空间是否大于历次升级到老年代的对象的平均大小，如果大于，那么尝试着进行Minor GC
4. 如果小于，那么进行一次Full GC

采取平均大小来进行比对其实是一种动态概率手段，并没有办法保证空间足够使用，Minor GC之后如果发现老年代空间并不够使用，那么还是得进行一次Full GC。之所以不直接进行Full GC，是因为Full GC的速度比较慢，我们应该尽量避免。

垃圾收集器

介绍完垃圾收集算法，我们来认识一下垃圾收集器，垃圾收集器是内存回收的具体表现，每个垃圾收集器都有其特定的收集算法，特性。
在介绍垃圾收集器之前，我们需要先了解一下并发和并行的概念：

• 并行
  指多条垃圾收集线程同时进行，此时用户线程处于暂停状态
• 并发
  指用户线程和垃圾收集线程同时运行。

一般而言，我们可以把收集器分成两种：

1. 新生代收集器

2. 老年代收集器

一般采用一个新生代收集器搭配一个老年代收集器来实现分代收集，特殊的G1收集器可以单独使用。

垃圾收集器

Serial收集器

Serial收集器是最基本最悠久的收集器，顾名思义，这是个单线程收集器，他只会开启一条垃圾收集线程，且必须暂停用户线程。显然这个收集器简单而高效，在某些单线程工作的环境下是一个好选择。

Serial收集器收集流程

ParNew收集器

ParNew收集器是Serial收集器的多线程版本，除了使用多线程进行垃圾收集外，其他方面基本与Serial无异，这是并行的收集器。
ParNew在单CPU的环境下，并不如Serial收集器，因为他存在线程交互的开销。
尽管ParNew并没有太多突出创新，但它却是许多运行在Server模式下的虚拟机中首选的新生代收集器，一个关键原因是，除了Serial收集器，目前只有他可以和CMS收集器（后面会介绍）搭配使用。

ParNew收集器收集流程

Parallel Scavange收集器

Parallel Scavange收集器也是一个多线程的新生代收集器，算法也采用了复制算法，看上去和ParNew差不多，他们的区别在于ParNew收集器侧重于缩短垃圾收集时用户线程的停顿时间，而Parallel Scavange收集器更加侧重于控制吞吐量，所谓吞吐量就是CPU用于运行用户代码的时间与CPU总消耗时间的比值，即吞吐量=运行用户代码时间/（运行用户代码时间+垃圾收集时间）。

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

Serial Old收集器

Serial收集器的老年代版本，同样是单线程收集器。
这个收集器的主要意义也是在于给Client模式下的虚拟机使用。如果在Server模式下，那么它主要还有两大用途：一种用途是在JDK 1.5以及之前的版本中与Parallel Scavenge收集器搭配使用[1]，另一种用途就是作为CMS收集器的后备预案。

SerialOld收集器收集流程

Parallel Old收集器

Parallel收集器是Parallel Scavange收集器的老年代版。没有什么特殊的地方，一般搭配Parallel old使用。

ParallelOld收集器收集流程

CMS收集器

CMS收集器是一种以获取最短回收停顿时间为目标的收集器，同时也是一个并发收集器。目前很大一部分的Java应用集中在互联网站或者B/S系统的服务端上，这类应用尤其重视服务的响应速度，希望系统停顿时间最短，以给用户带来较好的体验。CMS收集器就非常符合这类应用的需求。

CMS收集器收集流程

CMS收集器对比前面几种收集器来说，更加复杂一些，整个收集过程分为4个步骤：

1. 初始标记
   标记一下GC Root能直接关联到的对象，速度很快。
2. 并发标记
   遍历GC Root，时间较长
3. 重新标记
   修正并发标记期间因用户程序继续运作而导致标记产生变动的那一部分对象的标记记录。
4. 并发清除
   清除回收内存，时间较长。

整个过程，初始标记和重新标记过程是需要停止用户线程的，但是这两个步骤执行得比较快，而耗时较长的并发标记和并发清除过程则是并发的，用户线程并不会暂停。

CMS是一款优秀的收集器，它的主要优点在名字上已经体现出来了：并发收集、低停顿。
当然，他也存在一定的缺点：

1. CMS收集器对CPU资源非常敏感，在并发阶段，它虽然不会导致用户线程停顿，但是会因为占用了一部分线程（或者说CPU资源）而导致应用程序变慢，总吞吐量会降低。CMS默认启动的回收线程数是（CPU数量+3）/4，也就是当CPU在4个以上时，并发回收时垃圾收集线程不少于25%的CPU资源，并且随着CPU数量的增加而下降。但是当CPU不足4个（譬如2个）时，CMS对用户程序的影响就可能变得很大，如果本来CPU负载就比较大，还分出一半的运算能力去执行收集器线程，就可能导致用户程序的执行速度忽然降低了50%，其实也让人无法接受。

2. CMS收集器无法处理浮动垃圾（Floating Garbage），可能出现“Concurrent Mode Failure”失败而导致另一次Full GC的产生。由于CMS并发清理阶段用户线程还在运行着，伴随程序运行自然就还会有新的垃圾不断产生，这一部分垃圾出现在标记过程之后，CMS无法在当次收集中处理掉它们，只好留待下一次GC时再清理掉。这一部分垃圾就称为“浮动垃圾”。也是由于在垃圾收集阶段用户线程还需要运行，那也就还需要预留有足够的内存空间给用户线程使用，因此CMS收集器不能像其他收集器那样等到老年代几乎完全被填满了再进行收集，需要预留一部分空间提供并发收集时的程序运作使用。

3. CMS作为一个老年代收集器，采用的是标记清除算法，前面我们也有提到，这种算法容易产生大量空间碎片。

G1收集器

G1收集器是当今收集器技术里最前沿的成果之一，G1是一款面向服务端应用的垃圾收集器。

G1收集器收集流程

• 并行与并发：G1能充分利用多CPU、多核环境下的硬件优势，使用多个CPU（CPU或者CPU核心）来缩短Stop-The-World停顿的时间，部分其他收集器原本需要停顿Java线程执行的GC动作，G1收集器仍然可以通过并发的方式让Java程序继续执行。
• 分代收集：与其他收集器一样，分代概念在G1中依然得以保留。虽然G1可以不需要其他收集器配合就能独立管理整个GC堆，但它能够采用不同的方式去处理新创建的对象和已经存活了一段时间、熬过多次GC的旧对象以获取更好的收集效果。
• 空间整合：与CMS的“标记—清理”算法不同，G1从整体来看是基于“标记—整理”算法实现的收集器，从局部（两个Region之间）上来看是基于“复制”算法实现的，但无论如何，这两种算法都意味着G1运作期间不会产生内存空间碎片，收集后能提供规整的可用内存。这种特性有利于程序长时间运行，分配大对象时不会因为无法找到连续内存空间而提前触发下一次GC。
• 可预测的停顿：这是G1相对于CMS的另一大优势，降低停顿时间是G1和CMS共同的关注点，但G1除了追求低停顿外，还能建立可预测的停顿时间模型，能让使用者明确指定在一个长度为M毫秒的时间片段内，消耗在垃圾收集上的时间不得超过N毫秒，这几乎已经是实时Java（RTSJ）的垃圾收集器的特征了。

在G1之前的其他收集器进行收集的范围都是整个新生代或者老年代，而G1不再是这样。使用G1收集器时，Java堆的内存布局就与其他收集器有很大差别，它将整个Java堆划分为多个大小相等的独立区域（Region），虽然还保留有新生代和老年代的概念，但新生代和老年代不再是物理隔离的了，它们都是一部分Region（不需要连续）的集合。

G1收集器之所以能建立可预测的停顿时间模型，是因为它可以有计划地避免在整个Java堆中进行全区域的垃圾收集。G1跟踪各个Region里面的垃圾堆积的价值大小（回收所获得的空间大小以及回收所需时间的经验值），在后台维护一个优先列表，每次根据允许的收集时间，优先回收价值最大的Region（这也就是Garbage-First名称的来由）。这种使用Region划分内存空间以及有优先级的区域回收方式，保证了G1收集器在有限的时间内可以获取尽可能高的收集效率。

和CMS的过程很相似，G1的大致流程可以分为一下几个步骤：

1. 初始标记
   初始标记仅仅是标记一下GC Root能直接关联的对象，并标记一个TAMS（Next Top At Mark Start）值，让下一阶段用户程序并发运行时，能在正确可用的Region中创建新对象，这阶段需要停顿用户线程，但耗时很短。
2. 并发标记
   可达性分析，遍历GC Root，耗时较长，但是并发的。
3. 最终标记
   修正并发标记期间因用户程序继续运作而导致标记产生变动的那一部分对象的标记记录。需要停顿用户线程。
4. 筛选回收
   筛选回收内存，这个阶段是需要停顿用户线程的，但是从Sun公司透漏的消息来看，这里也可以和CMS一样并发回收，但是因为只回收一部分Region，时间是用户可控制的，而且停顿用户线程将大幅提高收集效率。

小结

介绍了几种垃圾收集算法和垃圾收集器，相信大家对于垃圾回收有了更加深入的认识，不过，这么多种算法和收集器，其实都各有各的优势，不存在最优一说，应根据不同场景选择不同的算法和收集器。