畢業(yè)設(shè)計(jì)外文文獻(xiàn)翻譯---java垃圾收集器的工作方式

1、<p><b>　　畢業(yè)設(shè)計(jì)(論文)</b></p><p><b>　　外文文獻(xiàn)翻譯</b></p><p><b>　　信息工程學(xué)院</b></p><p><b>　　英文原文</b></p><p>　　How a garbage col

2、lector works of Java Language</p><p>　　If you come from a programming language where allocating objects on the heap is expensive, you may naturally assume that Java’s scheme of allocating everything (except

3、primitives) on the heap is also expensive. However, it turns out that the garbage collector can have a significant impact on increasing the speed of object creation. This might sound a bit odd at first—that storage relea

4、se affects storage allocation—but it’s the way some JVMs work, and it means that allocating storage for heap obj</p><p>　　For example, you can think of the C++ heap as a yard where each stakes out its own pi

5、ece of turf object. This real estate can become abandoned sometime later and must be reused. In some JVMs, the Java heap is quite different; it’s more like a conveyor belt that moves forward every time you allocate a new

6、 object. This means that object storage allocation is remarkably rapid. The “heap pointer” is simply moved forward into virgin territory, so it’s effectively the same as C++’s stack allocation. (</p><p>　　Yo

7、u might observe that the heap isn’t in fact a conveyor belt, and if you treat it that way, you’ll start paging memory—moving it on and off disk, so that you can appear to have more memory than you actually do. Paging sig

8、nificantly impacts performance. Eventually, after you create enough objects, you’ll run out of memory. The trick is that the garbage collector steps in, and while it collects the garbage it compacts all the objects in th

9、e heap so that you’ve effectively moved the “heap pointer”</p><p>　　To understand garbage collection in Java, it’s helpful learn how garbage-collection schemes work in other systems. A simple but slow garbag

10、e-collection technique is called reference counting. This means that each object contains a reference counter, and every time a reference is attached to that object, the reference count is increased. Every time a referen

11、ce goes out of scope or is set to null, the reference count is decreased. Thus, managing reference counts is a small but constant overhead th</p><p>　　In faster schemes, garbage collection is not based on re

12、ference counting. Instead, it is based on the idea that any non-dead object must ultimately be traceable back to a reference that lives either on the stack or in static storage. The chain might go through several layers

13、of objects. Thus, if you start in the stack and in the static storage area and walk through all the references, you’ll find all the live objects. For each reference that you find, you must trace into the object that it p

14、oint</p><p>　　In the approach described here, the JVM uses an adaptive garbage-collection scheme, and what it does with the live objects that it locates depends on the variant currently being used. One of th

15、ese variants is stop-and-copy. This means that—for reasons that will become apparent—the program is first stopped (this is not a background collection scheme). Then, each live object is copied from one heap to another, l

16、eaving behind all the garbage. In addition, as the objects are copied into the new heap</p><p>　　Of course, when an object is moved from one place to another, all references that point at the object must be

17、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 & Cleanup that will be encou

18、ntered later during the “walk.” These are fixed up as they are found (you could imagine a table that maps old addresses to new ones).</p><p>　　There are two issues that make these so-called “copy collectors”

19、 inefficient. The first is the idea that you have two heaps and you slosh all the memory back and forth between these two separate heaps, maintaining twice as much memory as you actually need. Some JVMs deal with this by

20、 allocating the heap in chunks as needed and simply copying from one chunk to another.</p><p>　　The second issue is the copying process itself. Once your program becomes stable, it might be generating little

21、 or no garbage. Despite that, a copy collector will still copy all the memory from one place to another, which is wasteful. To prevent this, some JVMs detect that no new garbage is being generated and switch to a differe

22、nt scheme (this is the “adaptive” part). This other scheme is called mark-and-sweep, and it’s what earlier versions of Sun’s JVM used all the time. For general use, mark</p><p>　　However, each time it finds

23、a live object, that object is marked by setting a flag in it, but the object isn’t collected yet. Only when the marking process is finished does the sweep occur. During the sweep, the dead objects are released. However,

24、no copying happens, so if the collector chooses to compact a fragmented heap, it does so by shuffling objects around. “Stop-and-copy” refers to the idea that this type of garbage collection is not done in the background;

25、 Instead, the program is stopped</p><p>　　As previously mentioned, in the JVM described here memory is allocated in big blocks. If you allocate a large object, it gets its own block. Strict stop-and-copy req

26、uires copying every live object from the source heap to a new heap before you can free the old one, which translates to lots of memory. With blocks, the garbage collection can typically copy objects to dead blocks as it

27、collects. Each block has a generation count to keep track of whether it’s alive. In the normal case, only the block</p><p>　　The JVM monitors the efficiency of garbage collection and if it becomes a waste of

28、 time because all objects are long-lived, then it switches to mark-and sweep. Similarly, the JVM keeps track of how successful mark-and-sweep is, and if the heap starts to become fragmented, it switches back to stop-and-

29、copy. This is where the “adaptive” part comes in, so you end up with a mouthful: “Adaptive generational stop-and-copy mark-and sweep.”</p><p>　　There are a number of additional speedups possible in a JVM. An

30、 especially important one involves the operation of the loader and what is called a just-in-time (JIT) compiler. A JIT compiler partially or fully converts a program into native machine code so that it doesn’t need to be

31、 interpreted by the JVM and thus runs much faster. When a class must be loaded (typically, the first time you want to create an object of that class), the .class file is located, and the byte codes for that class are <

32、;/p><p><b>　　中文譯文</b></p><p>　　Java垃圾收集器的工作方式 </p><p>　　如果你學(xué)下過一種因?yàn)樵诙牙锓峙鋵?duì)象所以開銷過大的編程語言，很自然你可能會(huì)假定 Java 在堆里為每一樣?xùn)|西（除了 primitives）分配內(nèi)存資源的機(jī)制開銷也會(huì)很大。不過，事實(shí)上垃圾收集器能夠深刻影響對(duì)象的加速創(chuàng)建。 一開始聽起來

33、有些奇怪——存貯空間的釋放會(huì)影響存貯空間的分配，但是這的確是一些 JVMs 的工作方式，并且這意味著 Java 為堆對(duì)象分配存貯空間幾乎和別的語言里為棧分配存貯空間一樣地快。</p><p>　　舉個(gè)例子，你可以認(rèn)為 C++的堆就如同一個(gè)堆放的工場(chǎng)，在這個(gè)工場(chǎng)里，每一個(gè)對(duì)象都立有的地皮占有權(quán)不久會(huì)被廢除無效，并且這塊地皮必須重新加以利用。在Java 的 JVM 里，堆的工作方式完全不同；每次為一個(gè)新的對(duì)象分配存貯

34、空間的時(shí)候，它就更像是一個(gè)不斷向前移動(dòng)的傳送帶。 這就意味著對(duì)象存貯空間的分配速度明顯加快。 在這個(gè)過程中，“堆指針”簡(jiǎn)單地向還沒被占用的空間領(lǐng)域移動(dòng)，所以非常像 C++里棧的分配方式。（當(dāng)然，記錄工作會(huì)有一點(diǎn)額外的開銷，但是完全不同于 C++里那種在堆放工場(chǎng)里為尋找沒被利用的存貯空間而付出的開銷。）</p><p>　　你或許觀察到實(shí)際上堆本身并不是一個(gè)傳送帶，如果你真的那樣看待堆，你就會(huì)啟用虛擬內(nèi)存——在硬盤

35、里不斷地裝卸，結(jié)果是看上去你會(huì)擁有比實(shí)際情況還要多的內(nèi)存空間。 最終，當(dāng)你創(chuàng)建了足夠多的對(duì)象后，你會(huì)耗盡內(nèi)存。 Java 的訣竅就在于垃圾搜集器插手于其中，當(dāng)垃圾收集器收集垃圾的時(shí)候，它會(huì)壓縮所有堆里的對(duì)象以便你能夠有效的將堆指針移動(dòng)到相應(yīng)的地方從而遠(yuǎn)離了頁面錯(cuò)誤。垃圾收集器重新安排了整個(gè)過程，這使得分配存貯空間的時(shí)候一種高速，無窮閑置的堆模式成為可能。</p><p>　　要想理解 Java 的垃圾收集工作，先

36、了解一下別的語言系統(tǒng)里垃圾收集所使用的方案是有幫助的。 一種簡(jiǎn)單的但卻較慢的垃圾收集技術(shù)就是引用記數(shù)（reference counting）。這種技術(shù)意味著每個(gè)對(duì)象都含有一個(gè)引用計(jì)數(shù)器，每一次一個(gè)引用指向那個(gè)對(duì)象的時(shí)候，引用記數(shù)就增加1 每一次對(duì)象引用離開作用域或者被設(shè)置為 null 的時(shí)候，引用記數(shù)就減1。 因此，應(yīng)付對(duì)象被引用的數(shù)量在你的程序的整個(gè)生命周期里是一筆較小但卻一直持續(xù)的開銷。垃圾收集器歷遍整組對(duì)象，當(dāng)它發(fā)現(xiàn)一個(gè)引用記數(shù)為

37、零的對(duì)象時(shí)就會(huì)釋放那個(gè)對(duì)象的存貯空間。（不過，只要記數(shù)為零，引用記數(shù)方案通常會(huì)立刻釋放對(duì)象）。 這種方案的一個(gè)缺點(diǎn)是如果對(duì)象之間循環(huán)著互相引用，那么這些對(duì)象的引用記數(shù)可能為非零，而垃圾收集器依然把它們當(dāng)作垃圾收集。 定位這種自我引用的對(duì)象組需要垃圾收集器付出大量額外的工作。引用記數(shù)通常被用來解釋一類垃圾收集的工作原理，但是它似乎沒被任何一種 JVM 所采納。有一種執(zhí)行更快的垃圾收集方案，這種方案中垃圾收集不是建立在引用記數(shù)的基礎(chǔ)上。&l

38、t;/p><p>　　相反，它的思想是任何沒死的對(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ì)象必須還存活著。

39、注意，這里不存在分離的自我引用的對(duì)象組——他們只是沒被查找到，因此被自動(dòng)當(dāng)作垃圾。</p><p>　　在上述提到的垃圾收集方案中，JVM 使用了一種自適應(yīng)的垃圾收集方案，它對(duì)查找到的存活對(duì)象采取的措施依賴于它正在使用的方案變體。其中的一個(gè)變體就是 stop-and-copy。 它意味著——基于一些明顯的原因——程序首先停止運(yùn)行（這不是一種在后臺(tái)實(shí)施的垃圾收集方案）。然后，每一個(gè)活著的對(duì)象從一個(gè)堆里被拷貝到另一個(gè)

40、堆里，同時(shí)被拷貝的活對(duì)象和死的對(duì)象被當(dāng)作垃圾遺棄。并且，當(dāng)對(duì)象被拷貝到新的堆里后，他們?cè)谀抢锉灰粋€(gè)挨一個(gè)塞緊，因此實(shí)現(xiàn)了壓縮新堆的目的（而且如前所述，這種方式騰出了壓縮后多余出來的新的空間）。當(dāng)然，對(duì)象從一個(gè)地方移動(dòng)到另一個(gè)地方的時(shí)候，所有指向?qū)ο蟮囊帽仨毾鄳?yīng)改變。 指向堆或者靜態(tài)存貯器里某個(gè)被移動(dòng)對(duì)象的引用可以立即得到改變，但是還存在其它后來“在走走”的時(shí)候才會(huì)碰到的指向該對(duì)象的引用。 這些引用一旦發(fā)現(xiàn)就會(huì)被修改。（你可以想象存在一

41、張映射舊新地址的表）。</p><p>　　有兩個(gè)問題使這種所謂的“拷貝型收集器”缺乏效率。 第一個(gè)問題就是你使用了兩個(gè)堆，為了維護(hù)兩倍于你實(shí)際所需要的內(nèi)存空間，你得在這兩個(gè)堆之間來回?cái)噭?dòng)著整個(gè)內(nèi)存空間。 一些 JVMs 通過依據(jù)實(shí)際所需來為堆分配大塊內(nèi)存，然后很簡(jiǎn)單地從一個(gè)塊拷貝對(duì)象到另一個(gè)。第二個(gè)問題是拷貝過程本身。 一旦你地程序趨向于穩(wěn)定的時(shí)候，它可能生成很少或者幾乎不生成垃圾。 然而 stop-and-c

42、opy 方案不管這些，拷貝型垃圾收集器依舊把活對(duì)象占用的空間從一個(gè)地方拷貝到另一個(gè)地方，這就形成了浪費(fèi)。 為了阻止這種情況的發(fā)生，一些 JVMs會(huì)探測(cè)沒有新垃圾產(chǎn)生的時(shí)機(jī)，并且會(huì)轉(zhuǎn)向?qū)嵤┝硗庖粋€(gè)完全不同的垃圾收集方案。 這種不同的方案被稱為 mark-and-sweep，并且它是 Sun 的早期 JVM 版本一直使用的方案。 處理一般的垃圾收集工作，mark-and-sweep 表現(xiàn)得相當(dāng)?shù)芈钱?dāng)你的程序生成很少或者不生成垃圾時(shí)，它

43、又運(yùn)行得很快。</p><p>　　Mark-and-sweep 遵循著和 stop-and-copy 一樣的邏輯：從棧和靜態(tài)存貯器里出發(fā)，跟蹤所有的引用從而找到存活的對(duì)象。 不過，每次它找到活對(duì)象的時(shí)候，那個(gè)對(duì)象被做以標(biāo)記，而且對(duì)象還不會(huì)被收集起來。 只有在整個(gè)標(biāo)記過程完成后，清掃（sweep）工作才真正開始。在清掃過程中，死對(duì)象被釋放存貯空間。不過，Mark-and-sweep 方案的實(shí)施過程并沒有拷貝壓縮的

44、步驟發(fā)生，所以如果垃圾收集器打算壓縮已經(jīng)成為碎片的堆，它會(huì)采用如同洗牌一樣的方式來重新安排對(duì)象的散亂分布。stop-and-copy 的思想是垃圾收集不在后臺(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)行。 Mark-and

45、-sweep 也需要程序被終止。</p><p>　　正如前面提到的，在這里描述的 JVM 里，內(nèi)存被分配成大的塊。 如果你指定了一個(gè)大的對(duì)象，它將會(huì)得到它自己的內(nèi)存塊。 嚴(yán)格意義上的 stop-and-copy 在可以釋放舊堆之前，需要從源堆里拷貝每一個(gè)活著的對(duì)象到新的堆里，這會(huì)耗費(fèi)大量?jī)?nèi)存。 而有了塊的概念，垃圾收集器在收集的時(shí)候就能夠拷貝對(duì)象到死的塊里。每一個(gè)塊都有一個(gè)生成數(shù)用來跟蹤它是否還活著。正常情況下

46、，只有自上次垃圾收集后創(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)向 mark-and-sweep 模式。</p>&l

47、t;p>　　同樣地，JVM 也會(huì)跟蹤 mark-and-sweep 的運(yùn)行效果，如果堆開始變得零碎不堪，垃收集又會(huì)轉(zhuǎn)回 stop-and-copy 模式。 這就是“自適應(yīng)”概念的來源，所以你能總結(jié)出一句冗長(zhǎng)拗口的話： “自適應(yīng)地分階段地 stop-and-copy mark-and-sweep?！盝VM 里，可能會(huì)有一些附帶的加速技術(shù)。 一項(xiàng)很重要的技術(shù)就涉及到那個(gè)加載程序的操作，它被稱為 just-in-time（JIT）編譯器

48、。 JIT 編譯器能部分或者全部把程序轉(zhuǎn)換成機(jī)器能夠識(shí)別的代碼，所以程序就不需要 JVM 的解釋了，結(jié)果是程序運(yùn)行起來快很多。當(dāng)必須加載類的時(shí)候（特別是你第一次想創(chuàng)建那個(gè)類的對(duì)象的時(shí)候），首先定位 .class 文件，然后相應(yīng)的字節(jié)碼被送入內(nèi)存。 這個(gè)時(shí)候，一個(gè)可以利用的方式就是直接讓 JIT 編譯所有的代碼，但是這樣做有兩個(gè)缺點(diǎn)： 這種方式的應(yīng)用由于混雜在程序的整個(gè)生命周期里，所以能累加起來，從而導(dǎo)致程序執(zhí)行起來會(huì)花費(fèi)一些額外的時(shí)間；