【正文】 的垃圾收集方案，這種方案中垃圾收集不是建立在引用記數(shù)的基礎(chǔ)上。 相反，它的思想是任何沒死的對象最終一定會在棧和靜態(tài)存貯器里找到相應(yīng)存活的引用。這種鏈?zhǔn)降牟檎曳绞娇赡軞v遍幾個(gè)層次的對象組。因此，如果從棧和靜態(tài)存貯器里開始 并歷遍整個(gè)引用組，你會找到所有存活的對象。對于你找到的每個(gè)單引用，你必須找到它所指向的對象，然后發(fā)覺那個(gè)對象的所有引用，接著找到那些引用所指向的所有對象，依次類推，直到你歷遍整個(gè)由棧和靜態(tài)存貯器里的引用所形成的網(wǎng)。每個(gè)你找到的對象必須還存活著。注意，這里不存在分離的自我引用的對象組 ——他們只是沒被查找到，因此被自動(dòng)當(dāng)作垃圾。 在上述提到的垃圾收集方案中， JVM 使用了一種自適應(yīng)的垃圾收集方案，它對查找到的存活對象采取的措施依賴于它正在使用的方案變體。其中的一個(gè)變體就是 stopandcopy。 它意味著 ——基于一些明顯的原因 ——程序首先停止運(yùn)行（這不是一種在后臺實(shí)施的垃圾收集方案）。然后，每一個(gè)活著的對象從一個(gè)堆里被拷貝到另一個(gè)堆里，同時(shí)被拷貝的活對象和死的對象被當(dāng)作垃圾遺棄。并且，當(dāng)對象被拷貝到新的堆里后，他們在那里被一個(gè)挨一個(gè)塞緊，因此實(shí)現(xiàn)了壓縮新堆的目的（而且如前所述，這種方式騰出了壓縮后多余出來的新的空間）。當(dāng)然，對象從一個(gè)地方移動(dòng)到另一個(gè)地方的時(shí)候，所有指向?qū)ο蟮囊帽仨毾鄳?yīng)改變。 指向堆或者靜態(tài)存貯器里某個(gè)被移動(dòng)對象的引用可以立即得到改變，但是還存在其它后來 “在走走 ”的時(shí)候才會碰到的指向該對象 的引用。 這些引用一旦發(fā)現(xiàn)就會被修改。（你可以想象存在一張映射舊新地址的表）。 有兩個(gè)問題使這種所謂的 “拷貝型收集器 ”缺乏效率。 第一個(gè)問題就是你使用了兩個(gè)堆，為了維護(hù)兩倍于你實(shí)際所需要的內(nèi)存空間，你得在這兩個(gè)堆之間來回?cái)噭?dòng)著整個(gè)內(nèi)存空間。 一些 JVMs 通過依據(jù)實(shí)際所需來為堆分配大塊內(nèi)存，然后很簡單地從一個(gè)塊拷貝對象到另一個(gè)。第二個(gè)問題是拷貝過程本身。 一旦你地程序趨向于穩(wěn)定的時(shí)候，它可能生成很少或者幾乎不生成垃圾。 然而 本科生畢業(yè)設(shè)計(jì)（論文） 第 8 頁 stopandcopy 方案不管這些，拷貝型垃圾收集器依舊 把活對象占用的空間從一個(gè)地方拷貝到另一個(gè)地方，這就形成了浪費(fèi)。 為了阻止這種情況的發(fā)生，一些 JVMs 會探測沒有新垃圾產(chǎn)生的時(shí)機(jī)，并且會轉(zhuǎn)向?qū)嵤┝硗庖粋€(gè)完全不同的垃圾收集方案。 這種不同的方案被稱為 markandsweep，并且它是 Sun 的早期 JVM 版本一直使用的方案。 處理一般的垃圾收集工作， markandsweep 表現(xiàn)得相當(dāng)?shù)芈?，但是?dāng)你的程序生成很少或者不生成垃圾時(shí)，它又運(yùn)行得很快。 Markandsweep 遵循著和 stopandcopy 一樣的邏輯：從棧和靜態(tài)存貯器里出發(fā)，跟蹤所有的引用從而找到存活的對象。 不過，每次它找到活對象的時(shí)候，那個(gè)對象被做以標(biāo)記，而且對象還不會被收集起來。 只有在整個(gè)標(biāo)記過程完成后，清掃（ sweep）工作才真正開始。在清掃過程中，死對象被釋放存貯空間。不過， Markandsweep 方案的實(shí)施過程并沒有拷貝壓縮的步驟發(fā)生，所以如果垃圾收集器打算壓縮已經(jīng)成為碎片的堆，它會采用如同洗牌一樣的方式來重新安排對象的散亂分布。 stopandcopy 的思想是垃圾收集不在后臺完成，相反，程序需要停止運(yùn)行的同時(shí)垃圾收集開始工作。在 Sun 的文獻(xiàn)資 料里，你會發(fā)現(xiàn)很多資料認(rèn)為垃圾收集是一種低優(yōu)先性的后臺進(jìn)程，但事實(shí)上垃圾收集在早期的 Sun JVM 版本里并不是這樣執(zhí)行地。相反，當(dāng)內(nèi)存閑置空間少的時(shí)候， Sun 的垃圾收集器會終止程序運(yùn)行。 Markandsweep 也需要程序被終止。 正如前面提到的，在這里描述的 JVM 里，內(nèi)存被分配成大的塊。 如果你指定了一個(gè)大的對象，它將會得到它自己的內(nèi)存塊。 嚴(yán)格意義上的 stopandcopy 在可以釋放舊堆之前，需要從源堆里拷貝每一個(gè)活著的對象到新的堆里，這會耗費(fèi)大量內(nèi)存。 而有了塊的概念，垃圾收集 器在收集的時(shí)候就能夠拷貝對象到死的塊里。每一個(gè)塊都有一個(gè)生成數(shù)用來跟蹤它是否還活著。正常情況下，只有自上次垃圾收集后創(chuàng)建的塊才被壓縮；所有別的塊，如果在什么地方被引用的話，相應(yīng)的生成記數(shù)會增加。 這種方式解決了通常情況下許多短期生存的暫時(shí)對象。徹底的清掃工作會周期性進(jìn)行。大的對象仍舊不拷貝（他們只是把自己的生成記數(shù)增加），而那些包含小對象的塊會被拷貝和壓縮。 JVM 會監(jiān)視垃圾收集的效率，如果是因?yàn)樗械膶ο蠖挤€(wěn)定運(yùn)行而使得收集工作比較浪費(fèi)時(shí)間的話，垃圾收集會轉(zhuǎn)向 markandsweep 模式。 同樣 地， JVM 也會跟蹤 markandsweep 的運(yùn)行效果，如果堆開始變得零碎 本科生畢業(yè)設(shè)計(jì)（論文） 第 9 頁 不堪，垃收集又會轉(zhuǎn)回 stopandcopy 模式。 這就是 “自適應(yīng) ”概念的來源，所以你能總結(jié)出一句冗長拗口的話： “自適應(yīng)地分階段地 stopandcopy markandsweep。 ”JVM 里，可能會有一些附帶的加速技術(shù)。 一項(xiàng)很重要的技術(shù)就涉及到那個(gè)加載程序的操作，它被稱為 justintime（ JIT）編譯器。 JIT 編譯器能部分或者全部把程序轉(zhuǎn)換成機(jī)器能夠識別的代碼，所以程序就不需要 JVM 的解 釋了，結(jié)果是程序運(yùn)行起來快很多。當(dāng)必須加載類的時(shí)候（特別是你第一次想創(chuàng)建那個(gè)類的對象的時(shí)候），首先定位 .class 文件，然后相應(yīng)的字節(jié)碼被送入內(nèi)存。 這個(gè)時(shí)候，一個(gè)可以利用的方式就是直接讓 JIT 編譯所有的代碼，但是這樣做有兩個(gè)缺點(diǎn)： 這種方式的應(yīng)用由于混雜在程序的整個(gè)生命周期里，所以能累加起來，從而導(dǎo)致程序執(zhí)行起來會花費(fèi)一些額外的時(shí)間；另外它也增加了可執(zhí)行程序的尺寸（字節(jié)碼要比已擴(kuò)展的 JIT 代碼壓縮度高出很多），因此有可能導(dǎo)致虛擬內(nèi)存的使用，結(jié)果明顯地降低了程序的運(yùn)行效率。一個(gè)替代方案就是 lazy evaluation，它的意思是直到代碼需要的時(shí)候，才用 JIT 來編譯。 因此，從來都不執(zhí)行的代碼可能永遠(yuǎn)都不被 JIT 編譯。 在最近的 JDKV 里采用的 Java HotSpot 技術(shù)也使用了一種類似方案，一段代碼每執(zhí)行一次，該技術(shù)就優(yōu)化一次代碼，所以運(yùn)行的次數(shù)越多，代碼執(zhí)行的速度就越快。