java虚拟机4:jvm GC机制回收 判断对象生死 及 方法区永久代回收条件

heap堆中存放着几乎所有的对象实例,垃圾收集器在堆堆进行回收前,首先要确定这些对象哪些还“活着”,哪些已经“死去”。方法有如下两种:

(1)引用计数法

     算法思想:为对象添加一个引用计数器,每当有一个地方引用该对象时,则该引用计数器值加1,;当引用失效时,则该引用计数器值减1;最后,计数器为0的对象就是不可能再被使用的,也即所谓的“死去”的对象。

    Java中并没有使用这种算法进行GC,最主要的原因是很难解决对象之间的相互循环引用的问题。如下代码:


public class TestReferenceCountingGC {  
      
    public Object obj = null;  
      
    public void testGc(){  
        TestReferenceCountingGC obj1 = new TestReferenceCountingGC();  
        TestReferenceCountingGC obj2 = new TestReferenceCountingGC();  
        obj1.obj = obj2;  
        obj2.obj = obj1;  
        obj1 = null;  
        obj2 = null;  
          
        System.gc();  
    }  
}  


    在上述代码中,obj1和obj2相互引用,除此之外,无其他任何引用,但因为相互引用对方导致引用计数器都不为0,因此无法通知GC收集器回收它们。

(2)根搜索算法

    Java中是使用根搜索算法(GC Roots Tracing)判断对象是否存活的。

    算法思想:选择名为“GC Roots”的对象为起始点,从这些GC Roots节点开始向下搜索,搜索走过的路径称之为引用链(Reference Chain),当一个对象到GC Roots没有任何引用链时(即不可达,两者之间无通路),则认为该对象为不可用的。如下图:

                               

    如上图,Object3和Object4是相互连接的,但和GC Roots无通路,因此Object3和Object4被认为是可回收的对象。

   在Java中,可作为GC Roots的对象有如下:

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

    b、方法区中的常量引用的对象

    c、方法区中的类静态属性引用的对象

    d、本地方法栈中JNI(Native方法)的引用的对象。


在JDK1.2之后,Java对引用的概念进行了扩充,将引用分为强引用(Strong Reference),软引用(Soft Reference),弱引用(Weak Reference),虚引用(Phantom Reference)四种,这四种引用强度依赖逐渐减弱。

(3)jvm引用的分类

    a、强引用(Strong Reference)

          程序代码中普遍存在的,比如Object obj = new Object(),只要存在强引用,GC收集器永远不会回收被引用的对象。

    b、软引用(Soft Reference)

          非必须的对象,是否回收,要看当前内存情况,如果紧张,则进行回收,否则不回收。当程序抛出内存溢出异常时,肯定不存在这种类型的对象。

    c、弱引用(Weak Reference)

          被弱引用关联的对象只能生存到下一次GC发生之前。即每次必被回收。

    d、虚引用(Phantom Reference)

          幽灵引用或者幻影引用,一个对象是否有虚引用的存在不会影响到其生存时间,无法通过虚引用获取对象实例。为一个对象设置虚引用关联的唯一目的是希望能在这个对象被回收时受到一个系统通知。

(4)finalize

     在根搜索算法中,那些不可达的对象,比如上图中的Object3和Object4,并非是“真正死亡”的,主要看如下两次标记过程:

      a、当没有发现引用链时,进行第一次标记,此时进行第一次筛选,条件为此对象是否有必要执行finalize方法。当对象没有覆盖finalize方法,或者finalize方法已经被JVM调用过,此种情况下认为没有必要执行finalize方法。

      b、如果有必要执行finalize方法,此时对象会被放置在一个F-Queue队列中,会有一个优先级比较低的FInalizer线程去执行触发finalize方法。finalize方法是对象真正判定死活的最后一次机会。此时,GC会对队列中的对象进行第二次标记,如果对象在finalize方法中完成了自救,即和GC Roots建立了通路,则在第二次标记时该对象将被移出回收的集合。否则,只能判定对象死了。

     示例:对象自救:


public class TestFinalizeGC {  
    public static TestFinalizeGC obj = null;  
  
    @Override  
    protected void finalize() throws Throwable {  
        super.finalize();  
        System.out.println("finalize method executed");  
        //完成自救  
        TestFinalizeGC.obj = this;  
    }  
      
    public static void main(String[] args) {  
        obj = new TestFinalizeGC();  
        obj = null;  
        //自救  
        System.gc();  
    }  
}  

    执行结果是:finalize method executed

     说明对象可以再GC时完成自救,需要注意的是这种自救只有一次,因为一个对象的finalize方法最多只会被系统自动调用一次。


ps: 




方法区回收


很多人认为方法区(或者HotSpot虚拟机中的永久代)是没有垃圾收集的,Java虚拟机规范中确实说过可以不要求虚拟机在方法区实现垃圾收集,而且在方法区进行垃圾收集的“性价比”一般比较低:在堆中,尤其是在新生代中,常规应用进行一次垃圾收集一般可以回收70%~95%的空间,而永久代的垃圾收集效率远低于此。
 
永久代的垃圾收集主要回收两部分内容:废弃常量和无用的类。
 
先来说说方法区内常量池之中主要存放的两大类常量:字面量和符号引用。字面量比较接近Java语言层次的常量概念,如文本字符串、被声明为final的常量值等。而符号引用则属于编译原理方面的概念,包括下面三类常量:
 
1、类和接口的全限定名
 
2、字段的名称和描述符
 
3、方法的名称和描述符
 
回收废弃常量与回收Java堆中的对象非常类似。以常量池中字面量的回收为例,假如一个字符串“abc”已经进入了常量池中,但是当前系统没有任何一个String对象是叫做“abc”的,换句话说是没有任何String对象引用常量池中的“abc”常量,也没有其他地方引用了这个字面量,如果在这时候发生内存回收,而且必要的话,这个“abc”常量就会被系统“请”出常量池。常量池中的其他类(接口)、方法、字段的符号引用也与此类似。
 
判定一个常量是否是“废弃常量”比较简单,而要判定一个类是否是“无用的类”的条件则相对苛刻许多。类需要同时满足下面3个条件才能算是“无用的类”:
 
1.该类所有的实例都已经被回收,也就是Java堆中不存在该类的任何实例。
 
2.加载该类的ClassLoader已经被回收。
 
3.该类对应的java.lang.Class 对象没有在任何地方被引用,无法在任何地方通过反射访问该类的方法。
 
虚拟机可以对满足上述3个条件的无用类进行回收,这里说的仅仅是“可以”,而不是和对象一样,不使用了就必然会回收。是否对类进行回收,HotSpot虚拟机提供了-Xnoclassgc参数进行控制,还可以使用-verbose:class及-XX:+TraceClassLoading、 -XX:+TraceClassUnLoading查看类的加载和卸载信息。
 
在大量使用反射、动态代理、CGLib等bytecode框架的场景,以及动态生成JSP和OSGi这类频繁自定义ClassLoader的场景都需要虚拟机具备类卸载的功能,以保证永久代不会溢出。




原文地址:https://www.cnblogs.com/signheart/p/14441305.html