對(duì)象是使用new創(chuàng)建的，但是并沒有與之相對(duì)應(yīng)的delete操作來回收對(duì)象占用的內(nèi)存。當(dāng)我們完成對(duì)某個(gè)對(duì)象的使用時(shí)，只需停止對(duì)該對(duì)象的引用:將我們的引用改變?yōu)橹赶蚱渌麑?duì)象或指向null;或者從方法中返回，使得該方法的局部變量不復(fù)存在，從而使得對(duì)這些局部變量的引用變?yōu)椴恢赶蛉魏螌?duì)象。不再被引用的對(duì)象被稱為垃圾(garbage)，查找并回收這些對(duì)象的過程叫做垃圾回收(garbage collection) o

　　Java虛擬機(jī)利用垃圾回收來保證被引用的對(duì)象將會(huì)在內(nèi)存中保留，同時(shí)會(huì)釋放在執(zhí)行代碼中通過任何引用都不可達(dá)的對(duì)象所占用的存儲(chǔ)空間。這是一種強(qiáng)保證—如果順著從根引用(即在執(zhí)行代碼中可以直接訪問的引用)開始的引用鏈可以到達(dá)某個(gè)對(duì)象，那么該對(duì)象就不會(huì)被回收。

　　簡(jiǎn)言之，當(dāng)我們從任何可執(zhí)行代碼都無法到達(dá)某個(gè)對(duì)象時(shí)，它所占用的空間就可以被回收。注意，我們用的是“可以”這個(gè)詞，因?yàn)閮?nèi)存空間是否回收是由垃圾回收器來決定的，通常情況下，只有需要更多的內(nèi)存空間或者為了避免發(fā)生內(nèi)存溢出時(shí)，垃圾回收器才會(huì)運(yùn)行。但是程序可能在沒有發(fā)生內(nèi)存溢出，甚至在沒有接近內(nèi)存溢出的時(shí)候就退出了，所以可能根本就不需要執(zhí)行垃圾回收。在當(dāng)前執(zhí)行的所有方法中，如果所有變量都不包含指向某個(gè)對(duì)象的引用，并且從這些變量出發(fā)，順著引用鏈在所有域或數(shù)組元素中也找不到對(duì)這個(gè)對(duì)象的引用，那么我們就說這個(gè)對(duì)象是“不可達(dá)的”。

　　垃圾回收意味著我們永遠(yuǎn)不必?fù)?dān)心出現(xiàn)虛懸引用(dangling reference)。在那些可以由程序員直接控制何時(shí)刪除對(duì)象的系統(tǒng)中，程序員可以刪除某個(gè)其他對(duì)象還在引用的對(duì)象，如果程序員刪除了這樣的對(duì)象，那么還在引用被刪除對(duì)象的引用就會(huì)變?yōu)樘搼业?，因?yàn)樗鼈円玫氖遣?/p>

　　作系統(tǒng)認(rèn)為是可分配的內(nèi)存空間(但實(shí)際上該空間已經(jīng)被釋放)。系統(tǒng)可以將這個(gè)可分配空間分配給新的對(duì)象，這樣那些原來指向該空間的引用實(shí)際上得到的對(duì)象與它們所預(yù)期的就完全不同了。在這種情況下，當(dāng)程序使用存儲(chǔ)于這個(gè)空間中的值并將其當(dāng)作它們并不屬于的對(duì)象來操作時(shí)，就可能會(huì)引起不可預(yù)知的災(zāi)難。垃圾回收為我們解決了虛懸引用問題，因?yàn)樗腥匀槐灰玫膶?duì)象都不會(huì)被當(dāng)作垃圾回收，所以它們所占用的空間也不可能被釋放。垃圾回收同時(shí)還解決了意外地多次刪除同一個(gè)對(duì)象的問題—這種問題也會(huì)引發(fā)災(zāi)難。 垃圾對(duì)象的回收并不需要我們的介入，但是回收垃圾會(huì)占用一定的系統(tǒng)資源。大量對(duì)象的創(chuàng)建和回收對(duì)時(shí)間關(guān)鍵的應(yīng)用會(huì)產(chǎn)生干擾，因此我們?cè)谠O(shè)計(jì)這種系統(tǒng)時(shí)，要審慎地處理創(chuàng)建的對(duì)象數(shù)量，以便減少要回收的垃圾數(shù)量。

　　垃圾回收并不能保證內(nèi)存總是會(huì)有空間來創(chuàng)建新對(duì)象。例如，如果我們不停地創(chuàng)建對(duì)象，并把這些對(duì)象置于某個(gè)列表中，那么當(dāng)沒有足夠的空間來創(chuàng)建新對(duì)象，同時(shí)也沒有任何未被引用的對(duì)象時(shí)，就無法再創(chuàng)建新對(duì)象了。如果我們讓上述列表保持對(duì)不再需要的對(duì)象的引用，那么就會(huì)造成內(nèi)存泄漏。垃圾回收解決了很多(但并非全部)的內(nèi)存分配問題。

與垃圾回收器交互
盡管Java語(yǔ)言本身沒有任何顯式地處置空閑對(duì)象的方法，我們還是可以通過直接調(diào)用垃圾回收器來尋找不再使用的對(duì)象。Runtime類以及system類中的一些便捷方法使得我們可以調(diào)用垃圾回收器，請(qǐng)求運(yùn)行所有待運(yùn)行的終結(jié)器，或者查看當(dāng)前的內(nèi)存狀態(tài):

　　.public void gc Q:該方法請(qǐng)求Java虛擬機(jī)花費(fèi)精力去回收不再使用的對(duì)象，以便能夠重用這些對(duì)象所占據(jù)的內(nèi)存。

　　.public void runFinalization():該方法請(qǐng)求Java虛擬機(jī)花費(fèi)精力去運(yùn)行如下的終結(jié)器:那些已經(jīng)被發(fā)現(xiàn)是不可達(dá)的，但是其終結(jié)器還未執(zhí)行的對(duì)象。

　　“public long freememory():返回系統(tǒng)內(nèi)存可用字節(jié)的估測(cè)數(shù)。

　　·public long total Memory ():返回系統(tǒng)內(nèi)存的總字節(jié)數(shù)。

　　.public long maxmemoryo:返回Java虛擬機(jī)可用的系統(tǒng)內(nèi)存的最大字節(jié)數(shù)。如果操作系統(tǒng)對(duì)Java虛擬機(jī)沒有內(nèi)存使用上的限制，將返回Long . MAX-VALUE. Java中沒有任何用來設(shè)置系統(tǒng)最大內(nèi)存的方法，通常，Java虛擬機(jī)是通過命令行或者其他配置選項(xiàng)來設(shè)置這個(gè)值的。

　　要調(diào)用上述方法，我們需要通過靜態(tài)方法Runtime.getRuntime來獲取對(duì)當(dāng)前Runtime對(duì)象的引用。而system類支持靜態(tài)的gc和runFinalization方法，它們將調(diào)用當(dāng)前Runt-ime對(duì)象上的相應(yīng)方法;換句話說，System.gc()與Runtime.getRuntime().gc()方法是等價(jià)的。

　　在調(diào)用Runtime.gc()方法時(shí)，垃圾回收器可能并不能釋放出任何額外的內(nèi)存，因?yàn)榭赡懿]有垃圾可以回收，而且并非所有的垃圾回收器都可以按需發(fā)現(xiàn)可回收對(duì)象。因此調(diào)用垃圾回收器可能不會(huì)產(chǎn)生任何效果。然而，在創(chuàng)建大量的對(duì)象之前，特別是在垃圾回收的開銷可能會(huì)對(duì)其造成影響的時(shí)間關(guān)鍵的應(yīng)用中，調(diào)用Runtime.gc()方法還是可取的。執(zhí)行它有兩點(diǎn)潛在的好處:第一點(diǎn)是我們?cè)谶\(yùn)行應(yīng)用程序之前可以得到盡可能多的內(nèi)存，第二點(diǎn)是我們可以降低執(zhí)行任務(wù)期間垃圾回收器運(yùn)行的可能性。下面的方法在運(yùn)行時(shí)刻積極地釋放了可以釋放的所有空間:

　　public static vo記ful1GC(){

　　Runtime rt=Runtime.getRuntime();

　　long isFree=rt.freeMemory ();

　　long wasFree;

　　do{

　　wasFree=isFree;

　　rt.runFinalization ();

　　rt.gc();

　　isFree二rt.freeMemory();

　　}while (isFree>wasFree);

　　}

　　該方法在不斷地循環(huán)，通過連續(xù)調(diào)用runFinalization和gc方法，freememory的值不斷地增大。當(dāng)空閑內(nèi)存的數(shù)量不再增大時(shí)，該方法的循環(huán)也就結(jié)束了。

　　我們通常不需要調(diào)用runFinalization方法，因?yàn)閒inalize方法是由垃圾回收器異步調(diào)用的。在某些情況下，例如某項(xiàng)可以由finalize方法回收的資源被耗盡時(shí)，通過調(diào)用run-Finalization來強(qiáng)制執(zhí)行盡可能多的終結(jié)才會(huì)顯得有用。但是請(qǐng)記住，我們并不能保證任何等待被終結(jié)的對(duì)象都在使用這項(xiàng)資源，因此runFinalization可能不會(huì)有任何作用。

　　fullGc方法對(duì)于大多數(shù)應(yīng)用程序來說都顯得過于激進(jìn)。在需要強(qiáng)制進(jìn)行垃圾回收的特殊情況下，對(duì)system.gc方法的單次調(diào)用所收集到的垃圾即便不是全部的可利用垃圾，也是其中的絕大部分，因此重復(fù)調(diào)用會(huì)降低垃圾回收的產(chǎn)出率，而且在許多系統(tǒng)中，這些重復(fù)調(diào)用是毫無產(chǎn)出的。

最新評(píng)論