zoukankan      html  css  js  c++  java
  • JVM内存管理------杂谈(借此也论一论obj=null)

     各位园友好,LZ是从某网站转战过来的博主,看到这里很多博主都称看友们为园友,LZ斗胆模仿一下,不过以前,LZ其实都是称看友们为猿友的。之前LZ在某网站已经写了一系列文章,已经全部复制到了园内的新博客,主要是设计模式的内容,各位有兴趣的也可以去翻看一下,其中有不少还是颇受之前猿友们喜爱的。

                作为一个程序猿,修炼的过程就犹如玄幻小说中的主角,不仅需要练习各种武技,内气的修炼的一样重要。虽然武技可以迅速的提升主角的实力,但是在内气太差的情况下,根本发挥不出武技的十之一二。

                因此,在介绍过设计模式这一类外功之后,LZ就直接转战内气修炼,和各位猿友探讨一下JVM的内容。

                本来这一章应该是介绍与GC相关的内容,不过在此之前,LZ准备先和各位探讨一下一个编程的小技巧。当然,这个小技巧其实也是与GC密切相关的。

                不知道各位猿友有没看过一些JAVA内存相关的文章,里面在罗列建议的时候,经常会写出这样一条建议。

                第XX条、请在使用完对象之后,显示的将对象设置为null。

                原话不一定如此,但意思是一样的。话里所描述的意思,就是说我们以后写代码应该这么写。

    Object obj = new Object();
    //to do something 
    obj = null;

               这段代码有点C/C++的风格,obj=null代替了C/C++中的delete obj或者是free(obj),相当于在提示我们,就算有了GC,我们也要像没有GC一样,使用完对象就得将其赋为空值。

               首先,LZ这里要说明的是,将obj赋为空值,与C/C++中的delete其实有着天壤之别,LZ之所以说它们代替了delete和free,仅仅是因为它们出现在代码中的位置类似而已。

               obj=null只做了一件事,就是将obj这个引用变量与new Object()创造的实例的关联断开,实际上,实例所占用的内存空间依然没有释放。

               在提出这个建议的时候,很多博主或者图书的作者(因为有不少博主估计也是从书上看的)的本意,是想尽快消除引用与实例的关联,从而诱发GC在进行垃圾回收时,将实例所占用的内存释放。在某些时候,这么做也是为了消除内存泄露。

               LZ个人觉得,许多博主或者是图书作者,提出这个建议的初衷,主要是针对一些没有接触过GC原理以及内存管理的程序猿而建议的,因为在不明白相关知识的前提下,很容易掌握不好变量的作用域,从而导致不必要的内存浪费(个人觉得这个并不是主要目的,因为只要没有发生内存泄露,内存终究是要被GC释放的),甚至是内存泄露。

               所以为了安全起见,有些高人们就提出了这么一个建议。

               有鉴于此,LZ个人觉得,在各位掌握了相关知识之后,完全可以忽略这个建议,而且这么做明显会降低代码的清晰度以及增加编码的负担,然而所换来的好处,却只是为了避免那根本不一定存在的内存泄露。

               这里解释一下为何在有些时候不将对象赋为空值会造成内存泄露,我们考虑下面一段代码。

    import java.util.Arrays;
    
    public class Stack {
        
        private static final int INIT_SIZE = 10;
    
        private Object[] datas;
        
        private int size;
    
        public Stack() {
            super();
            datas = new Object[INIT_SIZE];
        }
        
        public void push(Object data){
            if (size == datas.length) {
                extend();
            }
            datas[size++] = data;
        }
        
        public Object pop(){
            if (size == 0) {
                throw new IndexOutOfBoundsException("size is zero");
            }
            return datas[--size];
        }
        
        private void extend(){
            datas = Arrays.copyOf(datas, 2 * size + 1);
        }
        
    }

     这段代码是一个简单的长度可伸缩的栈实现,在你写一段测试代码去测试它的时候,会发现它毫无问题。但是不好意思,这里面就有一个明显的“内存泄露”,这就是因为一些对象或者说引用没有设置为空值所造成的。       

              如果你还没看出来,LZ稍微提示一下,各位就会意识到了。这段代码里面,数组里的对象只会无限增长,而不会随着栈中元素的弹出而减少,减小的仅仅是对外展示的栈的大小size。考虑一个极端的场景,假设你曾经往栈中放入了100万个对象,最后使用了99万9千9百9十9个,从外部看来,栈中还只剩一个可用对象了,但是我们的栈依然持有着100万个对象的引用。如果JVM可以活过来的话,想必一定会把你蹂躏到死的。

              我们缺少的就是将对象赋为null值的那一步,所以pop方法应该改为下面的方式,而且各位可以去看一下ArrayList中remove方法的源码,也是类似的思路。

    复制代码
        public Object pop(){
            if (size == 0) {
                throw new IndexOutOfBoundsException("size is zero");
            }
            Object data = datas[--size];
            datas[size] = null;
            return data;
        }
    复制代码

              这个内存泄露是非常隐蔽的,而且实际使用当中不一定就能发现,因为随着Stack对象的回收,整个数组也会被回收,到时内存泄露就被掩盖了。

              所以个人觉得上述的那个建议是完全没有必要的,就算遵从了上面的建议,如果对内存管理不熟悉的话,也不会想到上面这个代码中的问题。如果想彻底的避免内存泄露的发生,机械式的主动将对象赋为空值,并不是一个可以从根本上解决问题的办法。

              真正能够解决问题的办法,就是掌握好GC的策略与原理,定义一个变量时多注意变量的作用域,如此才可以更好的避免内存泄露。

              所以学好GC原理还是很有必要的,希望准备走JAVA之路的朋友,尤其是从培训机构出来的猿友们(此处没有鄙视培训机构出来的猿友们的意思,因为LZ本人也是半路出家,从培训机构走上编程之路的程序猿之一),一定不要只专注于各个框架的使用以及业务的深入,虽然这些事很有必要,但并不是全部。

              follow me and go the memory world 吧(语法都是浮云)。

     

     


    版权声明


    作者:zuoxiaolong(左潇龙)

    出处:博客园左潇龙的技术博客--http://www.cnblogs.com/zuoxiaolong

    您的支持是对博主最大的鼓励,感谢您的认真阅读。

    本文版权归作者所有,欢迎转载,但未经作者同意必须保留此段声明,且在文章页面明显位置给出原文连接,否则保留追究法律责任的权利。


  • 相关阅读:
    C# winfrom容器布局与工具栏&&右键菜单栏&&隐藏显示小图标的的简单事件
    C# Winform ListView控件
    MongoDB3.6.3 windows安装配置、启动
    史蒂夫•乔布斯在斯坦福大学的演讲
    SpringBoot配置文件 application.properties详解
    Elasticsearch分布式安装启动失败
    Couldn't connect to host, port: smtp.163.com, 25; timeout -1;
    CentOS 7 安装jdk9
    生成唯一的随机数(时间+随机数)
    idea 设置背景图片
  • 原文地址:https://www.cnblogs.com/Zyf2016/p/6337764.html
Copyright © 2011-2022 走看看