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

一、概述
  为什么我们要了解 GC 和 内存分配呢？因为需要排查内存溢出、内存泄露问题时，当垃圾收集成为系统达到更高并发量的瓶颈时，我们就需要对这些“自动化”的技术实施监控和调节。
  从Java运行时数据区的各个部分看，其中程序计数器，虚拟机栈，本地方法栈3个区域随线程生而生，随线程灭而灭；栈中的栈帧随方法的进入和退出有条不紊的进行着入栈和出栈操作。每一个栈帧分配多少内存基本在类结构确定下来就已知，因此这3部分的内存分配和回收具备确定性，所以这几部分内存不用过多考虑回收问题，因为方法或线程结束时，内存自然就被回收了。
  Java 堆和方法区则不一样，一个接口中的多个实现类需要的内存不一样，一个方法中的多个分支需要的内存也可能不一样，我们只有在程序运行期间才知道会创建那些对象，这部分内存的分配和回收都是动态的，来及回收也关注的是这部分内存，因此后面讨论的内存分配与回收也仅指这部分内存。
二、对象的存活
  垃圾收集器在对堆回收前，首先要判断对象是否还存活。
1. 引用计数算法
  算法思想：给对象添加一个引用计数器，每当有一个地方引用它时，计数器值就加1；当引用失效时，计数器的值就减1；任何时刻计数器为0的对象就是不可能再被使用的。
   客观的说，这是一个实现简单，判定效率也很高的算法，比如微软的COM技术，Python语言等被广泛应用的Squirrel中都使用了引用计数算法进行内存管理。但是，主流的Java 虚拟机里面没有选用 引用计数算法来管理内存，主要原因是很难解决对象之间相互循环引用的问题。
例如：

/**
* testGC 执行后，objA和objB会不会被回收呢？
*/
public class ReferenceCountingGC{
    public Object instance = null;
    private static final int _1MB = 1024*1024;
    //此成员属性存在的意义就是占点内存，便于GC日志中清楚的看到是否回收过
    private byte[] bigSize = new byte[2*_1MB];

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

        objA = null;
        objB = null;
        /**
            此时没有了栈中的引用，只用堆内的两个对象相互引用，objA和objB能否被回收？
        */
        System.gc();
    }
}

运行结果：objA和objB被回收，也表示了Java虚拟机使用的不是引用计数算法。如果使用引用计数算法，则objA和objB 不会被回收。

2.可达性分析算法（Reachability Analysis）
  算法思想：通过一系列的称为“GC Roots”的对象作为起始点，从这些节点开始向下搜索，搜索走过的路径称为引用链（Reference Chain），当一个对象到 GC Roots 没有任何引用链相连（用图论来说，就是 GC Roots到这个对象不可达）时，则证明此对象是不可用的，此时该不可达对象会被回收。如下图所示，对象object5、object6、object7 虽有关联，但是可回收的对象。

在Java语言中，可作为 GC Roots 的对象包含下面几种：
  ①. 虚拟机栈（栈帧中的本地变量表）中引用的对象。
  ②. 方法区中类静态属性引用的变量。
  ③. 方法区中常量引用的对象。
  ④. 本地方法栈中JNI（即一般说的Native方法）引用的对象。
3. 再谈引用
  无论是通过“引用计数算法”还是通过“可达性分析算法”，判断对象存活都与“引用”有关。在JDK1.2 之前，Java中的引用定义很传统：如果Reference类型的数据存储的数值代表的是另一块内存的起始地址，就称这块内存代表一个引用。这种定义下一个对象就只有引用与被引用两种状态，对于如何描述一些“食之无味，弃之可惜”的对象就显得无能为力。
  我们希望能描述这样一类对象：当内存空间足够时，则保留在内存之中；如果内存空间在垃圾收集之后还是非常紧张，则可抛弃这些对象。在JDK 1.2 之后，Java对引用进行了扩充，将引用分为强引用（Strong Reference），软引用（Soft Reference），弱引用（Weak Reference），虚引用（Phantom Reference） 4种，引用强度依次减弱。
  ①. 强引用在程序中普遍存在，类似“Object obj = new Object()”这类的引用，只要强引用存在，垃圾收集器永远不会回收被引用的对象。
  ②. 软引用用来描述一些还有用但非必需的对象。对于软引用关联着的对象，系统会在发生内存溢出之前，将这些对象列进回收范围之中进行第二次回收。如果这次回收还没有足够的内存，才会抛出内存溢出异常。。在JDK 1.2之后，提供 SoftReference类来实现软引用。
  ③. 弱引用也是用来描述非必需的对象，它的引用强度比软引用更弱一些，被弱引用关联的对象只能生存到下一次垃圾收集发生之前。当垃圾收集器工作时，无论当前内存是否足够，都会回收掉只被弱引用关联的对象。。在JDK 1.2之后，提供 WeakReference类来实现软引用。
  ④. 虚引用被称为幽灵引用或幻影引用，它是最弱的一种引用关系。一个对象是否有虚引用的存在，完全不会影响它的生存时间，也不能通过虚引用来取得一个对象的实例。为一个对象设置虚引用关联的唯一目的就是 在这个对象被收集器回收时收到一个系统通知。。在JDK 1.2之后，提供 PhantomReference类 来实现软引用。
4. 生存还是死亡
  即使是可达性分析算法中不可达的对象，也并非是“非死不可”。这时候他们暂处“缓刑”阶段，要真正宣告一个对象死亡，至少要经历两次标记过程：如果对象在进行可达性分析后发现不可达，那它将会被第一次标记并且进行一次筛选。筛选的条件是此对象是否有必要执行 finalize() 方法。当对象没有覆盖 finalize() 方法，或者 finalize() 方法已经被虚拟机调用过，虚拟机将这两种情况都视为“没有必要执行”。
  如果这个对象被判定为有必要执行 finalize() 方法，那么这个对象将会被放在一个叫做 F-Queue 的队列之中，并在稍后由一个由虚拟机自动建立的、低优先级的 Finalizer线程去执行它。这个“执行”是指虚拟机会触发这个方法，但并不承诺会等待它运行结束，因为如果一个对象在 finalize()方法中执行缓慢，或者发生了死循环（极端情况），将可能会导致 F-Queue 队列的其他对象处于永久等待，甚至整个回收系统崩溃。finalize()方法是对象逃离死亡命运的最后一次机会，稍后 GC 将对 F-Queue 中的对象进行第二次小规模的标记，如果对象要在 finalize() 中成功拯救自己—–只要重新与引用链上任何一个对象关联即可，例如将自己（this关键字）赋值给某个对象的成员变量或类变量，那第二次标记时他将被移除“即将回收”的集合；如果此时对象还没有逃脱，他就真的被回收了。。。一会来个总结。

/**
* 此代码演示2点：
* 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:(

两段相同代码，执行结果却是一次逃脱成功，一次失败，原因是任何一个对象的 finalize()方法都只会被系统调用一次。

生存还是亡总结：
  任何一个对象宣告死亡，至少要经历两次标记过程:
当对象不可达，进行第一次标记并进行一次筛选，筛选判断是否有必要执行 finalize()方法<被虚拟机调用过、对象没有覆盖finalize()，此时不用执行>， 若有必要执行 finalize()方法，则去执行，此时是队形最后一次自救，否则被回收。

5. 回收方法区
   很多人认为方法区（或者HotSpot虚拟机中的永久代）是没有垃圾收集的，JVM规范中也说过不要去在方法区实现垃圾收集，而且方法区实现垃圾收集效率很低。在堆中，尤其在新生代中，一次一般可回收70%~90%的空间。
   永久代的垃圾收集只要回收两部分内容：废弃常量和无用的类。回收废弃常量与回收Java堆中对象非常类似（不存在被引用的情况，废弃常量在内存回收时将被回收）。常量池中其他类（接口）、方法、字段的符号引用也与此类似。
  判断一个常量是废弃常量比较简单，判断一个类是“无用的类”则苛刻的多。类同时需要满足一下三个条件才算是无用的类：
  ①. 该类的所有实例都已被回收。
  ②. 加载该类的 ClassLoader已经被回收。
  ③. 该类对象的 java.lang.Class 对象没有在任何地方被引用，无法在任何地方通过反射访问该类的方法。
  满足以上3个条件才“可以”对类进行回收。是否对类进行回收，HotSpot虚拟机提供了 -Xnoclassgc 参数进行控制，还可以使用 -verbose:class 以及 -XX:+TraceClassLoading、-XX:+TraceClassUnLoading 查看类加载和卸载信息，其中 -verbose:class 和 -XX:+TraceClassLoading 可以在Product 版的虚拟机中使用，-XX:+TraceClassUnLoading 参数需要在 FastDebug版的虚拟机支持。
   在大量使用反射、动态代理、CGLib 等 ByteCode框架、动态生成 JSP 以及 OSGi 这类频繁自定义 ClassLoader 的场景都需要 VM具备类卸载功能，以保证永久代不会溢出。
三、垃圾收集算法
  垃圾收集算法涉及大量的程序细节，而且各平台虚拟机操作内存的方法又各不相同，因此接下来只介绍几种算法的思想及其发展过程。
1. 标记 – 清除算法
  最基础的收集算法是“标记 – 清除”算法，算法分为“标记”和“清除”两个阶段：首先标记出所有需要回收的对象，在标记完成后统一回收所有被标记的对象，标记过程在上面已经讲过了。之所以说他是最基础的收集算法，是因为后续的算法都是基于这个思路并进行改进而得到的。
  不足有两个：一个是效率问题，标记和清除两个过程的效率都不高；另一个是空间问题，标记清除之后会产生大量不连续的内存碎片，空间碎片太多会导致以后在程序运行过程中需要分配较大对象时，无法找到足够的连续内存而不得不提前触发另一次垃圾收集动作。

2. 复制算法（回收新生代很有效）
  为了解决效率问题，一种称为“复制”的算法出现了。它将可用内存分为容量大小相等的两块，每次只使用其中的一块。当这一块的内存用完了，就将存活着的对象复制到另一块上面，然后再把已使用过的内存一次性清理掉。这样使得每次都是对半个区进行内存回收，内存分配时也不用考虑内存碎片等复杂情况，只要移动堆顶指针，按顺序分配内存即可，实现简单，运行高效。这种算法将内存缩小为原来的一半，代价有点太高。

  现在的商业 VM都采用这种收集算法来回收新生代（堆内存），IBM公司研究表明，新生代中的对象98%都是“朝生夕死”，因此不用按 1:1划分内存空间，而是将内存分为一块较大的 Eden 空间和两块较小的 Survivor 空间，每次使用 Eden 和其中一个 Survivor。当回收时，将 Eden 和 Survivor 中还存活的对象一次性的复制到另外一块 Survivor 空间上，最后清理 Eden 和刚才用过的 Survivor 空间。HotSpot VM 默认 Eden 和 Survivor 的大小比例是 8:1，也就是说，每次新生代中可用内存空间为 90%，只有 10% 才会被浪费。当然，在特殊情况下，存活的对象可能超过 10%，当Survivor 空间不够用时，需要依赖其它内存（这里指老年代）进行分配担保（Handle Promotion）。
  当另外一块 Survivor 空间没有足够空间存放上一次新生代收集下来的存活对象时，这些对象将直接通过分配担保机制进入老年代。关于分配担保将在后面垃圾收集器执行规则时详解。
3.标记 – 整理算法（回收老年代很有效）
复制收集算法在对象存货率高时就会进行较多的复制操作，效率会变低，并且有时需要额外的空间进行分配担保，所以在老年代一般不能选用这种算法。
根据老年代的特点，有人提出“标记 – 整理”算法，标记过程与“标记 – 清除”算法一样，后续不是对可回收对象进行清理，而是让存活的对象都向一端移动，然后直接清理掉端边界以外的内存。

4.分代收集算法
当前商业虚拟机的垃圾收集都采用“分代收集”算法，这种算法没有什么新思想，只是根据对象存活周期的不同将内存划分为几块。一般是把 Java堆分成新生代和老年代，这样就可以根据各个年代的特点采用最合适的收集算法。
在新生代中，每次都有大批对象死去，少量存活，就选用复制算法，只需付出少量存活对象的复制成本就可以完成。
老年代中因为对象存活率高、没有额外的空间对它进行分配担保，就采用“标记 – 清理”或“标记 – 整理”算法来进行回收。

未完待续。。。