垃圾收集算法,垃圾收集器

我們的研究實(shí)驗(yàn)室正全速前進(jìn)。 隨著最近的資本注入 ，我們只能保證我們不斷創(chuàng)新的步伐只會(huì)加快。 我們進(jìn)行的部分研究與GC優(yōu)化有關(guān)。 在處理這個(gè)有趣的領(lǐng)域中的問(wèn)題時(shí)，我們認(rèn)為可以分享一些有關(guān)GC算法使用的見(jiàn)解。

為此，我們對(duì)使用特定GC算法的頻率進(jìn)行了研究。 結(jié)果有些令人驚訝。 讓我從數(shù)據(jù)的背景開(kāi)始–我們可以訪問(wèn)來(lái)自84,936個(gè)會(huì)話的數(shù)據(jù)，這些會(huì)話代表2670種不同的環(huán)境用于研究。 13％的環(huán)境明確指定了GC算法。 其余的決定權(quán)交給了JVM。 因此，在使用顯式GC算法的11,062會(huì)話中，我們能夠區(qū)分出六種不同的GC算法：

在了解有關(guān)GC算法用法的詳細(xì)信息之前，我們應(yīng)該停一分鐘，然后嘗試?yán)斫鉃槭裁瓷厦娴娘瀳D中缺少87％的運(yùn)行。 我們認(rèn)為，這是兩個(gè)不同根本原因的征兆

• 首先也是有充分理由的是– JVM在選擇合理的默認(rèn)值方面已經(jīng)表現(xiàn)出色，以至于開(kāi)發(fā)人員不再需要深入研究。 如果您的應(yīng)用程序吞吐量和延遲足夠，那么–為什么要打擾？
• 缺少GC算法的第二個(gè)可能原因表明，應(yīng)用程序性能并不是團(tuán)隊(duì)的首要任務(wù)。 正如我們?nèi)ツ甑陌咐芯克砻鞯哪菢?#xff0c;僅需調(diào)整一項(xiàng)配置即可顯著提高吞吐量和延遲。

因此，我們有將近83,000個(gè)使用默認(rèn)GC選擇運(yùn)行的JVM。 但是默認(rèn)值是什么？ 答案既簡(jiǎn)單又復(fù)雜。 如果認(rèn)為您正在客戶端JVM上運(yùn)行，則JVM所應(yīng)用的默認(rèn)值為串行GC（-XX：+ UseSerialGC）。 在服務(wù)器級(jí)計(jì)算機(jī)上，默認(rèn)值為并行GC（-XX：+ UseParallelGC）。 可以基于以下決策表確定是在服務(wù)器還是客戶端類(lèi)計(jì)算機(jī)上運(yùn)行：

建筑	CPU /內(nèi)存	操作系統(tǒng)	默認(rèn)
i586	任何	微軟視窗	客戶
AMD64	任何	任何	服務(wù)器
64位SPARC	任何	的Solaris	服務(wù)器
32位SPARC	2個(gè)以上內(nèi)核和> 2GB RAM	的Solaris	服務(wù)器
32位SPARC	1核或<2GB RAM	的Solaris	客戶
i568	2個(gè)以上內(nèi)核和> 2GB RAM	Linux或Solaris	服務(wù)器
i568	1核或<2GB RAM	Linux或Solaris	客戶

但是，讓我們回到在配置中已明確指定GC算法的13％的人。 它以良好的舊串行模式開(kāi)始，毫無(wú)疑問(wèn)，它的用戶群如此之小，以至于在上圖中幾乎看不到它。 實(shí)際上，只有31個(gè)環(huán)境確定這是最佳的GC算法，并且已明確指定了該算法。 考慮到當(dāng)今大多數(shù)平臺(tái)都在多核計(jì)算機(jī)上運(yùn)行，??您應(yīng)該不會(huì)感到驚訝–當(dāng)您擁有多個(gè)核時(shí)，幾乎總是建議從串行模式切換。

GC	計(jì)數(shù)
序列號(hào)	31
平行	1,422
平行舊	1,193
ConcMarkSweep	6,655
CMSIncrementalMode	935
G1	826

其余配置可以分為三組-并行，并發(fā)和G1。 贏家是顯而易見(jiàn)的-并發(fā)標(biāo)記和掃描算法相結(jié)合構(gòu)成了樣本的三分之二以上。 但是，讓我們更深入地研究結(jié)果。

Parallel和ParallelOld模式大致在同一鄰域中，具有1,422和1,193個(gè)樣本。 不足為奇–如果您確定并行模式適合您的年輕一代，那么對(duì)于老一代而言，相同的算法通常也表現(xiàn)良好。 并行模式中另一個(gè)有趣的方面是–從上面可以看出，并行模式是大多數(shù)常見(jiàn)平臺(tái)上的默認(rèn)模式，因此缺乏明確的規(guī)范并不意味著它不比其他模式流行。

對(duì)于CMS，我們的期望有所不同。 即–與具有6556種配置的傳統(tǒng)CMS相比，增量模式僅在935次打開(kāi)。 提醒您-在并發(fā)階段，垃圾收集器線程正在使用一個(gè)或多個(gè)處理器。 增量模式用于通過(guò)定期停止并發(fā)階段以使處理器退還給應(yīng)用程序來(lái)減少長(zhǎng)時(shí)間的并發(fā)階段的影響。 這樣可以縮短暫停時(shí)間，尤其是在處理器數(shù)量少的機(jī)器上。 目前尚不清楚環(huán)境是全部擁有海量核心，還是負(fù)責(zé)配置的人員都不知道增量模式的好處。

但是我們最大的驚喜與G1的采用率有關(guān)。 G1作為垃圾收集算法正在運(yùn)行826個(gè)環(huán)境。 根據(jù)我們的經(jīng)驗(yàn)，無(wú)論您是追求吞吐量還是等待時(shí)間，G1的表現(xiàn)都比CMS差。 也許我們可以訪問(wèn)的測(cè)試用例的選擇不多，但是目前我們認(rèn)為G1需要更多的時(shí)間來(lái)實(shí)際兌現(xiàn)其承諾。 因此，如果您是快樂(lè)的G1用戶，也許可以與我們分享您的經(jīng)驗(yàn)？

參考： 您正在使用什么垃圾收集器？ 由我們的JCG合作伙伴 Nikita Salnikov Tarnovski在Plumbr Blog博客上獲得。

翻譯自: https://www.javacodegeeks.com/2013/11/what-garbage-collector-are-you-using.html

垃圾收集算法,垃圾收集器

總結(jié)

以上是生活随笔為你收集整理的垃圾收集算法,垃圾收集器_您正在使用什么垃圾收集器？的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

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