初探JVM GC策略

垃圾收集所要解决的三大问题：

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

---

一、哪些区域需要回收？

java内存模型中，程序计数器、虚拟机栈、本地方法栈三个区域随线程而生，随线程而灭；栈中的栈帧随着方法的进入和退出而有条不紊地执行着入栈和出栈的操作。每一个栈帧中分配多少内存基本上是在类结构确定下来时就已知的（尽管在运行期会由JIT编译器进行一些优化，大体上可以认为是编译期可知的），因此这几个区域的内存分配和回收都具备确定性，在这几个区域内就不需要过多考虑回收的问题，因为方法结束或者线程结束，内存自然就随着回收掉了。

而Java堆和方法区则不一样，一个接口中的多个实现类需要的内存可能不一样，一个方法中的多个分支需要的内存也可能不一样，我们只有在程序运行期间才能知道会创建哪些对象，这部分内存的分配和回收都是动态的，垃圾收集器所关注的是这部分内存。

二、哪些内存需要回收？

垃圾收集器收集的是"死"了的对象，所以第一件要做的事情，就是确定这些对象之中哪些还"存活"着，哪些已经"死去"。那么这个死代表什么？那就是——不可能再被任何途径引用的对象。

这里跳过"引用计数法"的介绍，因为至少主流的Java虚拟机里面没有选用引用计数法来管理内存，最主要的原因是它很难解决对象之间相互循环引用的问题。有兴趣的同学可以去了解一下。

1. 可达性分析算法
在主流的商用程序语言（Java 、C#，甚至包括古老的Lisp）的主流实现中，都是通过可达性分析（Reachability Analysis）来判定对象是否存活。这个算法的基本思想就是通过一系列成为"GC Roots"的对象作为起始点，从这些节点开始往下搜索，搜索走过的路径称为引用链(Reference Chain)，当一个对象到GC Roots没有任何引用链相连接（GC Roots到这个对象不可达）时，则证明这个对象是不可用的。
如图所示，object5与object6虽然相互有关联，但是他们到GC Roots是不可达的，所以它们将会被判定成可回收对象。

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

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

但是，对于可达性分析法搜索不到引用的对象，GC还不一定会回收它们，要完全回收一个对象，至少需要经过两次标记的过程。

第一次标记：对于一个与GC Root没有引用链的对象，筛选该对象是否有必要执行finalize()方法。"没有必要"是指当对象没有覆盖finalize()方法，或者finalize()方法已经被虚拟机调用过。

第二次标记：在第一次标记后，符合"必要执行"的对象将会被放置在一个叫做F-Queue的队列中，稍后GC将会对F-Queue中的对象进行第二次小规模的标记。如果在这次标记中，对象没有与引用链上的任何对象关联，那么基本上他就真的被回收了。

说到引用，那么问题就来了？这里的引用到底是什么意思？

无论是通过引用计数法计算对象的引用数量，还是通过可达性分析算法判断对象的引用链是否可达，判定对象的存活都与引用有关。在JDK1.2之前，Java中引用的定义很传统：
如果refrence类型的数据中存储的数值代表的是另一块内存的起始地址，就称这块内存代表着一个引用。

这种定义很纯粹，但是太狭隘。在这种定义下，一个对象只有被引用或不被引用这两种状态。但是这样不能满足一些可有可无的对象。比如有这么一种对象：

当内存空间还足够的时候，则能保留在内存之中；如果内存空间在进行垃圾回收后还是非常紧张，则可以抛弃这些对象。

故在JDK1.2之后，Java对引用的概念进行了扩充，将引用分为[“强引用”(Strong Reference)，“软引用”(Soft Reference)，“弱引用”(Weak Reference)，“虚引用”(phantom Reference)]，这4种，这4种引用强度依次逐渐减弱。

1. 强引用，就是在程序代码中普遍存在的，类似"Object obj = new Object()"这类的引用，只要强引用存在，垃圾回收器就永远不会回收掉被引用的对象。

2. 软引用，用来描述一些还有用但不是必须的对象。对于软应用关联着的对象，在系统要发生内存溢出异常之前，将会将这些对象列入回收范围之中进行第二次回收。如果第二次回收还没有足够的内存，才会抛出内存溢出异常。提供了SoftReference类来实现弱引用。

3. 弱引用，被弱引用关联的对象只能生存到下一次垃圾回收发生之前。当垃圾收集器工作时，无论当前内存是否足够，都会回收掉只被弱引用关联的对象。提供了WeakReference类来实现弱引用。

4. 虚引用（幽灵引用），最弱的一种引用，一个对象是否有虚引用，完全不对这个对象的生存时间造成影响，也无法通过一个对象的虚引用获得对象实例。为一个对象设置虚引用的唯一目的就是能在这个对象被垃圾回收时收到一个系统通知，提供了PhantomReference类来实现虚引用。

三、何时发生内存回收？

首先要介绍的是两种内存回收类型：
Minor GC：新生代GC，指的是发生在新生代的垃圾收集动作。由于java对象大都是朝生夕死的，所以Minor GC非常平凡，一般回收速度也比较i快。

Major GC/Full GC：老年代GC，指的是发生在老年代的GC，出现Major GC一般经常会伴有Minor GC，Major GC的速度比Minor GC慢的多

再来介绍它们各自什么情况下会发生:

Minor GC: 当创建一个新的对象时，如果年轻代的Eden区无法容纳新的对象，就发生Minor GC。
意外情况：当对象的大小大于-XX:PretenureSizeThreshold大小时，对象不会触发Minor GC，而是直接分配在老年代。

Full GC：Full GC触发的条件比较多，具体有如下场景。

1. 在老年代中直接配分大对象/大数组。在Minor GC 时提到，当创建某个大对象时，Eden区无法分配这么大的空间，会尝试在老年代中分配。但是个时候如果老年代也空间不足时，就会触发Full GC。故不要创建大的对象或数组。
2. 发生Minor GC之前的空间配分担保不通过。虚拟机在发生Minor GC之前，会检查老年代中的最大可用连续空间是否大于年轻代对象总大小或者历次晋升平均大小（空间配分担保），否则进行Full GC。
3. 永久代空间不足。如果堆中还存在永久代的设计，那么当系统要加载的类太多，要反射的类太多，要调用的方法太多时，可能会因为永久代空间不够而发生Full GC。
4. Minor GC时发生HandlePromotionFailure失败。老年代在判断完空间分配担保后，这次的Minor GC不一定会绝对成功，原因是可能发生某一次Minor GC后，从S1晋升上来的对象大小超过了老年代的可用空间的大小（比历史指大），则担保失败，这个时候就会发生Full GC。

四、如何回收？

标记-清除算法

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

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

复制算法

为了解决效率问题，”复制“算法出现了，将可用的内存划分为两块，每次只使用其中一块， 当这一块的内存用完了，就将还存活着的对象复制到另一块上面，然后再把已使用过的内存空间一次清理掉。这样就不用考虑内存碎片等复杂情况。

现在的商业虚拟机都采用这这种收集算法来回收新生代。根据研究表明，新生代中98%的对象都是”朝生夕死“的，所以新生代中将内存分为一块较大的Eden空间和两块较小的Survivor空间（from和to），每次使用Eden和其中一块Survivor，当回收时，将Eden和刚才用过的Survivor中还存活的对象一次性的复制到另外一个Survivor空间上，最后清理掉Eden和刚才用过的Survivor空间。

Hotspot虚拟机默认使用Eden和Survivor的大小比例是8：1，也就是Eden占8，form和to各占1。

当Survivor空间不够的时候，需要依赖老年代进行分配担保。

标记-整理算法

标记整理算法的“标记”过程和标记-清除算法一致，只是后面并不是直接对可回收对象进行整理，而是让所有存活的对象都向一段移动，然后直接清理掉端边界以外的内存。

分代收集算法

当前商业虚拟机的垃圾收集都采用”分代收集“算法，其主要思想是将Java堆分为新生代和老年代，这样就可以根据各个年代的特点采用最适合的收集算法。

在新生代采用复制算法，上面已经讲过了。而老年代因为对象存活率高，没有额外空间为它进行分配担保，就必须使用”标记清理“或者标记整理算法来进行回收。