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

• 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版）》 - 第三章