JAVA内存系列三之垃圾收集与内存分配原理

垃圾收集器与内存分配策略

一、概述

经过半个多世纪的发展，内存的动态分配和内存回收技术已经相当成熟，一切看起来都进入了“自动化”时代，那为什么还要去了解GC和内存分配？原因就是当需要排查各种内存溢出、内存泄漏问题时，当垃圾收集成为系统达到更高并发量的瓶颈时，就需要对这些“自动化”的技术实施必要的监控和调节。

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

二、对象的存活与否

在堆里面存放着Java中几乎所有的对象实例，在对堆回收之前，第一件事就是要确定其中的对象哪些还“存活”着，哪些已经“死去“（即不可能再被任何途径使用的对象）。

(1)计数算法（Reference Counting）

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

客观地说，引用计数算法的实现简单，判定效率也很高，在大部分情况下是个不错的算法，也有一些著名的案例，如微软公司的COM（Component Object Model）技术、使用ActionScript的FlashPlayer、Python语言和在游戏脚本领域被广泛应用的Squirrel中都使用了计数算法进行内存管理。但是在Java中，主流的JVM没有选用计数算法，因为很难解决对象之间的相互循环引用问题。

举个例子，在下面的testGC()方法中：对象objA和objB都有字段instance，赋值令objA.instance=objB及objB.instance=objA，除此之外，这两个对象再无任何引用，实际上这两个对象已经不可能再被访问，但是因为它们互相引用着对方，导致它们的引用计数都不为0，于是引用计数算法无法通知GC收集器回收它们。

public class ReferenceCountingGC{
public Object instance = null;
private static final int  _1MB = 1024 * 1024;

/**
*  这个成员属性的唯一意义就是占点内存，以便能在GC日志中看清楚是否被回收过
*/
private byte[] bigSize = new byte[2 * _1MB];

private static void testGC(){
ReferenceCountingGC objA = new ReferenceCountingGC();
ReferenceCountingGC objB = new ReferenceCountingGC();
objA.instance = objB;
objB.instance = objA;

objA = null;
objB = null;
//假设在这行发生GC，objA和objB是否能被回收？
System.gc();
}
}

从运行结果中可以清楚看到，GC日志中包含“4603K->210K”，意味着虚拟机并没有因为这两个对象互相引用就不用回收它们，这也从侧面说明虚拟机并不是通过引用计数算法来判断对象是否存活。

(2)可达性分析算法(Reachability Analysis)

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

下图中黑乎乎的是GC Roots

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

a. 虚拟机栈(栈帧中的本地变量表)中引用的对象

b. 方法区中类静态属性引用的对象

c. 方法区中常量引用的对象

d. 本地方法栈中JNI(即一般说的Native方法)引用的对象

(3)对象的生存与死亡

即使在可达性分析算法中不可达的对象，也并非是“非死不可”，这时候它们暂时处于“缓刑”阶段，要真正宣告一个对象死亡，至少要经历两次标记过程。如果对象在进行可达性分析后发现没有与GC Roots相连接的引用链，那它会被第一次标记并且进行一次筛选，筛选的条件是此对象是否有必要执行finalize()方法。当对象没有覆盖finalize()方法，或者finalize()方法已经被虚拟机调用过，虚拟机将这两种情况都视为“没有必要执行”。

如果这个对象被判定为有必要执行finalize()方法，那么这个对象将会放置在一个叫做F-Queue的队列中，稍后由一个由虚拟机自动建立的、低优先级的Finalizer线程去执行它。这里的“执行”是指虚拟机会触发这个方法，但不承诺会等待它运行结束，这样做的原因是，如果一个对象在finalize()方法中执行缓慢，或者发生了死循环(更极端的情况)，将很可能会导致F-Queue队列中的其他对象永久等待，甚至导致整个内存回收系统崩溃。

finalize()方法是对象逃脱死亡的最后一次机会，稍后GC将对F-Queue中的对象进行第二次小规模标记，如果对象要在finalize()中成功解救自己——只要重新与引用链上的任何一个对象建立关联即可，如把自己（this关键字）赋值给某个类变量或者对象的成员变量，那在第二次标记时它将被移出“即将回收”的集合；如果对象此时还没有逃脱，就会被回收。

下面代码展示了一个对象的finalize( )被执行，但是仍然存活。

/**
*  此代码演示了两点：
*  1.对象可以在被GC时自救
*  2.这种自救的机会只有一次，因为一个对象的finalize()方法最多只会被系统自动调用一次
*/
public class FinalizeEscapeGC( ){

public static FinalizeEscapeGC SAVE_HOOK = null;

public void isAlive( ){
System.out.println("yes, i am still alive :)");
}

@Override
protected void finalize( ) throws Throwable{
super.finalize( );
System.out.println("finalize method executed!");
FinalizeEscapeGC.SAVE_HOOK = this;
}

public static void main(String[ ] args) throws Throwable {
SAVE_HOOK = new FinalizeEscapeGC( );

//对象第一次成功拯救自己
SAVE_HOOK = null;
System.gc( );
//因为finalize方法优先级很低，所以暂停0.5秒来等待它
Thread.sleep(500);
if (SAVE_HOOK != null) {
SAVE_HOOK.isAlive( );
} else {
System.out.println("no, i am dead :(");
}

//下面这段代码和上面的相同，但是自救失败
SAVE_HOOK = null;
System.gc( );
//因为finalize方法优先级很低，所以暂停0.5秒来等待它
Thread.sleep(500);
if (SAVE_HOOK != null) {
SAVE_HOOK.isAlive( );
} else {
System.out.println("no, i am dead :(");
}
}
}

运行结果：
finalize method executed！
yes, i am still alive :)
no, i am dead :(

从上面的结果可以看出，SAVE_HOOK对象的finalize方法确实被GC收集器触发过，并且在收集之前成功逃脱了。并且值得关注的是任何对象的finalize方法都只会被系统调用一次，运行代价昂贵，不确定性大，无法保证各个对象之间的调用顺序，所以不建议使用这个方法，用try-finally或者其他方法比较好。

三、Java引用类型

无论是通过引用计数算法判断对象的引用数量，还是通过可达性分析算法判断对象的引用链是否可达，判断对象是否存活都与“引用”有关。从JDK1.2之后，Java对引用的概念进行了扩充，将引用分为强引用，软引用，弱引用，虚引用，这四种引用的强度一次逐渐减弱

强引用（Strong Reference）就是指在程序代码之中普遍存在的，类似 “Object obj = new Object()” 这类的引用，只要强引用还存在，垃圾回收器永远不会回收掉被引用的对象。

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

弱引用（Weak Reference）也是用来描述非必需对象的，但是它的强度比软引用更弱一些，被弱引用关联的对象只能生存到下一次垃圾收集发生之前，当垃圾收集器工作时，无论当前内存是否足够，都会回收掉只被弱引用关联的对象。在JDK1.2之后，提供了WeakReference类来实现弱引用。

虚引用（Phantom Reference）也称为幽灵引用或者幻影引用，它是最弱的一种引用关系，一个对象是否有虚引用的存在，完全不会对其生存时间构成影响，也无法通过虚引用来取得一个对象实例。对一个对象设置虚引用关联的唯一目的就是能在这个对象被收集器回收时收到一个系统通知。在JDK1.2之后，提供了PhantomReference类来实现虚引用。

四、内存分配与回收策略

Java的技术体系中的自动内存管理解决了两个问题：给对象分配内存以及回收分配给对象的内存。以下是几条普遍的内存分配原则。

1.对象优先在Eden分配

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

新生代GC（Minor GC）: 指发生在新生代的垃圾收集动作，因为Java对象大多都具备朝生夕灭的特性，所以Minor GC非常频繁，一般回收速度也很快。

老年代GC（Major GC/Full GC）: 指发生在老年代的GC，出现了Major GC，经常会伴随至少一次的Minor GC，但并非是绝对的，如Parallel Scavenge收集器的收集策略里就有直接进行Major GC的策略选择过程。Major GC的速度一般会比Minor GC慢10倍以上。

2.大对象直接进入老年代

所谓的大对象是指，需要大量连续内存空间的Java对象，最典型的大对象就是那种很长的字符串以及数组。

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

因为虚拟机VM采用了分代收集的思想来管理内存，为了在内存回收时能够识别哪些对象应放在新生代，哪些对象应放在老年代，虚拟机给每个对象定义了一个对象年龄计数器。如果对象在Eden出生并经过第一次Minor GC后仍然存活，并且能被Survivor容纳的话，将被移动到Survivor空间中，并且对象年龄设为1。对象在Survivor区中每度过一次Minor GC，年龄就增加一岁，当它的年龄增加到一定程度（默认15岁），就会被晋升到老年代中。对象晋升老年代的阈值，可以通过参数-XX:MaxTenuringThreshold设置。

4.动态对象年龄判定

为了更好地适应不同程序的内存情况，如果在Survivor空间中相同年龄的所有对象大小的总和大于Survivor空间的一半，年龄大于或等于该年龄的对象就可以直接进入老年代，无须等到MaxTenuringThreshold中要求的年龄。

5.空间分配担保

在发生Minor GC之前，VM会先检查老年代最大可用的连续空间是否大于新生代所有对象的总空间，如果条件成立，那么Minor GC是安全的。若不成立，VM会查看HandlePromotionFailure设置值是否允许担保失败。若允许，那么继续检查老年代最大可用的连续空间是否大于历次晋升到老年代对象的平均大小，如果大于，尝试进行一次Minor GC，但是有风险；如果小于，或者HandlePromotionFailure设置不允许冒险，这时改为进行一次Full GC。