首頁 > Java > java教程 > 主體

JVM記憶體管理------雜談(藉此也論一論obj=null)

黄舟
發布: 2016-12-28 15:29:04
原創
1287 人瀏覽過

作為一個程序猿,修練的過程就猶如玄幻小說中的主角,不僅需要練習各種武技,內氣的修練的一樣重要。雖然武技可以迅速的提升主角的實力,但是在內氣太差的情況下,根本發揮不出武技的十之一二。
因此,在介紹過設計模式這一類外功之後,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 吧(语法都是浮云)。

 以上就是JVM内存管理------杂谈(借此也论一论obj=null)的内容,更多相关内容请关注PHP中文网(m.sbmmt.com)!


相關標籤:
來源:php.cn
本網站聲明
本文內容由網友自願投稿,版權歸原作者所有。本站不承擔相應的法律責任。如發現涉嫌抄襲或侵權的內容,請聯絡admin@php.cn
熱門教學
更多>
最新下載
更多>
網站特效
網站源碼
網站素材
前端模板