JVM学习总结（三）GC

GC的意义

它使得java程序员不再时时刻刻的关注内存管理方面的工作
垃圾回收机制会自动的管理jvm内存空间,将那些已经不会被使用到了的"垃圾对象"清理掉",释放出更多的空间给其他对象使用

判断对象是否可再被使用

GC在堆进行回收前，第一件事就是要确定这些对象之中哪些“存活”着，哪些已经死去（不可能再被使用的），如下两种算法判断

引用计数法算法

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

引用计数算法的实现简单，判定效率也很高，在大部分情况下它都是一个不错的选择，主流的Java虚拟机里面没有选用引用计数算法来管理内存，主要是由于很难解决对象之间的循环引用的问题。

public class LoopReferenceDemo {

    public static void main(String[] args) {
        A a = new A();  // 1
        B b = new B(); // 2
        a.b = b; // 3
        b.a = a; // 4
        a = null; // 5
        b = null; // 6
    }
}

class A {
    public B b;
}

class B {
    public A a;
}

虽然a和b都为null,但是a和b存在循环引用,这样a和b就永远不会被回收

第一行 : TestA的引用计数器加1,TestA的引用数量为1 第二行 : TestB的引用计数器加1,TestB的引用数量为1 第三行 : TestB的引用计数器加1,TestB的引用数量为2 第四行 : TestA的引用计数器加1,TestA的引用数量为2

输入图片说明

第五行 : 将a变量设置为null,不再指向堆中的引用,所以TestA的引用计数器减1,TestA的引用数量为1 第六行 : 将b变量设置为null,不再指向堆中的引用,所以TestB的引用计数器减1,TestB的引用数量为1

结论 : 虽然上面程序将a和b设置为null了,但是在堆中,TestA和TestB还是互相持有对方的引用,引用计数器依然不等于0,这个就称为循环引用,所以说"引用计数器"会存在这个问题,导致这类对象无法被清理掉

输入图片说明

可达性分析算法

主流的商用程序语言的主流实现中，都通过可达性分析（Reachability Analysis）来判断对象是否存活的。

该算法的基本思想是：

将一系列的称为"GC Roots"的对象作为起始点，从这些节点开始向下搜索，搜索所走过的路径称为引用链（Reference Chain）,当一个对象到GC Roots没有任何引用链相连的话则证明对象是不可用的，即可以被回收

输入图片说明

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

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

在Java中,对引用的概念简述如下(引用强度依次减弱) :

强引用 : 这类引用是Java程序中最普遍的,只要强引用还存在，垃圾收集器就永远不会回收掉被引用的对象
软引用 : 用来描述一些非必须的对象,在系统内存不够使用时,这类对象会被垃圾收集器回收,JDK提供了SoftReference类来实现软引用
弱引用 : 用来描述一些非必须的对象,只要发生GC,无论但是内存是否够用,这类对象就会被垃圾收集器回收,JDK提供了WeakReference类来实现弱引用
虚引用 : 与其他几种引用不同,它不影响对象的生命周期,如果这个对象是虚运用,则就跟没有引用一样,在任何时刻都可能会回收,JDK提供了PhantomReference类来实现虚引用

        // 强引用
        Object object = new Object();
        Object[] objects = new Object[100];

        System.out.println("=======================================");

        // 软引用
        SoftReference<String> stringSoftReference = new SoftReference<String>(new String("SoftReference"));
        System.out.println(stringSoftReference.get());
        System.gc();
        System.out.println(stringSoftReference.get());  // 手动GC，因为内存充足，对象不会被回收

        System.out.println("========================================");

        // 弱引用
        WeakReference<String> stringWeakReference = new WeakReference<String>(new String("WeakReference"));
        System.out.println(stringWeakReference.get());
        System.gc();
        System.out.println(stringWeakReference.get()); // 手动GC，对象已被回收，所以返回null

        System.out.println("========================================");

        // 虚引用  为一个对象设置虚引用关联的唯一目的就是能在这个对象被收集器回收时收到一个系统通知， 需要配合引用队列一起使用
        // 当垃圾回收器准备回收一个对象时，如果发现他还有虚引用，就会在回收对象的内存之前，把这个虚引用加入到与之关联的引用队列中
        ReferenceQueue<String> stringReferenceQueue = new ReferenceQueue<>();
        PhantomReference<String> stringPhantomReference = new PhantomReference<>(new String("PhantomReference"), stringReferenceQueue);
        System.out.println(stringPhantomReference.get());

控制台输出：

=======================================
SoftReference
SoftReference
========================================
WeakReference
null
========================================
null

关于Java虚引用的更多使用说明可以参考 https://www.cnblogs.com/follows/p/8810605.html

对象是否可真正回收

实际上，在根搜索算法中，要真正宣告一个对象死亡，至少要经历两次标记过程 :

如果对象在进行根搜索后发现没有与GC Roots相连接的引用链，那它会被第一次标记并且进行一次筛选，筛选的条件是此对象是否有必要执行finalize（）方法
当对象没有覆盖finalize（）方法，或finalize（）方法已经被虚拟机调用过，虚拟机将这两种情况都视为没有必要执行
如果该对象被判定为有必要执行finalize（）方法，那么这个对象将会被放置在一个名为F-Queue队列中，并在稍后由一条由虚拟机自动建立的、低优先级的Finalizer线程去执行finalize（）方法
finalize（）方法是对象逃脱死亡命运的最后一次机会（因为一个对象的finalize（）方法最多只会被系统自动调用一次）, 稍后GC将对F-Queue中的对象进行第二次小规模的标记，如果要在finalize（）方法中成功拯救自己，只要在finalize（）方法中让该对象重引用链上的任何一个对象建立关联即可
而如果对象这时还没有关联到任何链上的引用，那它就会被回收掉

输入图片说明

从上图上看,reference1,2,3都是gc roots

reference1指向instance1,reference2指向instance4,并且instance4又指向了instance6,reference3则指向了instance2

所以说instance1,2,4,6都具有gc roots可达性,是存活着的对象,不会被垃圾回收器回收掉

而instance3,5则不具备gc roots可达性,是不可用对象,将会被垃圾回收器回收掉从上图描述"引用计数器"的图例场景来看,TestA和TestB虽然互相有持有引用,但是并不具备gc roots可达性,所以,在"可达性分析"算法下,是会被垃圾回收器回收掉的

方法区GC

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

永久代主要回收：

废弃常量
无用的类

以常量池中字面量的回收为例，加入一个字符串“abc”已经进入了常量池中，但是没有任何String对象引用常量池中的“abc”常量，也没有其他地方引用了这个字面量，如果这时候发生内存回收，而且必要的话，这个“abc” 常量就会被系统清理出常量池。常量池中的其他类（接口）、方法、字段的符号引用也与此类似

判断为无用的类：

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