1.9 Java的內(nèi)存泄漏
一 問題的提出
Java的一個(gè)重要優(yōu)點(diǎn)就是通過垃圾收集器(Garbage Collection,GC)自動(dòng)管理內(nèi)存的回收,程序員不需要通過調(diào)用函數(shù)來釋放內(nèi)存。因此,很多程序員認(rèn)為Java不存在內(nèi)存泄漏問題,或者認(rèn)為即使有內(nèi)存泄漏也不是程序的責(zé)任,而是GC或JVM的問題。其實(shí),這種想法是不正確的,因?yàn)镴ava也存在內(nèi)存泄露,但它的表現(xiàn)與C++不同。
隨著越來越多的服務(wù)器程序采用Java技術(shù),例如JSP,Servlet, EJB等,服務(wù)器程序往往長期運(yùn)行。另外,在很多嵌入式系統(tǒng)中,內(nèi)存的總量非常有限。內(nèi)存泄露問題也就變得十分關(guān)鍵,即使每次運(yùn)行少量泄漏,長期運(yùn)行之后,系統(tǒng)也是面臨崩潰的危險(xiǎn)。
二 Java是如何管理內(nèi)存
為了判斷Java中是否有內(nèi)存泄露,我們首先必須了解Java是如何管理內(nèi)存的。Java的內(nèi)存管理就是對(duì)象的分配和釋放問題。在Java中,程序員需要通過關(guān)鍵字new為每個(gè)對(duì)象申請內(nèi)存空間 (基本類型除外),所有的對(duì)象都在堆 (Heap)中分配空間。另外,對(duì)象的釋放是由GC決定和執(zhí)行的。在Java中,內(nèi)存的分配是由程序完成的,而內(nèi)存的釋放是有GC完成的,這種收支兩條線的方法確實(shí)簡化了程序員的工作。但同時(shí),它也加重了JVM的工作。這也是Java程序運(yùn)行速度較慢的原因之一。因?yàn),GC為了能夠正確釋放對(duì)象,GC必須監(jiān)控每一個(gè)對(duì)象的運(yùn)行狀態(tài),包括對(duì)象的申請、引用、被引用、賦值等,GC都需要進(jìn)行監(jiān)控。
監(jiān)視對(duì)象狀態(tài)是為了更加準(zhǔn)確地、及時(shí)地釋放對(duì)象,而釋放對(duì)象的根本原則就是該對(duì)象不再被引用。
為了更好理解GC的工作原理,我們可以將對(duì)象考慮為有向圖的頂點(diǎn),將引用關(guān)系考慮為圖的有向邊,有向邊從引用者指向被引對(duì)象。另外,每個(gè)線程對(duì)象可以作為一個(gè)圖的起始頂點(diǎn),例如大多程序從main進(jìn)程開始執(zhí)行,那么該圖就是以main進(jìn)程頂點(diǎn)開始的一棵根樹。在這個(gè)有向圖中,根頂點(diǎn)可達(dá)的對(duì)象都是有效對(duì)象,GC將不回收這些對(duì)象。如果某個(gè)對(duì)象 (連通子圖)與這個(gè)根頂點(diǎn)不可達(dá)(注意,該圖為有向圖),那么我們認(rèn)為這個(gè)(這些)對(duì)象不再被引用,可以被GC回收。
以下,我們舉一個(gè)例子說明如何用有向圖表示內(nèi)存管理。對(duì)于程序的每一個(gè)時(shí)刻,我們都有一個(gè)有向圖表示JVM的內(nèi)存分配情況。以下右圖,就是左邊程序運(yùn)行到第6行的示意圖。
Java使用有向圖的方式進(jìn)行內(nèi)存管理,可以消除引用循環(huán)的問題,例如有三個(gè)對(duì)象,相互引用,只要它們和根進(jìn)程不可達(dá)的,那么GC也是可以回收它們的。這種方式的優(yōu)點(diǎn)是管理內(nèi)存的精度很高,但是效率較低。另外一種常用的內(nèi)存管理技術(shù)是使用計(jì)數(shù)器,例如COM模型采用計(jì)數(shù)器方式管理構(gòu)件,它與有向圖相比,精度行低(很難處理循環(huán)引用的問題),但執(zhí)行效率很高。
相關(guān)推薦:計(jì)算機(jī)等級(jí)考試二級(jí)Java經(jīng)典算法大全匯總北京 | 天津 | 上海 | 江蘇 | 山東 |
安徽 | 浙江 | 江西 | 福建 | 深圳 |
廣東 | 河北 | 湖南 | 廣西 | 河南 |
海南 | 湖北 | 四川 | 重慶 | 云南 |
貴州 | 西藏 | 新疆 | 陜西 | 山西 |
寧夏 | 甘肅 | 青海 | 遼寧 | 吉林 |
黑龍江 | 內(nèi)蒙古 |