java性能優(yōu)化常見的垃圾收集器有哪些

本文小編為大家詳細介紹“java性能優(yōu)化常見的垃圾收集器有哪些”，內(nèi)容詳細，步驟清晰，細節(jié)處理妥當，希望這篇“java性能優(yōu)化常見的垃圾收集器有哪些”文章能幫助大家解決疑惑，下面跟著小編的思路慢慢深入，一起來學習新知識吧。

常見的垃圾回收器和算法

相信大家可以通過我提供的另外兩個文章，學習到很多的垃圾回收器的相關(guān)知識。而我們真正需要關(guān)注，甚至可能使用到的垃圾收集器就是以下四種：

serial 串行垃圾收集器

如果是在client型的虛擬機或者在單核的服務(wù)器上，這種垃圾回收器將會成為默認的垃圾回收器。無論是Minor GC 還是 Full GC ，所有的應用線程都會暫停。在老年代當中使用的是Serial Old，同樣是單線程的老年代版本。

client型虛擬機，我們前面提到過編譯類型分為client和server，jvm會通過client編譯器（單線程）將代碼編譯成jvm識別的字節(jié)碼。

可以通過如下標志表示：

    -XX:+UseSerialGC

Parallel 多線程垃圾收集器

在server型虛擬機或多線程服務(wù)器上，jdk8默認使用的垃圾收集器類型。

無論是Minor GC還是Full GC都使用多線程的方式去回收垃圾，這兩種GC都會造成應用線程的暫停。但是它具有更多的吞吐量，是對于響應時間沒有過多要求情況下，最合適的垃圾回收器。

可以通過如下標志查看其狀態(tài)：

年輕代：

-XX:+UseParallelGC

老年代：

-XX:+UseParallelOldGC

CMS 收集器

其設(shè)計初衷是為了減少serial和parallel收集器，在回收時造成的長時間的系統(tǒng)卡頓。

它在發(fā)生Minor GC時同樣會暫停所有的應用線程，不同之處在于，年輕代使用的不是parallel或者serial，而是使用一款專門適用于CMS的年輕代收集器ParNew。

可以通過下面的標志查看：

-XX:+UseParNewGC

CMS在發(fā)生Full GC時不再暫停全部應用線程，使用多線程的方式，和應用線程同時運行，清理不在使用的對象。這事得CMS垃圾收集器的停頓時間得到大大的降低。與Parellel收集器相比，極其明顯。

缺點：

• CMS需要占用較多的CPU資源，確保在應用線程運行時，gc線程不斷地掃描堆空間。

• 不會對內(nèi)存進行壓縮整理，導致內(nèi)存碎片化。

如果沒有足夠的CPU資源，或者內(nèi)存碎片化達到極限，將會退化成serial收集器。

可以通過下面的標志查看：

-XX:+UseConcMarkSweepGC

G1 收集器

也可以稱作垃圾優(yōu)先收集器(garbage first)。

設(shè)計初衷是為了盡量減少處理超大堆（4gb）時發(fā)生的卡頓。G1仍然屬于分代收集器，但是不同之處是它是邏輯分代。G1將堆空間劃分成若干個區(qū)域（Region），新生代的垃圾收集依然采用暫停所有應用線程的方式，將存活對象拷貝到老年代或者Survivor空間。老年代也分成很多區(qū)域，G1收集器通過將對象從一個區(qū)域復制到另外一個區(qū)域，完成了清理工作。這樣就解決了CMS中的內(nèi)存碎片問題。

與CMS相同，G1也屬于concurrent收集器，在老年代發(fā)生Full GC時，由后臺線程完成回收工作，不需要暫停應用線程。

通過下面的標志查看：

-XX:+UseG1GC

其實上面的內(nèi)容都是簡單描述，真正的實現(xiàn)細節(jié)請看開篇提供的文章。

顯式垃圾收集

這里說的顯式的垃圾收集，其實指的是手動觸發(fā)的垃圾回收，如下所示：

System.gc;

這是一種可以認為控制，讓jvm發(fā)生強制gc的方式。無論什么時候，都是不建議使用這種方式進行垃圾回收。

當你使用這條指定，不論是何種垃圾收集器，哪怕是CMS或G1也會發(fā)生Full GC，同時停止全部的應用線程，會卡頓相當長的一段時間。

例外情況：

• 性能分析、測試

• 堆分析

在上述情況，調(diào)用System.gc將能更好的幫助我們分析當前應用存在的問題。

讀到這里，這篇“java性能優(yōu)化常見的垃圾收集器有哪些”文章已經(jīng)介紹完畢，想要掌握這篇文章的知識點還需要大家自己動手實踐使用過才能領(lǐng)會，如果想了解更多相關(guān)內(nèi)容的文章，歡迎關(guān)注億速云行業(yè)資訊頻道。