這篇文章將討論一種技術(shù)，以減少應(yīng)用程序等待時(shí)間造成的垃圾收集暫停的負(fù)擔(dān)。 正如我?guī)啄昵八鶎?#xff0c; 在JVM中無法禁用垃圾收集 。 但是，有一個(gè)巧妙的技巧可以用來大大減少長(zhǎng)時(shí)間停頓的時(shí)間和頻率。

如您所知，JVM中發(fā)生了兩個(gè)不同的GC事件，稱為次要和主要集合。 關(guān)于這些收集期間發(fā)生的事情，有很多可用的材料，因此，我將不著重于詳細(xì)描述其機(jī)制。 我只想提醒一下，在Hotspot JVM中-在次要收集期間，會(huì)收集eden和幸存者空間，在主要收集中，保管空間也會(huì)被清理和（可能）壓縮。

如果打開GC日志記錄（例如-XX：+ PrintGCDetails ），則會(huì)立即注意到主要集合是您應(yīng)關(guān)注的集合。 一次大型垃圾收集的時(shí)間通常比一個(gè)清潔的年輕空間大幾倍。 在大型GC中，有兩個(gè)方面需要更多時(shí)間才能完成。 首先，年輕空間中的幸存者被復(fù)制到老地方。 接下來，除了清除舊版本中未使用的引用外，大多數(shù)GC算法還壓縮了舊空間，再次需要消耗寶貴的CPU周期。

在舊空間中放置許多對(duì)象也增加了從舊空間到年輕空間的引用更多的可能性。 當(dāng)檢查這些表以確定年輕空間中的對(duì)象是否適合使用GC時(shí)，這將導(dǎo)致更大的卡片表 ，跟蹤引用并增加次要GC暫停的時(shí)間。

因此，如果我們無法關(guān)閉垃圾收集，是否可以確保這些冗長(zhǎng)的大型GC的運(yùn)行頻率降低，并且從使用權(quán)空間到Y(jié)oung的引用計(jì)數(shù)保持較低水平？

答案是肯定的。 甚至有一些瘋狂的配置已完全擺脫了主要的GC。 擺脫主要的GC事件確實(shí)是一項(xiàng)復(fù)雜的工作，但是減少這些長(zhǎng)時(shí)間停頓的頻率是每個(gè)部署都可以實(shí)現(xiàn)的目標(biāo)。

我們正在考慮的策略是限制使用期限的對(duì)象數(shù)量。 例如，在典型的Web應(yīng)用程序中，創(chuàng)建的大多數(shù)對(duì)象僅在HttpRequest期間才有用。 存在并且將始終具有更長(zhǎng)的壽命的共享狀態(tài)，但是關(guān)鍵在于以下事實(shí)：短暫生存的對(duì)象與長(zhǎng)期生存的共享狀態(tài)的比率非常高。

現(xiàn)在進(jìn)行任何部署的棘手部分是了解為短期對(duì)象提供多少肘部空間，以便

• 您可以保證短期對(duì)象不會(huì)被提升為終身空間
• 您不會(huì)過度配置，從而增加了基礎(chǔ)架構(gòu)的成本

從概念上講，做到這一點(diǎn)很容易。 您只需要測(cè)量在請(qǐng)求期間為短期對(duì)象分配的內(nèi)存量，并將其與峰值加載時(shí)間相乘即可。 您將要得到的結(jié)果是您想要在eden或單個(gè)幸存者空間中容納的內(nèi)存量。 這將使GC真正有效地運(yùn)行，而不會(huì)意外升級(jí)為終身保有權(quán)。 從概念層面進(jìn)行放大會(huì)發(fā)現(xiàn)一些復(fù)雜的技術(shù)問題，我將在以后的文章中介紹這些問題。

那么從這里可以得出什么結(jié)論呢？ 首先-為您的應(yīng)用程序確定理想的GC配置是一項(xiàng)復(fù)雜的工作。 這既是壞消息，也是好消息。 不好的是–它需要您進(jìn)行大量的實(shí)驗(yàn)。 考慮到這一點(diǎn)，我們很樂意解決棘手的問題，目前正在制定實(shí)驗(yàn)以進(jìn)一步研究該領(lǐng)域。 有朝一日，在不久的將來， Plumbr能夠?yàn)槟瓿纱巳蝿?wù)，從而使您免于無聊的管道工作，并使您可以專注于手頭的實(shí)際問題。

翻譯自: https://www.javacodegeeks.com/2014/10/reducing-the-frequency-of-major-gc-pauses.html

總結(jié)

以上是生活随笔為你收集整理的减少主要GC暂停的频率的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

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