引言
Java的堆是一個運行時數據區,類的實例(對象)從中分配空間。Java虛擬機(JVM)的堆中儲存着正在運行的應用程序所創建的全部對象,這些對象經過new、newarray、anewarray和multianewarray等指令創建,可是它們不須要程序代碼來顯式地釋放。通常來講,堆的是由垃圾回收 來負責的,儘管JVM規範並不要求特殊的垃圾回收技術,甚至根本就不須要垃圾回收,可是因爲內存的有限性,JVM在實現的時候都有一個由垃圾回收所管理的堆。垃圾回收是一種動態存儲管理技術,它自動地釋放再也不被程序引用的對象,按照特定的垃圾收集算法來實現資源自動回收的功能。
垃圾收集的意義
在C++中,對象所佔的內存在程序結束運行以前一直被佔用,在明確釋放以前不能分配給其它對象;而在Java中,當沒有對象引用指向原先分配給某個對象的內存時,該內存便成爲垃圾。JVM的一個系統級線程會自動釋放該內存塊。垃圾收集意味着程序再也不須要的對象是"無用信息",這些信息將被丟棄。當一個對象再也不被引用的時候,內存回收它佔領的空間,以便空間被後來的新對象使用。事實上,除了釋放沒用的對象,垃圾收集也能夠清除內存記錄碎片。因爲建立對象和垃圾收集器釋放丟棄對象所佔的內存空間,內存會出現碎片。碎片是分配給對象的內存塊之間的空閒內存洞。碎片整理將所佔用的堆內存移到堆的一端,JVM將整理出的內存分配給新的對象。
垃圾收集能自動釋放內存空間,減輕編程的負擔。這使Java 虛擬機具備一些優勢。首先,它能使編程效率提升。在沒有垃圾收集機制的時候,可能要花許多時間來解決一個難懂的存儲器問題。在用Java語言編程的時候,靠垃圾收集機制可大大縮短期。其次是它保護程序的完整性, 垃圾收集是Java語言安全性策略的一個重要部份。
垃圾收集的一個潛在的缺點是它的開銷影響程序性能。Java虛擬機必須追蹤運行程序中有用的對象, 並且最終釋放沒用的對象。這一個過程須要花費處理器的時間。其次垃圾收集算法的不完備性,早先採用的某些垃圾收集算法就不能保證100%收集到全部的廢棄內存。固然隨着垃圾收集算法的不斷改進以及軟硬件運行效率的不斷提高,這些問題均可以迎刃而解。
垃圾收集的算法分析
Java語言規範沒有明確地說明JVM使用哪一種垃圾回收算法,可是任何一種垃圾收集算法通常要作2件基本的事情:(1)發現無用信息對象;(2)回收被無用對象佔用的內存空間,使該空間可被程序再次使用。
大多數垃圾回收算法使用了根集(root set)這個概念;所謂根集就量正在執行的Java程序能夠訪問的引用變量的集合(包括局部變量、參數、類變量),程序可使用引用變量訪問對象的屬性和調用對象的方法。垃圾收集首選須要肯定從根開始哪些是可達的和哪些是不可達的,從根集可達的對象都是活動對象,它們不能做爲垃圾被回收,這也包括從根集間接可達的對象。而根集經過任意路徑不可達的對象符合垃圾收集的條件,應該被回收。下面介紹幾個經常使用的算法。
一、 引用計數法(Reference Counting Collector)
引用計數法是惟一沒有使用根集的垃圾回收的法,該算法使用引用計數器來區分存活對象和再也不使用的對象。通常來講,堆中的每一個對象對應一個引用計數器。當每一次建立一個對象並賦給一個變量時,引用計數器置爲1。當對象被賦給任意變量時,引用計數器每次加1當對象出了做用域後(該對象丟棄再也不使用),引用計數器減1,一旦引用計數器爲0,對象就知足了垃圾收集的條件。
基於引用計數器的垃圾收集器運行較快,不會長時間中斷程序執行,適宜地必須 實時運行的程序。但引用計數器增長了程序執行的開銷,由於每次對象賦給新的變量,計數器加1,而每次現有對象出了做用域生,計數器減1。
二、tracing算法(Tracing Collector)
tracing算法是爲了解決引用計數法的問題而提出,它使用了根集的概念。基於tracing算法的垃圾收集器從根集開始掃描,識別出哪些對象可達,哪些對象不可達,並用某種方式標記可達對象,例如對每一個可達對象設置一個或多個位。在掃描識別過程當中,基於tracing算法的垃圾收集也稱爲標記和清除(mark-and-sweep)垃圾收集器.
三、compacting算法(Compacting Collector)
爲了解決堆碎片問題,基於tracing的垃圾回收吸取了Compacting算法的思想,在清除的過程當中,算法將全部的對象移到堆的一端,堆的另外一端就變成了一個相鄰的空閒內存區,收集器會對它移動的全部對象的全部引用進行更新,使得這些引用在新的位置能識別原來 的對象。在基於Compacting算法的收集器的實現中,通常增長句柄和句柄表。
四、copying算法(Coping Collector)
該算法的提出是爲了克服句柄的開銷和解決堆碎片的垃圾回收。它開始時把堆分紅 一個對象 面和多個空閒面, 程序從對象面爲對象分配空間,當對象滿了,基於coping算法的垃圾 收集就從根集中掃描活動對象,並將每一個 活動對象複製到空閒面(使得活動對象所佔的內存之間沒有空閒洞),這樣空閒面變成了對象面,原來的對象面變成了空閒面,程序會在新的對象面中分配內存。
一種典型的基於coping算法的垃圾回收是stop-and-copy算法,它將堆分紅對象面和空閒區域面,在對象面與空閒區域面的切換過程當中,程序暫停執行。
五、generation算法(Generational Collector)
stop-and-copy垃圾收集器的一個缺陷是收集器必須複製全部的活動對象,這增長了程序等待時間,這是coping算法低效的緣由。在程序設計中有這樣的規律:多數對象存在的時間比較短,少數的存在時間比較長。所以,generation算法將堆分紅兩個或多個,每一個子堆做爲對象的一代(generation)。因爲多數對象存在的時間比較短,隨着程序丟棄不使用的對象,垃圾收集器將從最年輕的子堆中收集這些對象。在分代式的垃圾收集器運行後,上次運行存活下來的對象移到下一最高代的子堆中,因爲老一代的子堆不會常常被回收,於是節省了時間。
六、adaptive算法(Adaptive Collector)
在特定的狀況下,一些垃圾收集算法會優於其它算法。基於Adaptive算法的垃圾收集器就是監控當前堆的使用狀況,並將選擇適當算法的垃圾收集器。
透視Java垃圾回收
一、命令行參數透視垃圾收集器的運行
二、使用System.gc()能夠無論JVM使用的是哪種垃圾回收的算法,均可以請求Java的垃圾回收。在命令行中有一個參數-verbosegc能夠查看Java使用的堆內存的狀況,它的格式以下:
java -verbosegc classfile
能夠看個例子:
class TestGC
{
public static void main(String[] args)
{
new TestGC();
System.gc();
System.runFinalization();
}
}
在這個例子中,一個新的對象被建立,因爲它沒有使用,因此該對象迅速地變爲可達,程序編譯後,執行命令: java -verbosegc TestGC 後結果爲:
[Full GC 168K->97K(1984K), 0.0253873 secs]
機器的環境爲,Windows 2000 + JDK1.3.1,箭頭先後的數據168K和97K分別表示垃圾收集GC先後全部存活對象使用的內存容量,說明有168K-97K=71K的對象容量被回收,括號內的數據1984K爲堆內存的總容量,收集所須要的時間是0.0253873秒(這個時間在每次執行的時候會有所不一樣)。
二、finalize方法透視垃圾收集器的運行
在JVM垃圾收集器收集一個對象以前 ,通常要求程序調用適當的方法釋放資源,但在沒有明確釋放資源的狀況下,Java提供了缺省機制來終止化該對象心釋放資源,這個方法就是finalize()。它的原型爲:
protected void finalize() throws Throwable
在finalize()方法返回以後,對象消失,垃圾收集開始執行。原型中的throws Throwable表示它能夠拋出任何類型的異常。
之因此要使用finalize(),是因爲有時須要採起與Java的普通方法不一樣的一種方法,經過分配內存來作一些具備C風格的事情。這主要能夠經過"固有方法"來進行,它是從Java裏調用非Java方法的一種方式。C和C++是目前惟一得到固有方法支持的語言。但因爲它們能調用經過其餘語言編寫的子程序,因此可以有效地調用任何東西。在非Java代碼內部,也許能調用C的malloc()系列函數,用它分配存儲空間。並且除非調用了free(),不然存儲空間不會獲得釋放,從而形成內存"漏洞"的出現。固然,free()是一個C和C++函數,因此咱們須要在finalize()內部的一個固有方法中調用它。也就是說咱們不能過多地使用finalize(),它並非進行普通清除工做的理想場所。
在普通的清除工做中,爲清除一個對象,那個對象的用戶必須在但願進行清除的地點調用一個清除方法。這與C++"破壞器"的概念稍有抵觸。在C++中,全部對象都會破壞(清除)。或者換句話說,全部對象都"應該"破壞。若將C++對象建立成一個本地對象,好比在堆棧中建立(在Java中是不可能的),那麼清除或破壞工做就會在"結束花括號"所表明的、建立這個對象的做用域的末尾進行。若對象是用new建立的(相似於Java),那麼當程序員調用C++的delete命令時(Java沒有這個命令),就會調用相應的破壞器。若程序員忘記了,那麼永遠不會調用破壞器,咱們最終獲得的將是一個內存"漏洞",另外還包括對象的其餘部分永遠不會獲得清除。
相反,Java不容許咱們建立本地(局部)對象--不管如何都要使用new。但在Java中,沒有"delete"命令來釋放對象,由於垃圾收集器會幫助咱們自動釋放存儲空間。因此若是站在比較簡化的立場,咱們能夠說正是因爲存在垃圾收集機制,因此Java沒有破壞器。然而,隨着之後學習的深刻,就會知道垃圾收集器的存在並不能徹底消除對破壞器的須要,或者說不能消除對破壞器表明的那種機制的須要(並且絕對不能直接調用finalize(),因此應儘可能避免用它)。若但願執行除釋放存儲空間以外的其餘某種形式的清除工做,仍然必須調用Java中的一個方法。它等價於C++的破壞器,只是沒後者方便。
下面這個例子向你們展現了垃圾收集所經歷的過程,並對前面的陳述進行了總結。
class Chair {
static boolean gcrun = false;
static boolean f = false;
static int created = 0;
static int finalized = 0;
int i;
Chair() {
i = ++created;
if(created == 47)
System.out.println("Created 47");
}
protected void finalize() {
if(!gcrun) {
gcrun = true;
System.out.println("Beginning to finalize after " + created + " Chairs have been created");
}
if(i == 47) {
System.out.println("Finalizing Chair #47, " +"Setting flag to stop Chair creation");
f = true;
}
finalized++;
if(finalized >= created)
System.out.println("All " + finalized + " finalized");
}
}
public class Garbage {
public static void main(String[] args) {
if(args.length == 0) {
System.err.println("Usage: \n" + "java Garbage before\n or:\n" + "java Garbage after");
return;
}
while(!Chair.f) {
new Chair();
new String("To take up space");
}
System.out.println("After all Chairs have been created:\n" + "total created = " + Chair.created +
", total finalized = " + Chair.finalized);
if(args[0].equals("before")) {
System.out.println("gc():");
System.gc();
System.out.println("runFinalization():");
System.runFinalization();
}
System.out.println("bye!");
if(args[0].equals("after"))
System.runFinalizersOnExit(true);
}
}
上面這個程序建立了許多Chair對象,並且在垃圾收集器開始運行後的某些時候,程序會中止建立Chair。因爲垃圾收集器可能在任什麼時候間運行,因此咱們不能準確知道它在什麼時候啓動。所以,程序用一個名爲gcrun的標記來指出垃圾收集器是否已經開始運行。利用第二個標記f,Chair可告訴main()它應中止對象的生成。這兩個標記都是在finalize()內部設置的,它調用於垃圾收集期間。另兩個static變量--created以及finalized--分別用於跟蹤已建立的對象數量以及垃圾收集器已進行完收尾工做的對象數量。最後,每一個Chair都有它本身的(非static)int i,因此能跟蹤瞭解它具體的編號是多少。編號爲47的Chair進行完收尾工做後,標記會設爲true,最終結束Chair對象的建立過程。
關於垃圾收集的幾點補充
通過上述的說明,能夠發現垃圾回收有如下的幾個特色:
(1)垃圾收集發生的不可預知性:因爲實現了不一樣的垃圾收集算法和採用了不一樣的收集機制,因此它有多是定時發生,有多是當出現系統空閒CPU資源時發生,也有多是和原始的垃圾收集同樣,等到內存消耗出現極限時發生,這與垃圾收集器的選擇和具體的設置都有關係。
(2)垃圾收集的精確性:主要包括2 個方面:(a)垃圾收集器可以精確標記活着的對象;(b)垃圾收集器可以精確地定位對象之間的引用關係。前者是徹底地回收全部廢棄對象的前提,不然就可能形成內存泄漏。然後者則是實現歸併和複製等算法的必要條件。全部不可達對象都可以可靠地獲得回收,全部對象都可以從新分配,容許對象的複製和對象內存的縮並,這樣就有效地防止內存的支離破碎。
(3)如今有許多種不一樣的垃圾收集器,每種有其算法且其表現各異,既有當垃圾收集開始時就中止應用程序的運行,又有當垃圾收集開始時也容許應用程序的線程運行,還有在同一時間垃圾收集多線程運行。
(4)垃圾收集的實現和具體的JVM 以及JVM的內存模型有很是緊密的關係。不一樣的JVM 可能採用不一樣的垃圾收集,而JVM 的內存模型決定着該JVM能夠採用哪些類型垃圾收集。如今,HotSpot 系列JVM中的內存系統都採用先進的面向對象的框架設計,這使得該系列JVM均可以採用最早進的垃圾收集。
(5)隨着技術的發展,現代垃圾收集技術提供許多可選的垃圾收集器,並且在配置每種收集器的時候又能夠設置不一樣的參數,這就使得根據不一樣的應用環境得到最優的應用性能成爲可能。
針對以上特色,咱們在使用的時候要注意:
(1)不要試圖去假定垃圾收集發生的時間,這一切都是未知的。好比,方法中的一個臨時對象在方法調用完畢後就變成了無用對象,這個時候它的內存就能夠被釋放。
(2)Java中提供了一些和垃圾收集打交道的類,並且提供了一種強行執行垃圾收集的方法--調用System.gc(),但這一樣是個不肯定的方法。Java 中並不保證每次調用該方法就必定可以啓動垃圾收集,它只不過會向JVM發出這樣一個申請,究竟是否真正執行垃圾收集,一切都是個未知數。
(3)挑選適合本身的垃圾收集器。通常來講,若是系統沒有特殊和苛刻的性能要求,能夠採用JVM的缺省選項。不然能夠考慮使用有針對性的垃圾收集器,好比增量收集器就比較適合實時性要求較高的系統之中。系統具備較高的配置,有比較多的閒置資源,能夠考慮使用並行標記/清除收集器。
(4)關鍵的也是難把握的問題是內存泄漏。良好的編程習慣和嚴謹的編程態度永遠是最重要的,不要讓本身的一個小錯誤致使內存出現大漏洞。
(5)儘早釋放無用對象的引用。大多數程序員在使用臨時變量的時候,都是讓引用變量在退出活動域(scope)後,自動設置爲null,暗示垃圾收集器來收集該對象,還必須注意該引用的對象是否被監聽,若是有,則要去掉監聽器,而後再賦空值。
結束語
通常來講,Java開發人員能夠不重視JVM中堆內存的分配和垃圾處理收集,可是,充分理解Java的這一特性可讓咱們更有效地利用資源。同時要注意finalize()方法是Java的缺省機制,有時爲確保對象資源的明確釋放,能夠編寫本身的finalize方法。