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