當前位置：首頁 > 编程语言 > java >内容正文

java

Java内存泄露的理解与解决

發布時間：2025/3/21 java 26 豆豆

生活随笔收集整理的這篇文章主要介紹了 Java内存泄露的理解与解决小編覺得挺不錯的,現在分享給大家,幫大家做個參考.

Java內存管理機制

在C++語言中，如果需要動態分配一塊內存，程序員需要負責這塊內存的整個生命周期。從申請分配、到使用、再到最后的釋放。這樣的過程非常靈活，但是卻十分繁瑣，程序員很容易由于疏忽而忘記釋放內存，從而導致內存的泄露。Java語言對內存管理做了自己的優化，這就是垃圾回收機制。Java的幾乎所有內存對象都是在堆內存上分配（基本數據類型除外），然后由GC（garbage?collection）負責自動回收不再使用的內存。

????上面是Java內存管理機制的基本情況。但是如果僅僅理解到這里，我們在實際的項目開發中仍然會遇到內存泄漏的問題。也許有人表示懷疑，既然Java的垃圾回收機制能夠自動的回收內存，怎么還會出現內存泄漏的情況呢？這個問題，我們需要知道GC在什么時候回收內存對象，什么樣的內存對象會被GC認為是“不再使用”的。

????Java中對內存對象的訪問，使用的是引用的方式。在Java代碼中我們維護一個內存對象的引用變量，通過這個引用變量的值，我們可以訪問到對應的內存地址中的內存對象空間。在Java程序中，這個引用變量本身既可以存放堆內存中，又可以放在代碼棧的內存中（與基本數據類型相同）。GC線程會從代碼棧中的引用變量開始跟蹤，從而判定哪些內存是正在使用的。如果GC線程通過這種方式，無法跟蹤到某一塊堆內存，那么GC就認為這塊內存將不再使用了（因為代碼中已經無法訪問這塊內存了）。

????通過這種有向圖的內存管理方式，當一個內存對象失去了所有的引用之后，GC就可以將其回收。反過來說，如果這個對象還存在引用，那么它將不會被GC回收，哪怕是Java虛擬機拋出OutOfMemoryError。

Java內存泄露

????一般來說內存泄漏有兩種情況。一種情況如在C/C++語言中的，在堆中的分配的內存，在沒有將其釋放掉的時候，就將所有能訪問這塊內存的方式都刪掉（如指針重新賦值）；另一種情況則是在內存對象明明已經不需要的時候，還仍然保留著這塊內存和它的訪問方式（引用）。第一種情況，在Java中已經由于垃圾回收機制的引入，得到了很好的解決。所以，Java中的內存泄漏，主要指的是第二種情況。

????可能光說概念太抽象了，大家可以看一下這樣的例子：

1?Vector?v=new?Vector(10);
2?for?(int?i=1;i<100;?i++){
3?Object?o=new?Object();
4?v.add(o);
5?o=null;
6?}

???
????在這個例子中，代碼棧中存在Vector對象的引用v和Object對象的引用o。在For循環中，我們不斷的生成新的對象，然后將其添加到Vector對象中，之后將o引用置空。問題是當o引用被置空后，如果發生GC，我們創建的Object對象是否能夠被GC回收呢？答案是否定的。因為，GC在跟蹤代碼棧中的引用時，會發現v引用，而繼續往下跟蹤，就會發現v引用指向的內存空間中又存在指向Object對象的引用。也就是說盡管o引用已經被置空，但是Object對象仍然存在其他的引用，是可以被訪問到的，所以GC無法將其釋放掉。如果在此循環之后，Object對象對程序已經沒有任何作用，那么我們就認為此Java程序發生了內存泄漏。

????盡管對于C/C++中的內存泄露情況來說，Java內存泄露導致的破壞性小，除了少數情況會出現程序崩潰的情況外，大多數情況下程序仍然能正常運行。但是，在移動設備對于內存和CPU都有較嚴格的限制的情況下，Java的內存溢出會導致程序效率低下、占用大量不需要的內存等問題。這將導致整個機器性能變差，嚴重的也會引起拋出OutOfMemoryError，導致程序崩潰。

一般情況下內存泄漏的避免

????在不涉及復雜數據結構的一般情況下，Java的內存泄露表現為一個內存對象的生命周期超出了程序需要它的時間長度。我們有時也將其稱為“對象游離”。

例如：

?1?public?class?FileSearch{
?2?
?3?????private?byte[]?content;
?4?????private?File?mFile;
?5?????
?6?????public?FileSearch(File?file){
?7?????????mFile?=?file;
?8?????}
?9?
10?????public?boolean?hasString(String?str){
11?????????int?size?=?getFileSize(mFile);
12?????????content?=?new?byte[size];
13?????????loadFile(mFile,?content);
14?????????
15?????????String?s?=?new?String(content);
16?????????return?s.contains(str);
17?????}
18?}

????在這段代碼中，FileSearch類中有一個函數hasString，用來判斷文檔中是否含有指定的字符串。流程是先將mFile加載到內存中，然后進行判斷。但是，這里的問題是，將content聲明為了實例變量，而不是本地變量。于是，在此函數返回之后，內存中仍然存在整個文件的數據。而很明顯，這些數據我們后續是不再需要的，這就造成了內存的無故浪費。

????要避免這種情況下的內存泄露，要求我們以C/C++的內存管理思維來管理自己分配的內存。第一，是在聲明對象引用之前，明確內存對象的有效作用域。在一個函數內有效的內存對象，應該聲明為local變量，與類實例生命周期相同的要聲明為實例變量……以此類推。第二，在內存對象不再需要時，記得手動將其引用置空。

復雜數據結構中的內存泄露問題

????在實際的項目中，我們經常用到一些較為復雜的數據結構用于緩存程序運行過程中需要的數據信息。有時，由于數據結構過于復雜，或者我們存在一些特殊的需求（例如，在內存允許的情況下，盡可能多的緩存信息來提高程序的運行速度等情況），我們很難對數據結構中數據的生命周期作出明確的界定。這個時候，我們可以使用Java中一種特殊的機制來達到防止內存泄露的目的。

????之前我們介紹過，Java的GC機制是建立在跟蹤內存的引用機制上的。而在此之前，我們所使用的引用都只是定義一個“Object?o;”這樣形式的。事實上，這只是Java引用機制中的一種默認情況，除此之外，還有其他的一些引用方式。通過使用這些特殊的引用機制，配合GC機制，就可以達到一些我們需要的效果。

Java中的幾種引用方式

????Java中有幾種不同的引用方式，它們分別是：強引用、軟引用、弱引用和虛引用。下面，我們首先詳細地了解下這幾種引用方式的意義。

????
????? 強引用

在此之前我們介紹的內容中所使用的引用都是強引用，這是使用最普遍的引用。如果一個對象具有強引用，那就類似于必不可少的生活用品，垃圾回收器絕不會回收它。當內存空?間不足，Java虛擬機寧愿拋出OutOfMemoryError錯誤，使程序異常終止，也不會靠隨意回收具有強引用的對象來解決內存不足問題。

軟引用（SoftReference）

SoftReference?類的一個典型用途就是用于內存敏感的高速緩存。SoftReference?的原理是：在保持對對象的引用時保證在?JVM?報告內存不足情況之前將清除所有的軟引用。關鍵之處在于，垃圾收集器在運行時可能會（也可能不會）釋放軟可及對象。對象是否被釋放取決于垃圾收集器的算法?以及垃圾收集器運行時可用的內存數量。

弱引用（WeakReference）

WeakReference?類的一個典型用途就是規范化映射（canonicalized?mapping）。另外，對于那些生存期相對較長而且重新創建的開銷也不高的對象來說，弱引用也比較有用。關鍵之處在于，垃圾收集器運行時如果碰到了弱可及對象，將釋放?WeakReference?引用的對象。然而，請注意，垃圾收集器可能要運行多次才能找到并釋放弱可及對象。

虛引用（PhantomReference）

PhantomReference?類只能用于跟蹤對被引用對象即將進行的收集。同樣，它還能用于執行?pre-mortem?清除操作。PhantomReference?必須與?ReferenceQueue?類一起使用。需要?ReferenceQueue?是因為它能夠充當通知機制。當垃圾收集器確定了某個對象是虛可及對象時，PhantomReference?對象就被放在它的?ReferenceQueue?上。將?PhantomReference?對象放在?ReferenceQueue?上也就是一個通知，表明?PhantomReference?對象引用的對象已經結束，可供收集了。這使您能夠剛好在對象占用的內存被回收之前采取行動。Reference與ReferenceQueue的配合使用。

GC、Reference與ReferenceQueue的交互

A、?GC無法刪除存在強引用的對象的內存。

B、?GC發現一個只有軟引用的對象內存，那么：

①?SoftReference對象的referent?域被設置為null，從而使該對象不再引用heap對象。

②?SoftReference引用過的heap對象被聲明為finalizable。

③?當?heap?對象的?finalize()?方法被運行而且該對象占用的內存被釋放，SoftReference?對象就被添加到它的?ReferenceQueue（如果后者存在的話）。

C、?GC發現一個只有弱引用的對象內存，那么：

①?WeakReference對象的referent域被設置為null,從而使該對象不再引用heap對象。

②?WeakReference引用過的heap對象被聲明為finalizable。

③?當heap對象的finalize()方法被運行而且該對象占用的內存被釋放時，WeakReference對象就被添加到它的ReferenceQueue（如果后者存在的話）。

D、?GC發現一個只有虛引用的對象內存，那么：

①?PhantomReference引用過的heap對象被聲明為finalizable。

②?PhantomReference在堆對象被釋放之前就被添加到它的ReferenceQueue。

值得注意的地方有以下幾點：

1、GC在一般情況下不會發現軟引用的內存對象，只有在內存明顯不足的時候才會發現并釋放軟引用對象的內存。

2、GC對弱引用的發現和釋放也不是立即的，有時需要重復幾次GC，才會發現并釋放弱引用的內存對象。
3、軟引用和弱引用在添加到ReferenceQueue的時候，其指向真實內存的引用已經被置為空了，相關的內存也已經被釋放掉了。而虛引用在添加到ReferenceQueue的時候，內存還沒有釋放，仍然可以對其進行訪問。

????代碼示例

通過以上的介紹，相信您對Java的引用機制以及幾種引用方式的異同已經有了一定了解。光是概念，可能過于抽象，下面我們通過一個例子來演示如何在代碼中使用Reference機制。

1?????String?str?=?new?String("hello");?//①
2?????ReferenceQueue<String>?rq?=?new?ReferenceQueue<String>();?//②
3?????WeakReference<String>?wf?=?new?WeakReference<String>(str,?rq);?//③
4?????str=null;?//④取消"hello"對象的強引用
5?????String?str1=wf.get();?//⑤假如"hello"對象沒有被回收，str1引用"hello"對象
6?????//假如"hello"對象沒有被回收，rq.poll()返回null
7?????Reference<??extends?String>?ref=rq.poll();?//⑥

在以上代碼中，注意⑤⑥兩處地方。假如“hello”對象沒有被回收wf.get()將返回“hello”字符串對象，rq.poll()返回null；而加入“hello”對象已經被回收了，那么wf.get()返回null，rq.poll()返回Reference對象，但是此Reference對象中已經沒有str對象的引用了(PhantomReference則與WeakReference、SoftReference不同)。

????引用機制與復雜數據結構的聯合應用

????了解了GC機制、引用機制，并配合上ReferenceQueue，我們就可以實現一些防止內存溢出的復雜數據類型。

例如，SoftReference具有構建Cache系統的特質，因此我們可以結合哈希表實現一個簡單的緩存系統。這樣既能保證能夠盡可能多的緩存信息，又可以保證Java虛擬機不會因為內存泄露而拋出OutOfMemoryError。這種緩存機制特別適合于內存對象生命周期長，且生成內存對象的耗時比較長的情況，例如緩存列表封面圖片等。對于一些生命周期較長，但是生成內存對象開銷不大的情況，使用WeakReference能夠達到更好的內存管理的效果。

附SoftHashmap的源碼一份，相信看過之后，大家會對Reference機制的應用有更深入的理解。

??1package?com.***.widget;
??2
??3//:?SoftHashMap.java?
??4import?java.util.*;?
??5import?java.lang.ref.*;?
??6
??7import?android.util.Log;
??8
??9public?class?SoftHashMap?extends?AbstractMap?{?
?10??/**?The?internal?HashMap?that?will?hold?the?SoftReference.?*/?
?11??private?final?Map?hash?=?new?HashMap();?
?12??/**?The?number?of?"hard"?references?to?hold?internally.?*/?
?13??private?final?int?HARD_SIZE;?
?14??/**?The?FIFO?list?of?hard?references,?order?of?last?access.?*/?
?15??private?final?LinkedList?hardCache?=?new?LinkedList();?
?16??/**?Reference?queue?for?cleared?SoftReference?objects.?*/?
?17??private?ReferenceQueue?queue?=?new?ReferenceQueue();?
?18
?19??//Strong?Reference?number
?20??public?SoftHashMap()?{?this(100);?}?
?21??public?SoftHashMap(int?hardSize)?{?HARD_SIZE?=?hardSize;?}?
?22??
?23
?24??public?Object?get(Object?key)?{?
?25????Object?result?=?null;?
?26????//?We?get?the?SoftReference?represented?by?that?key?
?27????SoftReference?soft_ref?=?(SoftReference)hash.get(key);?
?28????if?(soft_ref?!=?null)?{?
?29??????//?From?the?SoftReference?we?get?the?value,?which?can?be?
?30??????//?null?if?it?was?not?in?the?map,?or?it?was?removed?in?
?31??????//?the?processQueue()?method?defined?below?
?32??????result?=?soft_ref.get();?
?33??????if?(result?==?null)?{?
?34????????//?If?the?value?has?been?garbage?collected,?remove?the?
?35????????//?entry?from?the?HashMap.?
?36????????hash.remove(key);?
?37??????}?else?{?
?38????????//?We?now?add?this?object?to?the?beginning?of?the?hard?
?39????????//?reference?queue.??One?reference?can?occur?more?than?
?40????????//?once,?because?lookups?of?the?FIFO?queue?are?slow,?so?
?41????????//?we?don't?want?to?search?through?it?each?time?to?remove?
?42????????//?duplicates.?
?43??????????//keep?recent?use?object?in?memory
?44????????hardCache.addFirst(result);?
?45????????if?(hardCache.size()?>?HARD_SIZE)?{?
?46??????????//?Remove?the?last?entry?if?list?longer?than?HARD_SIZE?
?47??????????hardCache.removeLast();?
?48????????}?
?49??????}?
?50????}?
?51????return?result;?
?52??}?
?53
?54??/**?We?define?our?own?subclass?of?SoftReference?which?contains?
?55???not?only?the?value?but?also?the?key?to?make?it?easier?to?find?
?56???the?entry?in?the?HashMap?after?it's?been?garbage?collected.?*/?
?57??private?static?class?SoftValue?extends?SoftReference?{?
?58????private?final?Object?key;?//?always?make?data?member?final?
?59????/**?Did?you?know?that?an?outer?class?can?access?private?data?
?60?????members?and?methods?of?an?inner?class???I?didn't?know?that!?
?61?????I?thought?it?was?only?the?inner?class?who?could?access?the?
?62?????outer?class's?private?information.??An?outer?class?can?also?
?63?????access?private?members?of?an?inner?class?inside?its?inner?
?64?????class.?*/?
?65????private?SoftValue(Object?k,?Object?key,?ReferenceQueue?q)?{?
?66??????super(k,?q);?
?67??????this.key?=?key;?
?68????}?
?69??}?
?70
?71??/**?Here?we?go?through?the?ReferenceQueue?and?remove?garbage?
?72???collected?SoftValue?objects?from?the?HashMap?by?looking?them?
?73???up?using?the?SoftValue.key?data?member.?*/?
?74??public?void?processQueue()?{?
?75????SoftValue?sv;?
?76????while?((sv?=?(SoftValue)queue.poll())?!=?null)?{?
?77????????if(sv.get()==?null){
?78????????????Log.e("processQueue",?"null");
?79????????}else{
?80????????????Log.e("processQueue",?"Not?null");
?81????????}
?82??????hash.remove(sv.key);?//?we?can?access?private?data!
?83??????Log.e("SoftHashMap",?"release?"?+?sv.key);
?84????}?
?85??}?
?86??/**?Here?we?put?the?key,?value?pair?into?the?HashMap?using?
?87???a?SoftValue?object.?*/?
?88??public?Object?put(Object?key,?Object?value)?{?
?89????processQueue();?//?throw?out?garbage?collected?values?first?
?90????Log.e("SoftHashMap",?"put?into?"?+?key);
?91????return?hash.put(key,?new?SoftValue(value,?key,?queue));?
?92??}?
?93??public?Object?remove(Object?key)?{?
?94????processQueue();?//?throw?out?garbage?collected?values?first?
?95????return?hash.remove(key);?
?96??}?
?97??public?void?clear()?{?
?98????hardCache.clear();?
?99????processQueue();?//?throw?out?garbage?collected?values?
100????hash.clear();?
101??}?
102??public?int?size()?{?
103????processQueue();?//?throw?out?garbage?collected?values?first?
104????return?hash.size();?
105??}?
106??public?Set?entrySet()?{?
107????//?no,?no,?you?may?NOT?do?that!!!?GRRR?
108????throw?new?UnsupportedOperationException();?
109??}?
110}?
111
112
113
from:?http://www.cnblogs.com/qq78292959/archive/2011/07/25/2116123.html