zoukankan      html  css  js  c++  java
  • 浅析Java中不使用的对象应赋值为null的深层理解:基本没必要的原因、JVM中局部变量表(运行时候的栈状态)和slot(运行时栈里的索引)的理解、Java的栈优化(重用栈索引节约内存空间)、GC的可达性分析算法-如何找到root树根(栈中引用的对象)、如何断开栈中引用与堆的联系(重写栈索引)

      经常听说“不使用的对象应手动赋值为null”,但是要问原因,大都回答“有利于GC更早回收内存,减少内存占用”,但再往深入问就回答不出来了。所以这里做一点深入研究。

    一、将对象赋值为null,对垃圾回收有用吗?

      网上很多java性能优化里都会有这么一条:尽量把不使用的对象显式得置为null,这样有助于内存回收。

      可以明确的说,这个观点是基本没必要的。sun jdk 远比我们想象中的机智,完全能判断出对象是否已经 no ref。但是我上面用的词是"基本",也就是说,有例外的情况。这个例外的情况是:方法前面中有定义大的对象,然后又跟着非常耗时的操作,且没有触发JIT编译。总结这句话就是:

      除非在一个方法中,定义了一个非常大的对象,并且在后面又跟着一段非常耗时的操作,并且该方法没有满足 JIT 编译条件,否则显式得设置 obj = null 是完全没必要的。上面这句话有点绕,但是上面说的每一个条件都是有意义的,这些条件分别是:

    (1)同一个方法中

    (2)定义了一个大对象(小对象没有意义)

    (3)之后跟着一个非常耗时的操作

    (4)没有满足JIT编译条件

      上面4个条件缺一不可,这样把 obj 显式设置成 null 才是有意义的。

    1、同一个方法中:这个条件是最容易理解的,如果大对象定义在其他方法中,那么是不需要设置成Null的。

    public static void main(String[] args){  
            foo();  
            System.gc();  
    }
    
    public static void foo(){  
        byte[] placeholder = new byte[64*1024*1024];  
    }

      其实很好理解:placeholder是foo方法的局部变量,在main方法中调用的时候,其实foo方法对应的栈帧已经结束。那么placeholder指向的大对象自然被gc的时候回收了。

    2、定义了一个大对象:这句话的意思也很好理解,只有定义的是大的对象,我们才需要关心他尽快被回收。如果你只是定义了一个 String str = "abc"; 后续手动设置成null让gc回收是没有任何意义的。

    3、后面跟着一个非常耗时的操作:这里理解是后面的这个耗时的可能超过了一个GC的周期。

    public static void main(String[] args) throws Exception{  
      byte[] placeholder = new byte[64*1024*1024];  
      Thread.sleep(3000l);  
      // dosomething  
    }  

      在线程sleep的三秒内,可能jvm已经进行了好几次gc,但是由于placeholder一直持有这个大对象,所以造成这个64M的大对象一直无法被回收,甚至有可能造成了满足进入old 区的条件。这个时候在sleep之前显式得把placeholder设置成Null是有意义的。但是如果没有这个耗时的操作,main方法可以非常快速的执行结束,方法返回,同时也会销毁对应的栈帧。那么就是回到第一个条件,方法已经执行结束,在下一次gc的时候,自然就会把对应的"垃圾"给回收掉。

      具体分析见这篇文章:https://blog.csdn.net/qq_42945742/article/details/84107531

    二、问题背景

      我们来看一段非常简单的代码:

    public static void main(String[] args) {
        if (true) {
            byte[] placeHolder = new byte[64 * 1024 * 1024];
            System.out.println(placeHolder.length / 1024);
        }
        System.gc();
    }

      我们在 if 中实例化了一个数组 placeHolder,然后在 if 的作用域外通过 System.gc(); 手动触发了GC,其用意是回收 placeHolder,因为placeHolder已经无法访问到了。来看看输出:

    65536
    [GC 68239K->65952K(125952K), 0.0014820 secs]
    [Full GC 65952K->65881K(125952K), 0.0093860 secs]

      Full GC 65952K->65881K(125952K) 代表的意思是:本次GC后,内存占用从65952K降到了65881K。意思其实是说GC没有将placeHolder回收掉,是不是不可思议?下面来看看遵循“不使用的对象应手动赋值为null“的情况:

    public static void main(String[] args) {
        if (true) {
            byte[] placeHolder = new byte[64 * 1024 * 1024];
            System.out.println(placeHolder.length / 1024);
            placeHolder = null;
        }
        System.gc();
    }
    // 其输出为:
    65536
    [GC 68239K->65952K(125952K), 0.0014910 secs]
    [Full GC 65952K->345K(125952K), 0.0099610 secs]

      这次GC后内存占用下降到了345K,即placeHolder被成功回收了!对比两段代码,仅仅将placeHolder赋值为null就解决了GC的问题,为什么 placeHolder 不赋值为null,GC 就“发现不了” placeHolder 该回收呢?这才是问题的关键所在。

    三、运行时栈

    1、典型的运行时栈

      如果你了解过编译原理,或者程序执行的底层机制,你会知道方法在执行的时候,方法里的变量(局部变量)都是分配在栈上的;当然,对于Java来说,new出来的对象是在堆中,但栈中也会有这个对象的指针,和int一样

    public static void main(String[] args) {
        int a = 1;
        int b = 2;
        int c = a + b;
    }

      其运行时栈的状态可以理解成:“索引”表示变量在栈中的序号,根据方法内代码执行的先后顺序,变量被按顺序放在栈中。

    索引变量
    1 a
    2 b
    3 c

      再比如:

    public static void main(String[] args) {
        if (true) {
            int a = 1;
            int b = 2;
            int c = a + b;
        }
        int d = 4;
    }

      这时运行时栈就是:

    索引变量
    1 a
    2 b
    3 c
    4 d

      容易理解吧?其实仔细想想上面这个例子的运行时栈是有优化空间的。

    2、Java的栈优化

      上面的例子,main()方法运行时占用了4个栈索引空间,但实际上不需要占用这么多。当if执行完后,变量a、b和c都不可能再访问到了,所以它们占用的1~3的栈索引是可以“回收”掉的,比如像这样:

    索引变量
    1 a
    2 b
    3 c
    1 d

      变量d重用了变量a的栈索引,这样就节约了内存空间

      上面的“运行时栈”和“索引”是为方便引入而故意发明的词,实际上在JVM中,它们的名字分别叫做“局部变量表”和“Slot”。而且局部变量表在编译时即已确定,不需要等到“运行时”。

      局部变量表用于存放方法中的局部变量和方法参数,局部变量表用 Slot 为单位。jvm在实现的时候为了节省栈帧空间,做了一个简单的优化,就是slot的复用。如果当前字节码的PC计数器已经超出某些变量的作用域,那么这些变量的 slot 就可以给其他的复用。方法的局部变量表大小在javac的时候就已经确定了

    3、如何确定对象可以被 GC 回收

      这里来简单讲讲主流GC里非常简单的一小块,另一种表达是,如何确定对象是存活的。仔细想想,Java的世界中,对象与对象之间是存在关联的,我们可以从一个对象访问到另一个对象。如图所示。

      再仔细想想,这些对象与对象之间构成的引用关系,就像是一张大大的图;更清楚一点,是众多的树。

      如果我们找到了所有的树根,那么从树根走下去就能找到所有存活的对象,那么那些没有找到的对象,就是已经死亡的了!这样GC就可以把那些对象回收掉了。

      现在的问题是,怎么找到树根呢?JVM早有规定,其中一个就是:栈中引用的对象。也就是说,只要堆中的这个对象,在栈中还存在引用,就会被认定是存活的。

      这就是:确定对象可以被回收的算法,其名字是“可达性分析算法”。

      基础知识:

    1、sun jdk的内存垃圾判定是基于根搜索算法的。也就是说在GC root为根,能被搜索到的,就认为是存活对象,搜索不到的,则认为是"垃圾"。

    2、啥是 gc root。

    Local variable. For example, input parameters or locally created objects of methods that are still in the stack of a thread.

      这句话直接翻译就是说是"本地变量,例如方法的参数或者方法中创建的局部变量",如果换一种说法是:Java 方法栈(Java Method Stack)的局部变量表(Local Variable Table)中引用的对象

      在局部变量表的 slot 持有的某个对象,他是无法被垃圾回收的,因为局部变量表本来就是GC Root之一。

    四、JVM的“bug”

      我们再来回头看看最开始没有设置为 null 的例子,看看其运行时栈:

    LocalVariableTable:
    Start  Length  Slot  Name   Signature
        0      21     0  args   [Ljava/lang/String;
        5      12     1 placeHolder   [B

      栈中第一个索引是方法传入参数args,其类型为String[];第二个索引是placeHolder,其类型为byte[]。

      联系前面的内容,我们推断placeHolder没有被回收的原因:System.gc();触发GC时,main()方法的运行时栈中,还存在有对args和placeHolder的引用,GC判断这两个对象都是存活的,不进行回收。也就是说,代码在离开 if 后,虽然已经离开了placeHolder 的作用域,但在此之后,没有任何对运行时栈的读写,placeHolder所在的索引还没有被其他变量重用,所以GC判断其为存活。

      为了验证这一推断,我们在System.gc();之前再声明一个变量,按照之前提到的“Java的栈优化”,这个变量会重用 placeHolder 的索引。

    public static void main(String[] args) {
        if (true) {
            byte[] placeHolder = new byte[64 * 1024 * 1024];
            System.out.println(placeHolder.length / 1024);
        }
        int replacer = 1;
        System.gc();
    }
    // 看看其运行时栈:
    LocalVariableTable:
    Start  Length  Slot  Name   Signature
        0      23     0  args   [Ljava/lang/String;
        5      12     1 placeHolder   [B
       19       4     1 replacer   I

      不出所料,replacer重用了placeHolder的索引。来看看GC情况:

    65536
    [GC 68239K->65984K(125952K), 0.0011620 secs]
    [Full GC 65984K->345K(125952K), 0.0095220 secs]

      placeHolder 被成功回收了!我们的推断也被验证了。

      再从运行时栈来看,加上 nt replacer = 1; 和将 placeHolder 赋值为 null 起到了同样的作用:断开堆中 placeHolder 和栈的联系,让GC判断placeHolder已经死亡。

      现在算是理清了“不使用的对象应手动赋值为null“的原理了,一切根源都是来自于JVM的一个“bug”:代码离开变量作用域时,并不会自动切断其与堆的联系

      需要对局部变量表的重写才会重用 slot,这样才会端开 栈 中的引用与 堆 的联系。为什么这个“bug”一直存在?你不觉得出现这种情况的概率太小了么?算是一个tradeoff(权衡)了。

      看到这里你已经明白了“不使用的对象应手动赋值为null“这句话背后的奥义,正如《深入理解Java虚拟机》作者的观点:在需要“不使用的对象应手动赋值为null”的时大胆去用,但不应当对其有过多依赖,更不能当作是一个普遍规则来推广。

  • 相关阅读:
    Java Web
    对象拷贝
    多线程
    容器
    新鲜出炉一份Java面试清单,共200+道题
    优秀博客
    【安防】自动光圈控制
    【硬件】变压器的电特性参数
    【工作总结】IPD开发管理流程
    【EMC】EMI滤波器
  • 原文地址:https://www.cnblogs.com/goloving/p/15324334.html
Copyright © 2011-2022 走看看