四、深入理解JVM之垃圾收集（GC）

四、垃圾收集

程序计数器、虚拟机栈、本地方法栈3个区域随线程而生，随线程而灭，在这几个区域内就不需要过多考虑回收的问题，因为方法结束或者线程结束时，内存自然就跟随着回收了。

4.1、判断对象存活

4.1.1、引用计数器法

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

从图中可以看出，如果不下小心直接把 Obj1-reference 和 Obj2-reference 置 null。则在 Java 堆当中的两块内存依然保持着互相引用无法回收。

4.1.1、可达性分析算法

通过一系列的成为“GC Roots”的对象作为起始点，从这些节点开始向下搜索，搜索所走过的路径成为引用链，当一个对象到GC ROOTS没有任何引用链相连时，则证明此对象时不可用的。

Java语言中GC Roots的对象包括下面几种：

• 虚拟机栈（栈帧中的本地变量表）中引用的对象
• 方法区中类静态属性引用的对象
• 方法区中常量引用的对象
• 本地方法栈JNI（Native方法）引用的对象

4.2、引用

下面四种引用强度一次逐渐减弱。

• 强引用就是在程序代码之中普遍存在的，类似Object obj = new Object()这类的引用，只要强引用还存在，垃圾收集器永远不会回收掉被引用的对象。
• 软引用用来描述一些还有用但并非必须的元素。对于它在系统将要发生内存溢出异常之前，将会把这些对象列进回收范围之中进行第二次回收，如果这次回收还没有足够的内存才会抛出内存溢出异常。
• 弱引用用来描述非必须对象的，但是它的强度比软引用更弱一些，被引用关联的对象只能生存到下一次垃圾收集发生之前，当垃圾收集器工作时，无论当前内存是否足够都会回收掉只被弱引用关联的对象。
• 虚引用的唯一目的就是能在这个对象被收集器回收时收到一个系统通知。

4.3、Finalize方法

即使在可达性分析算法中不可达的对象，也并非是“facebook”的，这时候它们暂时出于“缓刑”阶段，一个对象的真正死亡至少要经历两次标记过程：

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

如果这个对象被判定为有必要执行 finalize() 方法，那么这个对象竟会放置在一个叫做 F-Queue 的队列中，并在稍后由一个由虚拟机自动建立的、低优先级的 Finalizer 线程去执行它。这里所谓的“执行”是指虚拟机会出发这个方法，并不承诺或等待他运行结束。finalize() 方法是对象逃脱死亡命运的最后一次机会，稍后 GC 将对 F-Queue 中的对象进行第二次小规模的标记，如果对象要在 finalize() 中成功拯救自己 —— 只要重新与引用链上的任何一个对象简历关联即可。

finalize() 方法只会被系统自动调用一次。

4.4、回收方法区

永久代的垃圾收集主要回收两部分内容：废弃常量和无用的类。

废弃常量：假如一个字符串abc已经进入了常量池中，如果当前系统没有任何一个String对象abc，也就是没有任何Stirng对象引用常量池的abc常量，也没有其他地方引用的这个字面量，这个时候发生内存回收这个常量就会被清理出常量池。

无用的类：

• 该类所有的实例都已经被回收，就是Java堆中不存在该类的任何实例
• 加载该类的ClassLoader已经被回收
• 该类对用的java.lang.Class对象没有在任何地方被引用，无法再任何地方通过反射访问该类的方法

4.5、垃圾收集算法

4.5.1、分代收集算法

只是根据对象存活周期的不同将内存划分为几块。一般是把java堆分为新生代和老年代，这样就可以根据各个年代的特点采用最适当的收集算法。在新生代中，每次垃圾收集时都发现有大批对象死去，只有少量存活，那就选用复制算法，只需要付出少量存活对象的复制成本就可以完成收集。而老年代中因为对象存活率高、没有额外空间对它进行分配担保，就必须使用标记清理或者标记整理算法来进行回收。

4.5.2、标记—清除算法

算法分为标记和清除两个阶段：首先标记出所有需要回收的对象，在标记完成后统一回收所有被标记的对象。

不足：一个是效率问题，标记和清除两个过程的效率都不高；另一个是空间问题，标记清楚之后会产生大量不连续的内存碎片，空间碎片太多可能会导致以后再程序运行过程中需要分配较大的对象时，无法找到足够的连续内存而不得不提前触发另一次垃圾收集动作。

4.5.3、标记整理算法

让所有存活的对象都向一端移动，然后直接清理掉端边界以外的内存。

4.5.4、复制算法

他将可用内存按照容量划分为大小相等的两块，每次只使用其中的一块。当这块的内存用完了，就将还存活着的对象复制到另外一块上面，然后再把已使用过的内存空间一次清理掉。这样使得每次都是对整个半区进行内存回收，内存分配时也就不用考虑内存碎片等复杂情况，只要移动堆顶指针，按顺序分配内存即可。

不足：将内存缩小为了原来的一半

实际中我们并不需要按照1:1比例来划分内存空间，而是将内存分为一块较大的Eden空间和两块较小的Survivor空间，每次使用Eden和其中一块Survivor。

当另一个Survivor空间没有足够空间存放上一次新生代收集下来的存活对象时，这些对象将直接通过分配担保机制进入老年代。

4.6、垃圾收集器

收集算法是内存回收的理论，而垃圾回收器是内存回收的实践。
说明：如果两个收集器之间存在连线说明他们之间可以搭配使用。

4.6.1、Serial收集器

这个收集器是一个单线程的收集器，但它的单线程的意义不仅仅说明它会只使用一个COU或一条收集线程去完成垃圾收集工作，更重要的是它在进行垃圾收集时，必须暂停其他所有的工作线程，直到它收集结束。

4.6.2、ParNew 收集器

Serial收集器的多线程版本，除了使用了多线程进行收集之外，其余行为和Serial收集器一样。

并行（Parallel）指多条垃圾收集线程并行工作，但此时用户线程仍然处于等待状态。

并发（Concurrent）指用户线程与垃圾收集线程同时执行（不一定是并行的，可能会交替执行），用户程序在继续执行，而垃圾收集程序运行于另一个CPU上。

4.6.3、Parallel Scavenge 收集器

收集器是一个新生代收集器，它是使用复制算法的收集器，又是并行的多线程收集器。

吞吐量：就是CPU用于运行用户代码的时间与CPU总消耗时间的比值。即吞吐量=运行用户代码时间/（运行用户代码时间+垃圾收集时间）

4.6.4、Serial Old 收集器

是Serial收集器的老年代版本,是一个单线程收集器，使用标记整理算法。

4.6.5、Parallel Old 收集器

Parallel Old是Paraller Seavenge收集器的老年代版本，使用多线程和标记整理算法。

4.6.6、CMS收集器

CMS (Concurrent Mark Sweep) 收集器是一种以获取最短回收停顿时间为目标的收集器。
CMS收集器是基于标记–清除算法实现的，整个过程分为4个步骤：

• 初始标记(CMS initial mark)：标记 GC Roots 能直接关联到的对象
• 并发标记(CMS concurrent mark)：进行 GC Roots Tracing
• 重新标记(CMS remark)：修正并发标记期间的变动部分
• 并发清除(CMS concurrent sweep)

优点：并发收集、低停顿

缺点：

• CMS收集器对CPU资源非常敏感，CMS默认启动的回收线程数是（CPU数量+3）/4。
• CMS收集器无法处理浮动垃圾，可能出现Failure失败而导致一次Full GC产生。
• CMS是基于标记清除算法实现的。
• 对 CPU 资源敏感、无法收集浮动垃圾、标记 —— 清除 算法带来的空间碎片

4.6.7、G1收集器

它是一款面向服务器应用的垃圾收集器。

运作步骤:

• 初始标记(Initial Marking)
• 并发标记(Concurrent Marking)
• 最终标记(Final Marking)
• 筛选回收(Live Data Counting and Evacuation)

优点：

• 并行与并发：利用多CPU缩短STOP-The-World停顿的时间
• 分代收集
• 空间整合：不会产生内存碎片
• 可预测的停顿

4.6.8、七种垃圾收集器的比较

4.7、内存分配与回收策略

一般来说 Java 堆的内存模型如下图所示：

• 新生代 GC (Minor GC)

发生在新生代的垃圾回收动作，频繁，速度快。

• 老年代 GC (Major GC / Full GC)

发生在老年代的垃圾回收动作，出现了 Major GC 经常会伴随至少一次 Minor GC(非绝对)。Major GC 的速度一般会比 Minor GC 慢十倍以上。

4.7.1、对象优先在Eden分配

大多数情况对象在新生代Eden区分配，当Eden区没有足够空间进行分配时，虚拟机将发起一次Minor GC。

4.7.2、大对象直接进入老年代

所谓大对象就是指需要大量连续内存空间的Java对象，最典型的大对象就是那种很长的字符串以及数组。这样做的目的是避免Eden区及两个Survivor之间发生大量的内存复制。

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

如果对象在Eden区出生并且尽力过一次Minor GC后仍然存活，并且能够被Survivor容纳，将被移动到Survivor空间中，并且把对象年龄设置成为1.对象在Survivor区中每熬过一次Minor GC，年龄就增加1岁，当它的年龄增加到一定程度（默认15岁），就将会被晋级到老年代中。

4.7.1、动态对象年龄判定

为了更好地适应不同程序的内存状况，虚拟机并不是永远地要求对象的年龄必须达到了MaxTenuringThreshold才能晋级到老年代，如果在Survivor空间中相同年龄所有对象的大小总和大于Survivor空间的一半，年龄大于或等于该年龄的对象就可以直接进入到老年代，无须登到MaxTenuringThreshold中要求的年龄。

4.7.1、空间分配担保

在发生Minor GC 之前，虚拟机会检查老年代最大可用的连续空间是否大于新生代所有对象总空间，如果这个条件成立，那么Minor GC可以确保是安全的。如果不成立，则虚拟机会查看HandlePromotionFailure设置值是否允许担保失败。

• 如果允许那么会继续检查老年代最大可用的连续空间是否大于晋级到老年代对象的平均大小，如果大于，将尝试进行一次Minor GC，尽管这次MinorGC 是有风险的。
• 如果小于，或者HandlePromotionFailure设置不允许冒险，那这时也要改为进行一次Full GC。