垃圾收集器与内存分配策略 - 对象已死吗

• Java与C++之间有一堵由内存动态分配和垃圾收集技术所围成的"高墙"，墙外面的人想进去，墙里面的人却想出来

概述

• 垃圾收集器(Garbage Collection)GC
• 1960年诞生于MIT的Lisp是一门真正的使用内存动态分配和垃圾收集技术的语言

• 思考GC需要完成的3件事：

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

• 为什么需要了解GC和内存分配？

  • 但需要排查各种内存溢出、内存泄漏问题时，当垃圾收集成为系统达到更高并发量的瓶颈时，就需要对这些“自动化”的技术实施必要的监控和调节

对象已死吗

• 第一件事情就是要确定这些对象之中哪些还“存活”着，哪些已经“死去”（即不可能再被任何途径使用的对象）

引用计数算法

• 很多教科书判断对象是否存活的算法：

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

• 引用计数法(Reference Counting)的实现简单，判定效率高，案例：

  • 微软的COM(Component Object Model)技术
  • 使用ActionScript 3的FlashPlayer
  • Python 语言和在游戏脚本领域被广泛应用的Squirrel
• 主流Java虚拟机里面没有选用引用计数算法来管理内存。主因：它很难解决对象间相互循环引用的问题

package com.leaf.u_jvm;

/**
 * 引用计数算法的缺陷
 * 
 * testGC()方法执行后，objA、objB会不会被GC呢？
 *
 */
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;
        
        //假设在这行发生GC，objA和objB是否能被回收？
        System.gc();
    }
    
    public static void main(String[] args) {
        ReferenceCountingGC.testGC();
    }
}

• 执行控制台日志：

[GC (System.gc()) [PSYoungGen: 5735K->824K(18944K)] 5735K->832K(62976K), 0.0012368 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
[Full GC (System.gc()) [PSYoungGen: 824K->0K(18944K)] [ParOldGen: 8K->693K(44032K)] 832K->693K(62976K), [Metaspace: 2593K->2593K(1056768K)], 0.0070749 secs] [Times: user=0.06 sys=0.00, real=0.01 secs] 
Heap
 PSYoungGen      total 18944K, used 164K [0x00000000eb180000, 0x00000000ec680000, 0x0000000100000000)
  eden space 16384K, 1% used [0x00000000eb180000,0x00000000eb1a90d0,0x00000000ec180000)
  from space 2560K, 0% used [0x00000000ec180000,0x00000000ec180000,0x00000000ec400000)
  to   space 2560K, 0% used [0x00000000ec400000,0x00000000ec400000,0x00000000ec680000)
 ParOldGen       total 44032K, used 693K [0x00000000c1400000, 0x00000000c3f00000, 0x00000000eb180000)
  object space 44032K, 1% used [0x00000000c1400000,0x00000000c14ad538,0x00000000c3f00000)
 Metaspace       used 2599K, capacity 4486K, committed 4864K, reserved 1056768K
  class space    used 286K, capacity 386K, committed 512K, reserved 1048576K

• 从日志PSYoungGen: 5735K->824K(18944K)] 5735K->832K(62976K)看虚拟机并没有因为这两个对象相互引用就不回收它们，这也从侧面说明虚拟机并不是通过引用计数算法判断对象是否存活

可达性分析算法

• 主流程序语言的主流实现，都是通过可达性分析(Reachability Analysis)来判定对象是否存活

• 基本思路：

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

• Java语言，可作为GC Roots的对象包括：

  • 虚拟机栈(栈帧的本地变量表)中引用的对象
  • 方法区中类静态属性引用的对象
  • 方法区中常量引用的对象
  • 本地方法栈中JNI(即一般说的Native方法)引用的对象

再谈引用

• 引用计数算法和可达性分析算法，判定对象是否存活都与“引用”有关
• JDK1.2以前，引用的定义：如果reference类型的数据中存储的数值代表的是另外一块内存的起始地址，就称这块内存代表着一个引用
• 一个对象在这种定义下只有被引用或者没有被引用两种状态，对于描述“食之无味，弃之可惜”的对象就显得无能为力

• 希望：当内存空间还足够时，则能保留在内存中；如果内存空间在进行垃圾收集后还是非常紧张，则可抛弃这些对象（缓存）
  *　JDK1.2之后，引用分

  • 强引用(Strong Reference)
  • 软引用(Soft Reference)
  • 弱引用(Weak Reference)
  • 虚引用(Phantom Reference)
  • 引用强调依次减弱
• 强引用，类似“Object obj = new Object()”，只要强引用存在，垃圾收集器永远不会回收掉被引用的对象
• 软引用是用来描述一些还有用但并非必需的对象，这类对象在系统将要发生内存溢出异常之前，将会把这些对象列回收范围之中进行第二次回收。如果这次回收还没有足够的内存，才会抛出异常，在JDK1.2之后，提供了SoftReference类来实现软引用
• 弱引用也是用来描述非必需对象的，但是它的强度比软引用更弱一些，被弱引用关联的对象只能生存到下一次垃圾收集之前。当垃圾收集器工作时，无论当前内存是否足够，都会回收掉被弱引用关联的对象。在JDK1.2之后，提供了WeakReference类来实现弱引用
• 虚引用也称为幽灵引用或幻影引用，是最弱的一种引用关系。一个对象是否有虚引用的存在，完全不会对其生存时间构成影响，也无法通过虚引用来取得一个对象实例。为一个对象设置虚引用关联的唯一目的就是能在这个对象被收集器回收时收到一个系统通知。在JDK1.2之后，提供了PhantomReference类来实现虚引用

生存还是死亡

• 即使在可达性分析算法中不可达的对象，也并非是“非死不可”，此时暂处“缓刑”阶段

• 真正宣告一个对象死亡，至少要经历两次标记过程：

  • 如果对象在进行可达性分析后发现没有与GC Roots相连接的引用链，那它将会被第一次标记并且进行一次筛选

    • 筛选的条件是此对象是否有必要执行finalize()方法
    • 当对象没有覆盖finalize()方法，或者finalize()方法已经被虚拟机调用过，虚拟机将这两种情况都视为“没有必要执行”
    • 如果这个对象被判定为有必要执行finalize()方法，那么这个对象将会放置在一个叫F-Queue的队列之中
    • 稍后由一个虚拟机自动建立、低优先级的Finalizer线程去执行它
    • finalize()方法是对象逃脱死亡命运的最后一次机会，稍后GC将对F-Queue中的对象进行第二次小规模的标记

    • 如果对象要在finalize()中成功拯救自己

      • 只有重新与引用链上的任何一个对象建立关联即可
      • 如把自己(this关键字)赋值给某个类变量或者对象的成员变量，那第二次标记时它将被移除出“即将回收”的集合
      • 如果对象这时还没有逃脱，那基本上就真的被回收了

package com.leaf.u_jvm;

/**
 * 一次自我拯救的演示
 * 1.对象可以在被GC时自我拯救
 * 2.这种自救的机会只有一次，因为对象的finalize()方法最多只会被系统自动调用一次
 *  正常运行结果：
 *  finalize method excuted
 *  yes, I am still alive
 *  no, I am dead
 *  
 *  finalize()方法确实执行了，但是第一次拯救成功，第二次失败了
 *  
 *  
 * 注意：这个案例只做演示使用，切记在实际中使用，因为finalize()方法的不确定性很大，它的优先级很低，容易受影响
 * 可以dubug看看运行结果
 * 
 * 可以是try-finally或者其它方式
 */
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 excuted");
        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");
        }
    }
    
    
}

回收方法区

• 很多人认为方法区（或者HotSpot虚拟机中的永久代）是没有垃圾收集的
• Java虚拟机规范确实说过可以不要求虚拟机在方法区实现垃圾收集
• 在方法区中进行垃圾收集的“性价比”一般比较低
• 在堆中，尤其在新生代中，常规应用进行一次垃圾收集一般可以回收70%-95%的空间，而永久代的垃圾收集效率远低于此
• 永久代的垃圾收集：废弃常量和无用的类

• 判定废弃常量

  • 回收废弃常量与回收Java堆中的对象类似
  • 如常量池中的字面量的回收，字符串“abc”进入常量池，没有任何String对象引用常量池中的“abc”常量，这个常量就会被系统清理出常量池
  • 常量池中的其它类(接口)、方法、字段的符号引用也类似

• 判定无用类

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

• 是否对类进行回收，HotSpot虚拟机提供了-Xnoclassgc参数进行控制

  • 可以使用-verbose:class以及-XX:+TraceClassLoading、-XX:+TraceClassUnLoading查看类加载和卸载信息
  • 大量使用反射、动态代理、CGLib等ByteCode框架、动态生成JSP以及OSGI这类频繁自定义ClassLoader的场景都需要虚拟机具备类卸载的功能，以保证永久代不会溢出

引用：《深入理解Java虚拟机：JVM高级特性与最佳实践（第2版）》 - 第三章