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