破除java神話之垃圾收集解決所有內存問題

2019-11-18 13:13:57

字體：大中小

來源：轉載

供稿：網友

　　垃圾收集解決所有的內存問題
　　
　　對于java程序員而言，垃圾收集功能是一個非常大的幫助，同時也是使用java語言的一個非常大的優勢。然而，實際情況應該是不能因為垃圾收集可以清除無用的內存就不去考慮內存問題。這里要指明的是，假如忽略這個問題，那么就會導致問題。
　　
　　首先，在不同的JVM上垃圾收集算法是不同的，因此，假如你想你的程序能夠很好的運行在不同的JVM上，那么就不能依靠垃圾收集的特定行為。垃圾收集是一個非?；钴S的研究問題，更好、更快并且更精確的收集器總在實現中。
　　
　　然而很多現代的垃圾收集器都有著同樣的問題。其中一個是當他們運行時并非總是釋放所有那些可以被收集的對象。
　　
　　分析表明java編程中大多對象的生存期是短暫的，因此，對于需要提高性能的收集器而言，他們會減少檢查那些具有較長生命的對象的頻度，這個是依據大多對象具有較短的生存期，而那些生存期較長的對象往往會被繼續引用，因此，沒有必要在每次檢查時都去檢查這樣的對象是否可以被回收。
　　
　　要釋放特定的對象的內存可能需要多次調用垃圾收集。你可以通過調用System.gc方法建議（注重是建議）垃圾收集器運行。請求這個方法的結果通常導致垃圾收集器進行一次完整的收集。通常這個比VM調用垃圾收集要更徹底和完全，也會盡可能快的完成。假如程序員顯式的調用System.gc，那么推論是有更多的時間做更多的工作（請注重是有更多的事情做更多的事情，這意味著將進行大量的檢查,還記得剛才的有關對長短生命期對象的檢查的頻度的變化嗎？而不是真正徹底的清除）。在任何一種情況下（顯式調用垃圾收集和VM調用垃圾收集）都不要假設所有可以被收集的對象會真正的被收集。
　　
　　顯式的調用System.gc有更大的機會完成徹底的收集，但不是保證會完成。
　　
　　另一個程序員會碰到的麻煩是他們往往保持對那些不再需要的對象的引用。這將阻止垃圾收集器釋放該對象。
　　
　　這種情況在你自己治理列表的時候會發生。
　　
　　考慮下面的ObjStack類。這個類使用push和pop方法治理堆棧中的對象。兩個方法都利用索引，該索引指明堆棧中下一個可用的位置。push方法存儲對新對象的引用并增加索引值，而pop方法減小索引值并返回堆棧最上面的元素。
　　
　　實例一：沒有正確實現pop方法的ObjStack
　　
　　class ObjStack
　　{
　　PRivate Object[] stack;
　　private int index;
　　public void push(Object o)
　　{
　　stack[index] = o;
　　index++;
　　}
　　public Object pop()
　　{
　　index-;
　　return stack[index];
　　}
　　//...
　　}
　　
　　現在創建一個容量為10的對象，然后調用8次push方法向它添加對象，那么此時索引值為8。
　　
　　現在考慮三次調用pop方法后發生什么？此時的索引值為5，但是請注重，除了這個索引值發生變化外堆棧其實沒有其它任何變化！
　　
　　雖然pop方法減小了索引值，但是實際上堆棧仍然保持著對那些對象的引用。調用pop方法往往意味著那些對象應該被收集（大多情況是如此的，即使不是馬上，也是在稍后使用完該對象后）。然而由于堆棧仍然保留有對該對象的引用，它就不能被收集。這些對象只能在調用push后被替換才可能被收集。正確的pop的實現如下：
　　
　　public Object pop()
　　{
　　index-;
　　Object o = stack[index];
　　stack[index] = null;
　　return o;
　　}
　　在這個版本的pop方法中，當引用被返回后，堆棧刪除對他們的引用因此垃圾收集器在以后可以回收他們。
　　
　　在你自己的編碼中，對于那些不需要的對象，不要在引用它們！程序的執行極大收到可用內存的影響，可用內存越少，那么垃圾收集的執行次數越多，這將極大的傷害性能。

上一篇：在Java中發送郵件的一個相當完善的腳本

下一篇：一個在程序中實現plugin機制的簡單例子