畢業(yè)設(shè)計外文文獻(xiàn)翻譯---java垃圾收集器的工作方式-預(yù)覽頁
【正文】 ugh must still be alive. Note that there is no problem with detached selfreferential groups—these are simply not found, and are therefore automatically garbage. In the approach described here, the JVM uses an adaptive garbagecollection scheme, and what it does with the live objects that it locates depends on the variant currently being used. One of these variants is stopandcopy. This means that—for reasons that will bee apparent—the program is first stopped (this is not a background collection scheme). Then, each live object is copied from one heap to another, leaving behind all the garbage. In addition, as the objects are copied into the new heap, they are packed endtoend, thus pacting the new heap (and allowing 3 new storage to simply be reeled off the end as previously described). Of course, when an object is moved from one place to another, all references that point at the object must be changed. The reference that goes from the heap or the static storage area to the object can be changed right away, but there can be other references pointing to this object Initialization amp。 and it increases the size of the executable (byte codes are significantly more pact than expanded JIT code), and this might cause paging, which definitely slows down a program. An alternative 5 approach is lazy evaluation, which means that the code is not JIT piled until necessary. Thus, code that never gets executed might never be JIT piled. The Java Hotspot technologies in recent JDKs take a similar approach by increasingly optimizing a piece of code each time it is executed, so the more the code is executed, the faster it gets. 6 中文譯文 Java 垃圾收集器的工作方式 如果你學(xué)下過一種因為在堆里分配對象所以開銷過大的編程語言，很自然你可能會假定 Java 在堆里為每一樣?xùn)|西（除了 primitives）分配內(nèi)存資源的機(jī)制開銷也會很大。在 Java 的 JVM 里，堆的工作方式完全不同；每次為一個新的對象分配存貯空間的時候，它就更像是一個不斷向前移動的傳送帶。） 你或許觀察到實際上堆本身并不是一個傳送帶，如果你真 的那樣看待堆，你就會啟用虛擬內(nèi)存 ——在硬盤里不斷地裝卸，結(jié)果是看上去你會擁有比實際情況還要多的內(nèi)存空間。 要想理解 Java 的垃圾收集工作，先了解一下別的語言系統(tǒng)里垃圾收集所使用的方案是有幫助的。垃圾收集器歷遍整 7 組對象，當(dāng)它發(fā)現(xiàn)一個引用記數(shù)為零的對象時就會釋放那個對象的存貯空間。引用記數(shù)通常被用來解釋一類垃圾收集的工作原理，但是它似乎沒被任何一種 JVM 所采納。因此，如果從棧和靜態(tài)存貯器里開始并歷遍整個引用組，你會找到所有存活的對象。 在上述提到的垃圾收集方案中， JVM 使用了一種自適應(yīng)的垃圾收集方案，它對查找到的存活對象采取的措施依賴于它正在使用的方案變體。并且，當(dāng)對象被拷貝到新的堆里后，他們在那里被一個挨一個塞緊，因此實現(xiàn)了壓縮新堆的目的（而且如前所述，這種方式騰出了壓縮后多余出來的新的空間）。（你可以想象存在一張映射舊新地址的表）。第二個問題是拷貝過程本身。 這種不同的方案被稱為 markandsweep，并且它是 Sun 的早期 JVM 版本一直使用的方案。 只有在整個標(biāo)記過程完成后，清掃（ sweep）工作才真正開始。在 Sun 的文獻(xiàn)資料里，你會發(fā)現(xiàn)很多 資料認(rèn)為垃圾收集是一種低優(yōu)先性的后臺進(jìn)程，但事實上垃圾收集在早期的 Sun JVM 版本里并不是這樣執(zhí)行地。 如果你指定了一個大的對象，它將會得到它自己的內(nèi)存塊。正常情況下，只有自上次垃圾收集后創(chuàng)建的塊才被壓縮；所有別的塊，如果在什么地方被引用的話，相應(yīng)的生成記數(shù)會增加。 JVM 會監(jiān)視垃圾收集的效率，如果是因為所有的對象都穩(wěn)定運(yùn)行而使得收集工作比較浪費(fèi)時間的話，垃圾收集會轉(zhuǎn)向 markandsweep 模式。 一項很重要的技術(shù)就涉及到那個加載程序的操作，它被稱為 justintime（ JIT）編譯器。一個替代方案就是 lazy evaluation，它的意思是直到代碼需要的時候，才用 JIT
畢業(yè)設(shè)計相關(guān)推薦
鄂ICP備17016276號-1