計(jì)算機(jī)科學(xué)與技術(shù)Java垃圾收集器中英文對照外文翻譯文獻(xiàn)

中英文資料中英文資料外文翻譯文獻(xiàn)原文：HowagarbagecollectorworksofJavaLanguageIfyoucomefromaprogramminglanguagewhereallocatingobjectsontheheapisexpensive,youmaynaturallyassumethatJava’sschemeofallocatingeverything(exceptprimitives)ontheheapisalsoexpensive.However,itturnsoutthatthegarbagecollectorcanhaveasignificantimpactonincreasingthespeedofobjectcreation.Thismightsoundabitoddatfirst—thatstoragereleaseaffectsstorageallocation—butit’sthewaysomeJVMswork,anditmeansthatallocatingstorageforheapobjectsinJavacanbenearlyasfastascreatingstorageonthestackinotherlanguages.Forexample,youcanthinkoftheC++heapasayardwhereeachstakesoutitsownpieceofturfobject.Thisrealestatecanbecomeabandonedsometimelaterandmustbereused.InsomeJVMs,theJavaheapisquitedifferent;it’smorelikeaconveyorbeltthatmovesforwardeverytimeyouallocateanewobject.Thismeansthatobjectstorageallocationisremarkablyrapid.The“heappointer”issimplymovedforwardintovirginterritory,soit’seffectivelythesameasC++’sstackallocation.(Ofcourse,there’salittleextraoverheadforbookkeeping,butit’snothinglikesearchingforstorage.)Youmightobservethattheheapisn’tinfactaconveyorbelt,andifyoutreatitthatway,you’llstartpagingmemory—movingitonandoffdisk,sothatyoucanappeartohavemorememorythanyouactuallydo.Pagingsignificantlyimpactsperformance.Eventually,afteryoucreateenoughobjects,you’llrunoutofmemory.Thetrickisthatthegarbagecollectorstepsin,andwhileitcollectsthegarbageitcompactsalltheobjectsintheheapsothatyou’veeffectivelymovedthe“heappointer”closertothebeginningoftheconveyorbeltandfartherawayfromapagefault.Thegarbagecollectorrearrangesthingsandmakesitpossibleforthehigh-speed,infinite-free-heapmodeltobeusedwhileallocatingstorage.TounderstandgarbagecollectioninJava,it’shelpfullearnhowgarbage-collectionschemesworkinothersystems.Asimplebutslowgarbage-collectiontechniqueiscalledreferencecounting.Thismeansthateachobjectcontainsareferencecounter,andeverytimeareferenceisattachedtothatobject,thereferencecountisincreased.Everytimeareferencegoesoutofscopeorissettonull,thereferencecountisdecreased.Thus,managingreferencecountsisasmallbutconstantoverheadthathappensthroughoutthelifetimeofyourprogram.Thegarbagecollectormovesthroughtheentirelistofobjects,andwhenitfindsonewithareferencecountofzeroitreleasesthatstorage(however,referencecountingschemesoftenreleaseanobjectassoonasthecountgoestozero).Theonedrawbackisthatifobjectscircularlyrefertoeachothertheycanhavenonzeroreferencecountswhilestillbeinggarbage.Locatingsuchself-referentialgroupsrequiressignificantextraworkforthegarbagecollector.Referencecountingiscommonlyusedtoexplainonekindofgarbagecollection,butitdoesn’tseemtobeusedinanyJVMimplementations.Infasterschemes,garbagecollectionisnotbasedonreferencecounting.Instead,itisbasedontheideathatanynon-deadobjectmustultimatelybetraceablebacktoareferencethatliveseitheronthestackorinstaticstorage.Thechainmightgothroughseverallayersofobjects.Thus,ifyoustartinthestackandinthestaticstorageareaandwalkthroughallthereferences,you’llfindalltheliveobjects.Foreachreferencethatyoufind,youmusttraceintotheobjectthatitpointstoandthenfollowallthereferencesinthatobject,tracingintotheobjectstheypointto,etc.,untilyou’vemovedthroughtheentireWebthatoriginatedwiththereferenceonthestackorinstaticstorage.Eachobjectthatyoumovethroughmuststillbealive.Notethatthereisnoproblemwithdetachedself-referentialgroups—thesearesimplynotfound,andarethereforeautomaticallygarbage.Intheapproachdescribedhere,theJVMusesanadaptivegarbage-collectionscheme,andwhatitdoeswiththeliveobjectsthatitlocatesdependsonthevariantcurrentlybeingused.Oneofthesevariantsisstop-and-copy.Thismeansthat—forreasonsthatwillbecomeapparent—theprogramisfirststopped(thisisnotabackgroundcollectionscheme).Then,eachliveobjectiscopiedfromoneheaptoanother,leavingbehindallthegarbage.Inaddition,astheobjectsarecopiedintothenewheap,theyarepackedend-to-end,thuscompactingthenewheap(andallowingnewstoragetosimplybereeledofftheendaspreviouslydescribed).Ofcourse,whenanobjectismovedfromoneplacetoanother,allreferencesthatpointattheobjectmustbechanged.Thereferencethatgoesfromtheheaporthestaticstorageareatotheobjectcanbechangedrightaway,buttherecanbeotherreferencespointingtothisobjectInitialization&Cleanupthatwillbeencounteredlaterduringthe“walk.”Thesearefixedupastheyarefound(youcouldimagineatablethatmapsoldaddressestonewones).Therearetwoissuesthatmaketheseso-called“copycollectors”inefficient.Thefirstistheideathatyouhavetwoheapsandyousloshallthememorybackandforthbetweenthesetwoseparateheaps,maintainingtwiceasmuchmemoryasyouactuallyneed.SomeJVMsdealwiththisbyallocatingtheheapinchunksasneededandsimplycopyingfromonechunktoanother.Thesecondissueisthecopyingprocessitself.Onceyourprogrambecomesstable,itmightbegeneratinglittleornogarbage.Despitethat,acopycollectorwillstillcopyallthememoryfromoneplacetoanother,whichiswasteful.Topreventthis,someJVMsdetectthatnonewgarbageisbeinggeneratedandswitchtoadifferentscheme(thisisthe“adaptive”part).Thisotherschemeiscalledmark-and-sweep,andit’swhatearlierversionsofSun’sJVMusedallthetime.Forgeneraluse,mark-and-sweepisfairlyslow,butwhenyouknowyou’regeneratinglittleornogarbage,it’sfast.Mark-and-sweepfollowsthesamelogicofstartingfromthestackandstaticstorage,andtracingthroughallthereferencestofindliveobjects.However,eachtimeitfindsaliveobject,thatobjectismarkedbysettingaflaginit,buttheobjectisn’tcollectedyet.Onlywhenthemarkingprocessisfinisheddoesthesweepoccur.Duringthesweep,thedeadobjectsarereleased.However,nocopyinghappens,soifthecollectorchoosestocompactafragmentedheap,itdoessobyshufflingobjectsaround.“Stop-and-copy”referstotheideathatthistypeofgarbagecollectionisnotdoneinthebackground;Instead,theprogramisstoppedwhilethegarbagecollectionoccurs.IntheSunliteratureyou’llfindmanyreferencestogarbagecollectionasalow-prioritybackgroundprocess,butitturnsoutthatthegarbagecollectionwasnotimplementedthatwayinearlierversionsoftheSunJVM.Instead,theSungarbagecollectorstoppedtheprogramwhenmemorygotlow.Mark-and-sweepalsorequiresthattheprogrambestopped.Aspreviouslymentioned,intheJVMdescribedherememoryisallocatedinbigblocks.Ifyouallocatealargeobject,itgetsitsownblock.Strictstop-and-copyrequirescopyingeveryliveobjectfromthesourceheaptoanewheapbeforeyoucanfreetheoldone,whichtranslatestolotsofmemory.Withblocks,thegarbagecollectioncantypicallycopyobjectstodeadblocksasitcollects.Eachblockhasagenerationcounttokeeptrackofwhetherit’salive.Inthenormalcase,onlytheblockscreatedsincethelastgarbagecollectionarecompacted;allotherblocksgettheirgenerationcountbumpediftheyhavebeenreferencedfromsomewhere.Thishandlesthenormalcaseoflotsofshort-livedtemporaryobjects.Periodically,afullsweepismade—largeobjectsarestillnotcopied(theyjustgettheirgenerationcountbumped),andblockscontainingsmallobjectsarecopiedandcompacted.TheJVMmonitorstheefficiencyofgarbagecollectionandifitbecomesawasteoftimebecauseallobjectsarelong-lived,thenitswitchestomark-andsweep.Similarly,theJVMkeepstrackofhowsuccessfulmark-and-sweepis,andiftheheapstartstobecomefragmented,itswitchesbacktostop-and-copy.Thisiswherethe“adaptive”partcomesin,soyouendupwithamouthful:“Adaptivegenerationalstop-and-copymark-andsweep.”ThereareanumberofadditionalspeedupspossibleinaJVM.Anespeciallyimportantoneinvolvestheoperationoftheloaderandwhatiscalledajust-in-time(JIT)compiler.AJITcompilerpartiallyorfullyconvertsaprogramintonativemachinecodesothatitdoesn’tneedtobeinterpretedbytheJVMandthusrunsmuchfaster.Whenaclassmustbeloaded(typically,thefirsttimeyouwanttocreateanobjectofthatclass),the.classfileislocated,andthebytecodesforthatclassarebroughtintomemory.Atthispoint,oneapproachistosimplyJITcompileallthecode,butthishastwodrawbacks:Ittakesalittlemoretime,which,compoundedthroughoutthelifeoftheprogram,canaddup;anditincreasesthesizeoftheexecutable(bytecodesaresignificantlymorecompactthanexpandedJITcode),andthismightcausepaging,whichdefinitelyslowsdownaprogram.Analternativeapproachislazyevaluation,whichmeansthatthecodeisnotJITcompileduntilnecessary.Thus,codethatnevergetsexecutedmightneverbeJITcompiled.TheJavaHotspottechnologiesinrecentJDKstakeasimilarapproachbyincreasinglyoptimizingapieceofcodeeachtimeitisexecuted,sothemorethecodeisexecuted,thefasteritgets.譯文：Java垃圾收集器的工作方式如果你學(xué)下過一種因?yàn)樵诙牙锓峙鋵ο笏蚤_銷過大的編程語言，很自然你可能會假定Java在堆里為每一樣?xùn)|西（除了primitives）分配內(nèi)存資源的機(jī)制開銷也會很大。不過，事實(shí)上垃圾收集器能夠深刻影響對象的加速創(chuàng)建。一開始聽起來有些奇怪——存貯空間的釋放會影響存貯空間的分配，但是這的確是一些JVMs的工作方式，并且這意味著Java為堆對象分配存貯空間幾乎和別的語言里為棧分配存貯空間一樣地快。舉個例子，你可以認(rèn)為C++的堆就如同一個堆放的工場，在這個工場里，每一個對象都立有的地皮占有權(quán)不久會被廢除無效，并且這塊地皮必須重新加以利用。在Java的JVM里，堆的工作方式完全不同；每次為一個新的對象分配存貯空間的時候，它就更像是一個不斷向前移動的傳送帶。這就意味著對象存貯空間的分配速度明顯加快。在這個過程中，“堆指針”簡單地向還沒被占用的空間領(lǐng)域移動，所以非常像C++里棧的分配方式。（當(dāng)然，記錄工作會有一點(diǎn)額外的開銷，但是完全不同于C++里那種在堆放工場里為尋找沒被利用的存貯空間而付出的開銷。）你或許觀察到實(shí)際上堆本身并不是一個傳送帶，如果你真的那樣看待堆，你就會啟用虛擬內(nèi)存——在硬盤里不斷地裝卸，結(jié)果是看上去你會擁有比實(shí)際情況還要多的內(nèi)存空間。最終，當(dāng)你創(chuàng)建了足夠多的對象后，你會耗盡內(nèi)存。Java的訣竅就在于垃圾搜集器插手于其中，當(dāng)垃圾收集器收集垃圾的時候，它會壓縮所有堆里的對象以便你能夠有效的將堆指針移動到相應(yīng)的地方從而遠(yuǎn)離了頁面錯誤。垃圾收集器重新安排了整個過程，這使得分配存貯空間的時候一種高速，無窮閑置的堆模式成為可能。要想理解Java的垃圾收集工作，先了解一下別的語言系統(tǒng)里垃圾收集所使用的方案是有幫助的。一種簡單的但卻較慢的垃圾收集技術(shù)就是引用記數(shù)（referencecounting）。這種技術(shù)意味著每個對象都含有一個引用計(jì)數(shù)器，每一次一個引用指向那個對象的時候，引用記數(shù)就增加1每一次對象引用離開作用域或者被設(shè)置為null的時候，引用記數(shù)就減1。因此，應(yīng)付對象被引用的數(shù)量在你的程序的整個生命周期里是一筆較小但卻一直持續(xù)的開銷。垃圾收集器歷遍整組對象，當(dāng)它發(fā)現(xiàn)一個引用記數(shù)為零的對象時就會釋放那個對象的存貯空間。（不過，只要記數(shù)為零，引用記數(shù)方案通常會立刻釋放對象）。這種方案的一個缺點(diǎn)是如果對象之間循環(huán)著互相引用，那么這些對象的引用記數(shù)可能為非零，而垃圾收集器依然把它們當(dāng)作垃圾收集。定位這種自我引用的對象組需要垃圾收集器付出大量額外的工作。引用記數(shù)通常被用來解釋一類垃圾收集的工作原理，但是它似乎沒被任何一種JVM所采納。有一種執(zhí)行更快的垃圾收集方案，這種方案中垃圾收集不是建立在引用記數(shù)的基礎(chǔ)上。相反，它的思想是任何沒死的對象最終一定會在棧和靜態(tài)存貯器里找到相應(yīng)存活的引用。這種鏈?zhǔn)降牟檎曳绞娇赡軞v遍幾個層次的對象組。因此，如果從棧和靜態(tài)存貯器里開始并歷遍整個引用組，你會找到所有存活的對象。對于你找到的每個單引用，你必須找到它所指向的對象，然后發(fā)覺那個對象的所有引用，接著找到那些引用所指向的所有對象，依次類推，直到你歷遍整個由棧和靜態(tài)存貯器里的引用所形成的網(wǎng)。每個你找到的對象必須還存活著。注意，這里不存在分離的自我引用的對象組——他們只是沒被查找到，因此被自動當(dāng)作垃圾。在上述提到的垃圾收集方案中，JVM使用了一種自適應(yīng)的垃圾收集方案，它對查找到的存活對象采取的措施依賴于它正在使用的方案變體。其中的一個變體就是stop-and-copy。它意味著——基于一些明顯的原因——程序首先停止運(yùn)行（這不是一種在后臺實(shí)施的垃圾收集方案）。然后，每一個活著的對象從一個堆里被拷貝到另一個堆里，同時被拷貝的活對象和死的對象被當(dāng)作垃圾遺棄。并且，當(dāng)對象被拷貝到新的堆里后，他們在那里被一個挨一個塞緊，因此實(shí)現(xiàn)了壓縮新堆的目的（而且如前所述，這種方式騰出了壓縮后多余出來的新的空間）。當(dāng)然，對象從一個地方移動到另一個地方的時候，所有指向?qū)ο蟮囊帽仨毾鄳?yīng)改變。指向堆或者靜態(tài)存貯器里某個被移動對象的引用可以立即得到改變，但是還存在其它后來“在走走”的時候才會碰到的指向該對象的引用。這些引用一旦發(fā)現(xiàn)就會被修改。（你可以想象存在一張映射舊新地址的表）。有兩個問題使這種所謂的“拷貝型收集器”缺乏效率。第一個問題就是你使用了兩個堆，為了維護(hù)兩倍于你實(shí)際所需要的內(nèi)存空間，你得在這兩個堆之間來回?cái)噭又麄€內(nèi)存空間。一些JVMs通過依據(jù)實(shí)際所需來為堆分配大塊內(nèi)存，然后很簡單地從一個塊拷貝對象到另一個。第二個問題是拷貝過程本身。一旦你地程序趨向于穩(wěn)定的時候，它可能生成很少或者幾乎不生成垃圾。然而stop-and-copy方案不管這些，拷貝型垃圾收集器依舊把活對象占用的空間從一個地方拷貝到另一個地方，這就形成了浪費(fèi)。為了阻止這種情況的發(fā)生，一些JVMs會探測沒有新垃圾產(chǎn)生的時機(jī)，并且會轉(zhuǎn)向?qū)嵤┝硗庖粋€完全不同的垃圾收集方案。這種不同的方案被稱為mark-and-sweep，并且它是Sun的早期JVM版本一直使用的方案。處理一般的垃圾收集工作，mark-and-sweep表現(xiàn)得相當(dāng)?shù)芈?，但是?dāng)你的程序生成很少或者不生成垃圾時，它又運(yùn)行得很快。Mark-and-sweep遵循著和stop-and-copy一樣的邏輯：從棧和靜態(tài)存貯器里出發(fā)，跟蹤所有的引用從而找到存活的對象。不過，每次它找到活對象的時候，那個對象被做以標(biāo)記，而且對象還不會被收集起來。只有在整個標(biāo)記過程完成后，清掃（sweep）工作才真正