第27講java常見(jiàn)的垃圾收集器有哪些

SerialGCJVM--ParNewGC，很明顯是個(gè)GC實(shí)現(xiàn)，它實(shí)際是SerialGC的多線程版本，最常見(jiàn)的應(yīng)用場(chǎng)景是配合老年代的CMSGC工作，下面是對(duì)應(yīng)參數(shù)-XX:+UseConcMarkSweepGC-XX:+UseConcMarkSweepGC-CMS（ConcurrentMarkSweep）GC（Mark-Sweep）算法，設(shè)計(jì)目標(biāo)是盡量減少停頓時(shí)間，這一點(diǎn)對(duì)于Web等反應(yīng)時(shí)間敏感的應(yīng)用非常重要，一直到今天，仍然有很多系統(tǒng)使用CMSGC。但是，CMS采用的標(biāo)記-清除算法，存在著內(nèi)存碎片化問(wèn)題，所以在長(zhǎng)時(shí)間運(yùn)行等情況下發(fā)生fullGC，導(dǎo)致惡劣的停頓。另外，既然強(qiáng)調(diào)了并發(fā)（Concurrent），CMS會(huì)占用CPU資源，并和用戶線程爭(zhēng)搶。ParrallelGC，在早期JDK8等版本中，它是server模式JVM的默認(rèn)GC選擇，也被稱作代和老年代GC都是并行進(jìn)行的，在常見(jiàn)的服務(wù)器環(huán)境中更加高效。--JVM---XX:GCTimeRatio=NGC時(shí)間和用戶時(shí)間比例=1/G1GC這是一種兼顧吞吐量和停頓時(shí)間的GC實(shí)現(xiàn)，是OracleJDK9以后的默認(rèn)GC選項(xiàng)。G1CMSGC，G1CMSG1GC一個(gè)個(gè)region。Region之間是算法，但整體上實(shí)際可看作是標(biāo)記-整理（Mark-Compact）Java，G1被標(biāo)記為廢棄（deprecated），所以G1GC值得你深入掌握。今天的問(wèn)題是你對(duì)GC的了解，GC是Java程序員的面試常見(jiàn)題目，但是并不是每個(gè)人都等信息，例如類型不再使用，卸載該Java類似乎是很合理的。果計(jì)數(shù)為0，即表示對(duì)象可回收。這是很多語(yǔ)言的資源回收選擇，例如因人工智能而更加火進(jìn)一步復(fù)雜化，具體請(qǐng)參考專欄第4講，這種類型的收集通常叫作追蹤性收集（TracingGarbageCollection）。其原理簡(jiǎn)單來(lái)說(shuō)，就是將對(duì)象及其關(guān)系看作一個(gè)圖，選定活動(dòng)的對(duì)象作為GCRoots，然后鏈條，如果一個(gè)對(duì)象和GCRoots之間法棧中正在的對(duì)象、靜態(tài)屬性的對(duì)象和常量，作為GCRoots。oad）的；而普通的類型的卸載，往往是要求相應(yīng)自定義類加載器本身被回收，所以大量使用動(dòng)態(tài)類型的場(chǎng)合，需要防止元數(shù)據(jù)區(qū)（期的永久代）不會(huì)OO0JDK--（Copying）算法，我前面講到的GC，基本都是基于算法，過(guò)程就如專欄上一講所介紹的，將活著的對(duì)象到to區(qū)域，拷貝過(guò)程中將對(duì)象順序放置，就可以避免內(nèi)存這種分拆成為大量region的GC，而不是移動(dòng)，意味著GC需要region之間對(duì)象（Mark-Sweep）算法，首先進(jìn)行標(biāo)記工作，標(biāo)識(shí)出所有要回收的對(duì)象，然后進(jìn)導(dǎo)致其不適合特別大的堆；否則，一旦出現(xiàn)FullGC，暫停時(shí)間可能根本無(wú)法接受。標(biāo)記-整理（ 內(nèi)容并不是圍繞Java收集，但是對(duì)通用算法講解比較形象。Survivor、Tenured等區(qū)域會(huì)發(fā)生什么變化呢？第一，Java應(yīng)用不斷創(chuàng)建對(duì)象，通常都是分配在Eden區(qū)域，當(dāng)其空間占用達(dá)到一定閾值時(shí)，觸發(fā)minorGC。仍然被的對(duì)象（綠色方塊）存，被到JVM選擇的Survivor區(qū)域，而沒(méi)有被的對(duì)象（黃色方塊）則被回收。注意，我給存活對(duì)象標(biāo)記了“數(shù)字1”，這是第二，經(jīng)過(guò)一次MinorGC，Eden就會(huì)空閑下來(lái)，直到再次達(dá)到MinorGC觸發(fā)條件，這時(shí)Survivorto，EdenFrom被到to區(qū)域，并且存活的計(jì)數(shù)會(huì)被加1。第三，類似第二步的過(guò)程會(huì)發(fā)生很多次，直到有對(duì)象計(jì)數(shù)達(dá)到閾值，這時(shí)候就會(huì)發(fā)生所謂--理算法過(guò)程示意圖，老年代中的無(wú)用對(duì)象被清除后，GC會(huì)將對(duì)象進(jìn)行整理，以防止內(nèi)存碎片通常我們把老年代GC叫作MajorGC，將對(duì)整個(gè)堆進(jìn)行的清理叫作FullGC，但是這個(gè)也沒(méi)有GCCMS，“concurrent”就體現(xiàn)GCGC仍然處于飛速發(fā)展之中，目前的默認(rèn)選項(xiàng)G1GC在不斷的進(jìn)行改進(jìn)，很多我們?cè)瓉?lái)認(rèn)為的FullGC、CardTableJDK10后，F(xiàn)ullGC已經(jīng)是并行運(yùn)行，在很多場(chǎng)景下，其表現(xiàn)還略優(yōu)于ParallelGC的并行FullGC實(shí)即使是SerialGC，雖然比較古老，但是簡(jiǎn)單的設(shè)計(jì)未必就是過(guò)時(shí)的，它本身的開(kāi)銷，不管是GC相關(guān)數(shù)據(jù)結(jié)構(gòu)的開(kāi)銷，還是線程的開(kāi)銷，都是非常小的，所以隨著云計(jì)算的興起，在Serverless等新的應(yīng)用場(chǎng)景下，SerialGC找到了新的舞臺(tái)。CMSGC，因?yàn)槠渌惴ǖ睦碚撊毕莸仍颍m然現(xiàn)在還有非常大的用戶群體，但是已經(jīng)被標(biāo)記為廢棄，如果沒(méi)有組織主動(dòng)承擔(dān)CMS的，很有可能會(huì)在未來(lái)版本移除。JDK11，你會(huì)發(fā)現(xiàn)，JDKGCEpsilonGC，簡(jiǎn)單說(shuō)就是個(gè)不做收集的GC，似乎有點(diǎn)奇怪，有的情況下，例如在進(jìn)行ZGC，這是Oracle開(kāi)源出來(lái)的一個(gè)超級(jí)GC實(shí)現(xiàn)，具備令人驚訝的擴(kuò)展能力，比如支持Tbytes10ms。雖然目前還處于實(shí)驗(yàn)階段，僅支持Linux64位的平臺(tái)，但其已經(jīng)表現(xiàn)出的能力和潛力都非常令人期待。GCGC你通常使用什么參數(shù)去打開(kāi)GC日志呢？還會(huì)額外添加哪些選項(xiàng)？ 精選留公號(hào)-Java大后 JVM提供的收集器較多，特征不一，適用于不同的業(yè)務(wù)場(chǎng)景era收集器：串行；作于；算法應(yīng)速度；適用CP環(huán)境的模式。PaNew集器：運(yùn)行；于；算響應(yīng)速先；多P環(huán)境err模式下與 模式。 1于記+優(yōu)一 張南 JK8BCS1作者回沒(méi)有絕對(duì)，我建議綜合考慮 理論上比ms更容調(diào)，但熟悉哪實(shí)際用許如g還有基礎(chǔ)配置，如堆大小，比較大，比如16g以上，建議優(yōu)先 直接分配到老年代的對(duì)象在年輕代有空間了會(huì)移動(dòng)回來(lái)陳華 老師，Oracle的jvm的CMSGC，本身能夠解決內(nèi)存碎片化的問(wèn)題作者回我理解是目前實(shí)現(xiàn)不能完全避免，cms又不再發(fā)展雪 ZGC如此強(qiáng)大，非常期咨詢大師，Java未來(lái)有沒(méi)有計(jì)劃讓手動(dòng)內(nèi)存回收輔助自動(dòng)內(nèi)存回收以提高回收效率？既默認(rèn)情況下自動(dòng)內(nèi)存回收完全沒(méi)問(wèn)題，但在極致情況下允極客開(kāi)發(fā)者介入甚至完全接管內(nèi)存回收過(guò)程（和C+）作者回現(xiàn)在有一些影響gc，或者用直接內(nèi)存再顯式釋放，更近一步我不知道 老師，一下，rvvo滿而且or的么o作者回三木 用過(guò)- etails，打印比較詳作者回這個(gè)jdk9已經(jīng)deprecated了 老師，pyton支持那里好像有