JAVA垃圾回收機制與內(nèi)存泄露問題

JAVAJAVA垃圾回收機制與內(nèi)存泄露問題#1．垃圾收集算法的核心思想Java語言建立了垃圾收集機制，用以跟蹤正在使用的對象和發(fā)現(xiàn)并回收不再使用(引用)的對象。該機制可以有效防范動態(tài)內(nèi)存分配中可能發(fā)生的兩個危險：因內(nèi)存垃圾過多而引發(fā)的內(nèi)存耗盡，以及不恰當?shù)膬?nèi)存釋放所造成的內(nèi)存非法引用。垃圾收集算法的核心思想是：對虛擬機可用內(nèi)存空間，即堆空間中的對象進行識別，如果對象正在被引用那么稱其為存活對象，反之，如果對象不再被引用，則為垃圾對象，可以回收其占據(jù)的空間，用于再分配。垃圾收集算法的選擇和垃圾收集系統(tǒng)參數(shù)的合理調節(jié)直接影響著系統(tǒng)性能，因此需要開發(fā)人員做比較深入的了解。2.觸發(fā)主GC(GarbageCollector)的條件JVM進行次GC的頻率很高，但因為這種GC占用時間極短，所以對系統(tǒng)產(chǎn)生的影響不大。更值得關注的是主GC的觸發(fā)條件,因為它對系統(tǒng)影響很明顯。總的來說,有兩個條件會觸發(fā)主GC:當應用程序空閑時，即沒有應用線程在運行時,GC會被調用。因為GC在優(yōu)先級最低的線程中進行，所以當應用忙時,GC線程就不會被調用，但以下條件除外。Java堆內(nèi)存不足時,GC會被調用。當應用線程在運行，并在運行過程中創(chuàng)建新對象，若這時內(nèi)存空間不足,JVM就會強制地調用GC線程,以便回收內(nèi)存用于新的分配。若GC一次之后仍不能滿足內(nèi)存分配的要求,JVM會再進行兩次GC作進一步的嘗試，若仍無法滿足要求，則JVM將報“outofmemory"的錯誤,Java應用將停止。由于是否進行主GC由JVM根據(jù)系統(tǒng)環(huán)境決定，而系統(tǒng)環(huán)境在不斷的變化當中,所以主GC的運行具有不確定性,無法預計它何時必然出現(xiàn),但可以確定的是對一個長期運行的應用來說，其主GC是反復進行的。3?減少GC開銷的措施根據(jù)上述GC的機制，程序的運行會直接影響系統(tǒng)環(huán)境的變化，從而影響GC的觸發(fā)。若不針對GC的特點進行設計和編碼,就會出現(xiàn)內(nèi)存駐留等一系列負面影響。為了避免這些影響,基本的原則就是盡可能地減少垃圾和減少GC過程中的開銷。具體措施包括以下幾個方面:不要顯式調用System.gc()此函數(shù)建議JVM進行主GC,雖然只是建議而非一定，但很多情況下它會觸發(fā)主GC，從而增加主GC的頻率，也即增加了間歇性停頓的次數(shù)。盡量減少臨時對象的使用臨時對象在跳出函數(shù)調用后，會成為垃圾，少用臨時變量就相當于減少了垃圾的產(chǎn)生，從而延長了出現(xiàn)上述第二個觸發(fā)條件出現(xiàn)的時間，減少了主GC的機會。對象不用時最好顯式置為Null一般而言，為Null的對象都會被作為垃圾處理，所以將不用的對象顯式地設為Null,有利于GC收集器判定垃圾，從而提高了GC的效率。盡量使用StringBuffer而不用String來累加字符串(詳見blog另一篇文章JAVA中String與StringBuffer)由于String是固定長的字符串對象，累加String對象時，并非在一個String對象中擴增，而是重新創(chuàng)建新的String對象，如Str5=Strl+Str2+Str3+Str4,這條語句執(zhí)行過程中會產(chǎn)生多個垃圾對象，因為對次作“+”操作時都必須創(chuàng)建新的String對象，但這些過渡對象對系統(tǒng)來說是沒有實際意義的,只會增加更多的垃圾。避免這種情況可以改用StringBuffer來累加字符串，因StringBuffer是可變長的，它在原有基礎上進行擴增，不會產(chǎn)生中間對象。⑸能用基本類型如Int,Long,就不用Integer,Long對象基本類型變量占用的內(nèi)存資源比相應對象占用的少得多，如果沒有必要，最好使用基本變量。(6)盡量少用靜態(tài)對象變量靜態(tài)變量屬于全局變量，不會被GC回收，它們會一直占用內(nèi)存。(7)分散對象創(chuàng)建或刪除的時間集中在短時間內(nèi)大量創(chuàng)建新對象,特別是大對象，會導致突然需要大量內(nèi)存JVM在面臨這種情況時，只能進行主GC,以回收內(nèi)存或整合內(nèi)存碎片,從而增加主GC的頻率。集中刪除對象,道理也是一樣的。它使得突然出現(xiàn)了大量的垃圾對象,空閑空間必然減少,從而大大增加了下一次創(chuàng)建新對象時強制主GC的機會。4．gc與finalize方法(l)gc方法請求垃圾回收使用System.gc()可以不管JVM使用的是哪一種垃圾回收的算法，都可以請求Java的垃圾回收。需要注意的是，調用System.gc(也僅僅是一個請求。JVM接受這個消息后，并不是立即做垃圾回收，而只是對幾個垃圾回收算法做了加權，使垃圾回收操作容易發(fā)生，或提早發(fā)生，或回收較多而已。⑵finalize方法透視垃圾收集器的運行在JVM垃圾收集器收集一個對象之前，一般要求程序調用適當?shù)姆椒ㄡ尫刨Y源，但在沒有明確釋放資源的情況下，Java提供了缺省機制來終止化該對象釋放資源，這個方法就是finalize()。它的原型為：protectedvoidfinalize()throwsThrowable在finalize。方法返回之后，對象消失，垃圾收集開始執(zhí)行。原型中的throwsThrowable表示它可以拋出任何類型的異常。因此，當對象即將被銷毀時，有時需要做一些善后工作?？梢园堰@些操作寫在finalize()方法里。protectedvoidfinalize(){//finalizationcodehere}⑶代碼示例classGarbage{intindex;staticintcount;Garbage(){count++;System.out.println("object"+count+"construct");setID(count);}voidsetID(intid){index=id;}protectedvoidfinalize()//重寫finalize方法{System.out.println("object"+index+"isreclaimed");}publicstaticvoidmain(String[]args){newGarbage();newGarbage();newGarbage();newGarbage();System.gc();//請求運行垃圾收集器}}5．Java內(nèi)存泄漏由于采用了垃圾回收機制，任何不可達對象(對象不再被引用)都可以由垃圾收集線程回收。因此通常說的Java內(nèi)存泄漏其實是指無意識的、非故意的對象引用，或者無意識的對象保持。無意識的對象引用是指代碼的開發(fā)人員本來已經(jīng)對對象使用完畢，卻因為編碼的錯誤而意外地保存了對該對象的引用(這個引用的存在并不是編碼人員的主觀意愿)，從而使得該對象一直無法被垃圾回收器回收掉，這種本來以為可以釋放掉的卻最終未能被釋放的空間可以認為是被“泄漏了”?？紤]下面的程序，在ObjStack類中，使用push和pop方法來管理堆棧中的對象。兩個方法中的索引(index)用于指示堆棧中下一個可用位置。push方法存儲對新對象的引用并增加索引值，而pop方法減小索引值并返回堆棧最上面的元素。在main方法中，創(chuàng)建了容量為64的棧，并64次調用push方法向它添加對象，此時index的值為64,隨后又32次調用pop方法，則index的值變?yōu)?2，出棧意味著在堆棧中的空間應該被收集。但事實上,pop方法只是減小了索引值,堆棧仍然保持著對那些對象的引用。故32個無用對象不會被GC回收，造成了內(nèi)存滲漏。publicclassObjStack{privateObject[]stack;privateintindex;ObjStack(intindexcount){stack=newObject[indexcount];index=0;}publicvoidpush(Objectobj){stack[index]=obj;index++;}publicObjectpop(){index--;returnstack[index];}}publicclassPushpop{publicstaticvoidmain(String[]args){inti=0;Objecttempobj;ObjStackstack1=newObjStack(64);//new—個ObjStack對象，并調用有參構造函數(shù)。分配stackObj數(shù)組的空間大小為64，可以存64個對象，從0開始存儲。while(i<64){tempobj=newObject。;〃循環(huán)newObj對象，把每次循環(huán)的對象一一存放在stackObj數(shù)組中。stack1.push(tempobj);i++;System.out.println(”第"+i+"次進棧"+"\t");}while(i>32){tempobj=stackl.pop();〃這里造成了空間的浪費。//正確的pop方法可改成如下所指示,當引用被返回后,堆棧刪除對他們的引用,因此垃圾收集器在以后可以回收他們。/**publicObjectpop(){index--;Objecttemp=stack[index];stack[index]=null;returntemp;}*/i--;System.out.println(”第"+(64-i)+"次出棧"+"\t");}}}如何消除內(nèi)存泄漏雖然Java虛擬機(JVM)及其垃圾收集器(garbagecollector，GC)負責管理大多數(shù)的內(nèi)存任務，Java軟件程序中還是有可能出現(xiàn)內(nèi)存泄漏。實際上，這在大型項目中是一個常見的問題。避免內(nèi)存泄漏的第一步是要弄清楚它是如何發(fā)生的。本文介紹了編寫Java代碼的一些常見的內(nèi)存泄漏陷阱，以及編寫不泄漏代碼的一些最佳實踐。一旦發(fā)生了內(nèi)存泄漏，要指出造成泄漏的代碼是非常困難的。因此本文還介紹了一種新工具，用來診斷泄漏并指出根本原因。該工具的開銷非常小，因此可以使用它來尋找處于生產(chǎn)中的系統(tǒng)的內(nèi)存泄漏。垃圾收集器的作用雖然垃圾收集器處理了大多數(shù)內(nèi)存管理問題，從而使編程人員的生活變得更輕松了，但是編程人員還是可能犯錯而導致出現(xiàn)內(nèi)存問題。簡單地說，GC循環(huán)地跟蹤所有來自“根”對象(堆棧對象、靜態(tài)對象、JNI句柄指向的對象，諸如此類)的引用，并將所有它所能到達的對象標記為活動的。程序只可以操縱這些對象；其他的對象都被刪除了。因為GC使程序不可能到達已被刪除的對象，這么做就是安全的。雖然內(nèi)存管理可以說是自動化的，但是這并不能使編程人員免受思考內(nèi)存管理問題之苦。例如，分配(以及釋放)內(nèi)存總會有開銷，雖然這種開銷對編程人員來說是不可見的。創(chuàng)建了太多對象的程序將會比完成同樣的功能而創(chuàng)建的對象卻比較少的程序更慢一些(在其他條件相同的情況下)。而且，與本文更為密切相關的是，如果忘記“釋放”先前分配的內(nèi)存，就可能造成內(nèi)存泄漏。如果程序保留對永遠不再使用的對象的引用，這些對象將會占用并耗盡內(nèi)存，這是因為自動化的垃圾收集器無法證明這些對象將不再使用。正如我們先前所說的，如果存在一個對對象的引用，對象就被定義為活動的，因此不能刪除。為了確保能回收對象占用的內(nèi)存，編程人員必須確保該對象不能到達。這通常是通過將對象字段設置為null或者從集合(collection)中移除對象而完成的。但是，注意，當局部變量不再使用時，沒有必要將其顯式地設置為null。對這些變量的引用將隨著方法的退出而自動清除。概括地說，這就是內(nèi)存托管語言中的內(nèi)存泄漏產(chǎn)生的主要原因：保留下來卻永遠不再使用的對象引用。典型泄漏既然我們知道了在Java中確實有可能發(fā)生內(nèi)存泄漏，就讓我們來看一些典型的內(nèi)存泄漏及其原因。全局集合在大的應用程序中有某種全局的數(shù)據(jù)儲存庫是很常見的，例如一個JNDI樹或一個會話表。在這些情況下，必須注意管理儲存庫的大小。必須有某種機制從儲存庫中移除不再需要的數(shù)據(jù)。這可能有多種方法，但是最常見的一種是周期性運行的某種清除任務。該任務將驗證儲存庫中的數(shù)據(jù)，并移除任何不再需要的數(shù)據(jù)。另一種管理儲存庫的方法是使用反向鏈接(referrer)計數(shù)。然后集合負責統(tǒng)計集合中每個入口的反向鏈接的數(shù)目。這要求反向鏈接告訴集合何時會退出入口。當反向鏈接數(shù)目為零時，該元素就可以從集合中移除了。緩存緩存是一種數(shù)據(jù)結構，用于快速查找已經(jīng)執(zhí)行的操作的結果。因此，如果一個操作執(zhí)行起來很慢，對于常用的輸入數(shù)據(jù)，就可以將操作的結果緩存，并在下次調用該操作時使用緩存的數(shù)據(jù)。緩存通常都是以動態(tài)方式實現(xiàn)的，其中新的結果是在執(zhí)行時添加到緩存中的。典型的算法是：檢查結果是否在緩存中，如果在，就返回結果。如果結果不在緩存中，就進行計算。將計算出來的結果添加到緩存中，以便以后對該操作的調用可以使用。該算法的問題(或者說是潛在的內(nèi)存泄漏)出在最后一步。如果調用該操作時有相當多的不同輸入，就將有相當多的結果存儲在緩存中。很明顯這不是正確的方法。為了預防這種具有潛在破壞性的設計，程序必須確保對于緩存所使用的內(nèi)存容量有一個上限。因此，更好的算法是：檢查結果是否在緩存中，如果在，就返回結果。如果結果不在緩存中，就進行計算。如果緩存所占的空間過大，就移除緩存最久的結果。將計算出來的結果添加到緩存中，以便以后對該操作的調用可以使用。通過始終移除緩存最久的結果，我們實際上進行了這樣的假設：在將來，比起緩存最久的數(shù)據(jù)，最近輸入的數(shù)據(jù)更有可能用到。這通常是一個不錯的假設。新算法將確保緩存的容量處于預定義的內(nèi)存范圍之內(nèi)。確切的范圍可能很難計算，因為緩存中的對象在不斷變化，而且它們的引用包羅萬象。為緩存設置正確的大小是一項非常復雜的任務，需要將所使用的內(nèi)存容量與檢索數(shù)據(jù)的速度加以平衡。解決這個問題的另一種方法是使用java.lang.ref.SoftReference類跟蹤緩存中的對象。這種方法保證這些引用能夠被移除，如果虛擬機的內(nèi)存用盡而需要更多堆的話。ClassLoaderJavaClassLoader結構的使用為內(nèi)存泄漏提供了許多可乘之機。正是該結構本身的復雜性使ClassLoader在內(nèi)存泄漏方面存在如此多的問題。ClassLoader的特別之處在于它不僅涉及“常規(guī)”的對象引用，還涉及元對象引用，比如:字段、方法和類。這意味著只要有對字段、方法、類或ClassLoader的對象的引用,ClassLoader就會駐留在JVM中。因為ClassLoader本身可以關聯(lián)許多類及其靜態(tài)字段，所以就有許多內(nèi)存被泄漏了。確定泄漏的位置通常發(fā)生內(nèi)存泄漏的第一個跡象是：在應用程序中出現(xiàn)了OutOfMemoryError。這通常發(fā)生在您最不愿意它發(fā)生的生產(chǎn)環(huán)境中，此時幾乎不能進行調試。有可能是因為測試環(huán)境運行應用程序的方式與生產(chǎn)系統(tǒng)不完全相同，因而導致泄漏只出現(xiàn)在生產(chǎn)中。在這種情況下，需要使用一些開銷較低的工具來監(jiān)控和查找內(nèi)存泄漏。還需要能夠無需重啟系統(tǒng)或修改代碼就可以將這些工具連接到正在運行的系統(tǒng)上?？赡茏钪匾氖?，當進行分析時，需要能夠斷開工具而保持系統(tǒng)不受干擾。雖然OutOfMemoryError通常都是內(nèi)存泄漏的信號，但是也有可能應用程序確實正在使用這么多的內(nèi)存；對于后者，或者必須增加JVM可用的堆的數(shù)量，或者對應用程序進行某種更改，使它使用較少的內(nèi)存。但是，在許多情況下，OutOfMemoryError都是內(nèi)存泄漏的信號。一種查明方法是不間斷地監(jiān)控GC的活動，確定內(nèi)存使用量是否隨著時間增加。如果確實如此，就可能發(fā)生了內(nèi)存泄漏。非常多人在談論內(nèi)存泄露問題，當然對于C/C++來說，這個應該是老掉牙的問題，不過非常多Java人員也越來越多得討論這個問題，我這里寫個小結，希望對大家有一定的參考價值。內(nèi)存泄漏的慨念C/C++是程式員自己管理內(nèi)存，Java內(nèi)存是由GC自動回收的。我雖然不是非常熟悉C++，不過這個應該沒有犯常識性錯誤吧。什么是內(nèi)存泄露?內(nèi)存泄露是指系統(tǒng)中存在無法回收的內(nèi)存，有時候會造成內(nèi)存不足或系統(tǒng)崩潰。在C/C++中分配了內(nèi)存不釋放的情況就是內(nèi)存泄露。Java存在內(nèi)存泄露我們必須先承認這個，才能接著討論。雖然Java存在內(nèi)存泄露，不過基本上不用非常關心他，特別是那些對代碼本身就不講究的就更不要去關心這個了。Java中的內(nèi)存泄露當然是指：存在無用不過垃圾回收器無法回收的對象。而且即使有內(nèi)存泄露問題存在，也不一定會表現(xiàn)出來。Java中參數(shù)都是傳值的。對于基本類型，大家基本上沒有異議，不過對于引用類型我們也不能有異議。Java內(nèi)存泄露情況JVM回收算法是非常復雜的，我也不知道他們怎么實現(xiàn)的，不過我只知道他們要實現(xiàn)的就是：對于沒有被引用的對象是能回收的。所以你要造成內(nèi)存泄露就要做到：中國.網(wǎng)管聯(lián)盟持有對無用對象的引用!不要以為這個非常容易做到，既然無用，你怎么還會持有他的引用?既然你還持有他，他怎么會是無用的呢?我實在想不到比那個堆棧更經(jīng)典的例子了,以致于我還要引用別人的例子，下面的例子不是我想到的，是書上看到的，當然如果沒有在書上看到，可能過一段時間我自己也想的到，可是那時我說是我自己想到的也沒有人相信的。publicclassStack{privateObject[]elements=newObject[10];privateintsize=0;publicvoidpush(Objecte){ensureCapacity();elements[size++]=e;}publicObjectpop(){if(size==0)thrownewEmptyStackException();returnelements[--size];}privatevoidensureCapacity(){if(elements.length==size){Object[]oldElements=elements;elements=newObject[2*elements.length+1];System.arraycopy(oldElements,0,elements,0,size);}}}上面的原理應該非常簡單，如果堆棧加了10個元素，然后全部彈出來，雖然堆棧是空的，沒有我們要的東西，不過這是個對象是無法回收的，這個才符合了內(nèi)存泄露的兩個條件：無用，無法回收。中國網(wǎng)管聯(lián)盟不過就是存在這樣的東西也不一定會導致什么樣的后果，如果這個堆棧用的比較少，也就浪費了幾個K內(nèi)存而已，反正我們的內(nèi)存都上G了，哪里會有什么影響，再說這個東西非?？炀蜁换厥盏?，有什么關系。下面看兩個例子。例子1publicclassBad{publicstaticStacks=Stack();static{s.push(newObject());s.pop();//這里有一個對象發(fā)生內(nèi)存泄露s.push(newObject());//上面的對象能被回收了，等于是自愈了}因為是static，就一直存在到程式退出，不過我們也能看到他有自愈功能，就是說如果你的Stack最多有100個對象，那么最多也就只有100個對象無法被回收其實這個應該非常容易理解，Stack內(nèi)部持有100個引用，最壞的情況就是他們都是無用的，因為我們一旦放新的進取，以前的引用自然消失！例子2publicclassNotTooBad{publicvoiddoSomething(){Stacks=newStack();s.push(newObject());//othercodes.pop();〃這里同樣導致對象無法回收，內(nèi)存泄露.}〃退出方法,s自動無效,s能被回收,Stack內(nèi)部的引用自然沒了，所以www_bitscn_com//這里也能自愈,而且能說這個方法不存在內(nèi)存泄露問題,不過是晚一點〃交給GC而已，因為他是封閉的，對外不開放，能說上面的代碼99.9999%的//情況是不會造成所有影響的,當然你寫這樣的代碼不會有什么壞的影響,不過//絕對能說是垃圾代碼!沒有矛盾吧，我在里面加一個空的for循環(huán)也不會有//什么太大的影響吧，你會這么做嗎?}上面兩個例子都不過是小打小鬧，不過C/C++中的內(nèi)存泄露就不是Bad了，而是Worst了。他們?nèi)绻惶帥]有回收就永遠無法回收，頻繁的調用這個方法內(nèi)存不就用光了!因為Java更有自愈功能(我自己起的名字,還沒申請專利)，所以Java的內(nèi)存泄露問題幾乎能忽略了,不過知道的人就不要犯了。不知者無罪!Java存在內(nèi)存泄露，不過也不要夸大其辭。如果你對Java都不是非常熟，你根本就不用關心這個，我說過你無意中寫出內(nèi)存泄露的例子就像你中一千萬相同概率小，開玩笑了，其實應該是小的多的多!而且即使你有幸寫出這樣的代碼，中獎了!基本上都是一包洗衣粉，不會讓你發(fā)財，對系統(tǒng)沒有什么大的影響。杞人憂天的情況無話可說型Objectobj=newObject。；obj=null;//這個完全多此一舉，因為退出了作用范圍，對象的引用自動消失中國網(wǎng)管聯(lián)盟//不要在你的程式中出現(xiàn)這樣的語句，沒有錯，不過就是不雅觀思考不對型voidfunc(Objecto){o=newObject();return}當我們知道Java參數(shù)是傳值，就知道上面的方法什么也沒錯，就是申請了一個對象然后再丟給GC。因為是傳值，這里的o是個調用時候的拷貝,會不會無法回收？不就是拷貝嗎，退出方法什么都沒了，這個對象怎么會留的住。盡量避免型classA{Bb=newB(this);}classB{Aa;B(Aa)}這個存在互相引用，可能導致孤島現(xiàn)象，不過這個不會造成內(nèi)存泄露不過我自己覺得這個會降低GC的效率，就從我的智力來看，我覺得這種情況比一