現(xiàn)在已經(jīng)是2014年了，但是對(duì)大多數(shù)開(kāi)發(fā)人員而言有兩件事情仍然是個(gè)謎——java垃圾回收以及異性(碼農(nóng)又被嘲笑了)。由于我對(duì)后者也不是特別了解，我想我還是試著說(shuō)說(shuō)前者吧，尤其是隨著Java8的到來(lái)，這個(gè)領(lǐng)域也發(fā)生了許多重大的變化及提升，其中最重要的莫過(guò)于持久代(PermGen)的刪除以及一些令人振奮的新的優(yōu)化(后面會(huì)陸續(xù)提及這些)。

說(shuō)起垃圾回收，許多人都了解它的概念，也在日常的編程中有所應(yīng)用。盡管如此，仍有許多我們不太了解的東西，而這正是痛苦的根源。關(guān)于JVM最大的誤解就是認(rèn)為它只有一個(gè)垃圾回收器，而事實(shí)上它有四個(gè)不同的回收器，每個(gè)都各有其長(zhǎng)短。JVM并不會(huì)自動(dòng)地選擇某一個(gè)，這事還得落在你我的肩上，因?yàn)椴煌幕厥掌鲿?huì)帶來(lái)吞吐量及應(yīng)用的暫停時(shí)間的顯著的差異。

這四種回收算法的共同之處在于它們都是分代的，也就是說(shuō)它們將托管的堆分成了好幾個(gè)區(qū)域，它假設(shè)堆中的許多對(duì)象的生命周期都很短，可以很快被回收掉。介紹這塊內(nèi)容的已經(jīng)很多了，因此這里我打算直接講一下這幾個(gè)不同的算法，以及它們的長(zhǎng)處及短處。1.串行回收器

串行回收器是最簡(jiǎn)單的一個(gè)，你都不會(huì)考慮使用它，因?yàn)樗饕敲嫦騿尉€程環(huán)境的(比如說(shuō)32位的或者Windows)以及比較小的堆。這個(gè)回收器工作的時(shí)候會(huì)將所有應(yīng)用線程全部?jī)鼋Y(jié)，就這一點(diǎn)而言就使得它完全不可能會(huì)被服務(wù)端應(yīng)用所采用。

如何使用它：你可以打開(kāi)-XX:+UseSerialGC這個(gè)JVM參數(shù)來(lái)使用它。2.并行/吞吐量回收器

下一個(gè)是并行回收器( Parallel collector)。這是JVM的默認(rèn)回收器。正如它的名字所說(shuō)的那樣，它的最大的優(yōu)點(diǎn)就是它使用多個(gè)線程來(lái)掃描及壓縮堆。它的缺點(diǎn)就是不管執(zhí)行的是minor GC還是full GC它都會(huì)暫停應(yīng)用線程。并行回收器最適合那些可以容許暫停的應(yīng)用，它試圖減少由回收器所引起的CPU開(kāi)銷(xiāo)。3.CMS回收器

并行回收器之后就是CMS回收器了(concurrent-mark-sweep)。這個(gè)算法使用了多個(gè)線程(concurrent)來(lái)掃描堆并標(biāo)記(mark)那些不再使用的可以回收(sweep)的對(duì)象。這個(gè)算法在兩種情況下會(huì)進(jìn)入一個(gè)”stop the world”的模式：當(dāng)進(jìn)行根對(duì)象的初始標(biāo)記的時(shí)候 (老生代中線程入口點(diǎn)或靜態(tài)變量可達(dá)的那些對(duì)象)以及當(dāng)這個(gè)算法在并發(fā)運(yùn)行的時(shí)候應(yīng)用程序改變了堆的狀態(tài)使得它不得不回去再次確認(rèn)自己標(biāo)記的對(duì)象都是正確的。

使用這個(gè)回收器最大的問(wèn)題就是會(huì)碰到promotion failure，這是指在回收新生代及年老代時(shí)出現(xiàn)了競(jìng)爭(zhēng)條件的情況。如果回收器需要將年輕的對(duì)象提升到年老代中，而這個(gè)時(shí)候年老代沒(méi)有多余的空間了，它就只能先進(jìn)行一次STW(Stop The World)的full GC了——這種情況正是CMS所希望避免的。為了確保這種情況不會(huì)發(fā)生，你要么就是增加老生代的大小(或者增加整個(gè)堆的大小)，要么就是給回收器分配一些后臺(tái)線程以便與對(duì)象分配的速度進(jìn)行賽跑。

這個(gè)算法的另一個(gè)缺點(diǎn)就是和并行回收器相比，它使用的CPU資源會(huì)更多，它使用了多個(gè)線程來(lái)執(zhí)行掃描和回收，這樣才能讓?xiě)?yīng)用持續(xù)提供更高級(jí)別的吞吐量。對(duì)于大多數(shù)長(zhǎng)期運(yùn)行的程序而言，應(yīng)用的暫停對(duì)它們是很不利的，這個(gè)時(shí)候可以考慮使用CMS回收器。盡管如此，這個(gè)算法也不是默認(rèn)開(kāi)啟的。你得指定XX:+UseConcMarkSweepGC來(lái)啟用它。假設(shè)你的堆小于4G，而你又希望分配更多的CPU資源以避免應(yīng)用暫停，那么這就是你要選擇的回收器。然而，如果堆大于4G的話，你可能更希望使用最后的這個(gè)——G1回收器。4.G1回收器

G1( Garbage first)回收器在JDK 7update 4中首次引入，它的設(shè)計(jì)目標(biāo)是能更好地支持大于4GB的堆。G1回收器將堆分為多個(gè)區(qū)域，大小從1MB到32MB不等，并使用多個(gè)后臺(tái)線程來(lái)掃描它們。G1回收器會(huì)優(yōu)先掃描那些包含垃圾最多的區(qū)域，這正是它的名字的由來(lái)(Garbage first)。這個(gè)回收器可以通過(guò)-XX:UseG1GC標(biāo)記來(lái)啟用。

這一策略減少了后臺(tái)線程還未掃描完無(wú)用對(duì)象前堆就已經(jīng)用光的可能性，而那種情況回收器就必須得暫停應(yīng)用，這就會(huì)導(dǎo)致STW回收。G1的另一個(gè)好處就是它總是會(huì)進(jìn)行堆的壓縮，而CMS回收器只有在full GC的時(shí)候才會(huì)干這事。

過(guò)去幾年里，大堆一直都是一個(gè)充滿爭(zhēng)議的領(lǐng)域，很多開(kāi)發(fā)人員從單機(jī)器單JVM模型轉(zhuǎn)向了單機(jī)器多JVM的微服務(wù)，組件化的架構(gòu)。這是許多因素所驅(qū)動(dòng)的，包括隔離程序的組件，簡(jiǎn)化部署，避免重新加載應(yīng)用類(lèi)到內(nèi)存所產(chǎn)生的開(kāi)銷(xiāo)(Java 8中這點(diǎn)已經(jīng)得到了改善)。

盡管如此，這么做最主要還是希望能避免大堆的GC中長(zhǎng)時(shí)期的”stop the world”的暫停(在一次大的回收中需要花費(fèi)數(shù)秒才能完成)。像Docker這樣的容器技術(shù)也加速了這一進(jìn)程，它們使得你可以很輕松地在同一臺(tái)物理機(jī)上部署多個(gè)應(yīng)用。Java 8及G1回收器

Java 8 update 20所引入的一個(gè)很棒的優(yōu)化就是G1回收器中的字符串去重(String deduplication)。由于字符串(包括它們內(nèi)部的char[]數(shù)組)占用了大多數(shù)的堆空間，這項(xiàng)新的優(yōu)化旨在使得G1回收器能識(shí)別出堆中那些重復(fù)出現(xiàn)的字符串并將它們指向同一個(gè)內(nèi)部的char[]數(shù)組，以避免同一個(gè)字符串的多份拷貝，那樣堆的使用效率會(huì)變得很低。你可以使用-XX:+UseStringDeduplication這個(gè)JVM參數(shù)來(lái)試一下這個(gè)特性。Java 8及持久代

Java 8中最大的改變就是持久代的移除，它原本是用來(lái)給類(lèi)元數(shù)據(jù)，駐留字符串，靜態(tài)變量來(lái)分配空間的。這在以前都是需要開(kāi)發(fā)人員來(lái)針對(duì)那些會(huì)加載大量類(lèi)的應(yīng)用來(lái)專(zhuān)門(mén)進(jìn)行堆比例的優(yōu)化及調(diào)整。許多年來(lái)都是如此，這也正是許多OutOfMemory異常的根源，因此由JVM來(lái)接管它真是再好不過(guò)了。即便如此，它本身并不會(huì)減少開(kāi)發(fā)人員將應(yīng)用解耦到不同的JVM中的可能性。

每個(gè)回收器都有許多不同的開(kāi)關(guān)和選項(xiàng)來(lái)進(jìn)行調(diào)優(yōu)，這可能會(huì)增加吞吐量，也可能會(huì)減少，這取決于你的應(yīng)用的具體的行為了。在下一篇文章中我們會(huì)深入講解配置這些算法的關(guān)鍵策略。

總結(jié)

以上是生活随笔為你收集整理的java8 垃圾 不同_【不同的Java垃圾回收器的比较】的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。