當(dāng)前位置：首頁(yè) >

7-8垃圾箱分布_您认为有关垃圾收集的7件事-完全错了

發(fā)布時(shí)間：2023/12/3 51 豆豆

生活随笔收集整理的這篇文章主要介紹了 7-8垃圾箱分布_您认为有关垃圾收集的7件事-完全错了小編覺(jué)得挺不錯(cuò)的,現(xiàn)在分享給大家,幫大家做個(gè)參考.

7-8垃圾箱分布

關(guān)于Java Garbage Collection的最大誤解是什么？它的真實(shí)情況如何？

小時(shí)候，我的父母曾經(jīng)告訴我，如果我學(xué)習(xí)不好，我將成為垃圾收集者。他們幾乎不知道，垃圾回收實(shí)際上是很棒的。也許這就是為什么即使在Java世界中，許多開(kāi)發(fā)人員也會(huì)誤解GC算法：它們?nèi)绾喂ぷ?#xff0c;GC如何影響其應(yīng)用程序以及您可以對(duì)此做些什么。這就是為什么我們求助 Java性能調(diào)優(yōu)專(zhuān)家Haim Yadid并將Java性能調(diào)優(yōu)指南放到Takipi博客上的原因。

新帖：關(guān)于垃圾回收的7件事您以為您知道-完全錯(cuò)了http://t.co/3QJLJuKCRq pic.twitter.com/aqQEF0zTkK

— Takipi（@takipid） 2015年4月6日

由于對(duì)性能調(diào)優(yōu)指南的興趣，在此后續(xù)文章中，我們決定收集一些有關(guān)垃圾回收的流行觀點(diǎn)，并向您展示為什么它們是完全錯(cuò)誤的。以下是前7名：

1.只有一個(gè)垃圾收集器

不，并且4也不是正確的答案。 HotSpot JVM總共有4個(gè)垃圾收集器：串行，并行/吞吐量。 CMS，并在塊G1上新建一個(gè)孩子。但是，還有更多，還有非標(biāo)準(zhǔn)的垃圾收集器，還有更多冒險(xiǎn)的實(shí)現(xiàn)，例如Shenandoah或其他JVM使用的收集器（例如C4， Azul的不間斷收集器）。 HotSpot的默認(rèn)值是并行/吞吐量收集器，通常它不是您的應(yīng)用程序的最佳選擇。例如，CMS和G1收集器將導(dǎo)致較少的GC暫停。但是，當(dāng)出現(xiàn)暫停時(shí)，其持續(xù)時(shí)間很可能會(huì)比Parallel收集器引起的持續(xù)時(shí)間更長(zhǎng)。另一方面，對(duì)于相同大小的堆，并行收集器通常可實(shí)現(xiàn)更高的吞吐量。

總結(jié)：根據(jù)您的要求選擇合適的垃圾收集器：可接受的GC暫停頻率和持續(xù)時(shí)間。

2.并行=并發(fā)

垃圾回收周期可以是STW（緊急停止）并導(dǎo)致GC暫停，也可以并發(fā)執(zhí)行而無(wú)需停止應(yīng)用程序。當(dāng)我們更進(jìn)一步時(shí)，GC算法本身可以是串行（單線(xiàn)程）或并行（多線(xiàn)程）的。這就是為什么當(dāng)我們提到并發(fā)GC時(shí)，它不一定意味著它是并行完成的；反之，當(dāng)我們提到串行GC時(shí)，它并不一定意味著它會(huì)引起暫停。在垃圾回收世界中，Concurrent和Parallel是兩個(gè)絕對(duì)不同的術(shù)語(yǔ)，其中Concurrent是指GC周期，而Parallel是指GC算法本身。

總結(jié)：垃圾回收是一個(gè)兩步游戲，調(diào)用GC周期的方式及其進(jìn)行業(yè)務(wù)的方式是兩件不同的事情。

3. G1解決了所有問(wèn)題

G1收集器是Java 7中引入的，并且經(jīng)過(guò)了許多更改和修改，是JVM垃圾收集器的最新成員。主要優(yōu)勢(shì)在于，它解決了CMS收集器常見(jiàn)的碎片問(wèn)題：GC循環(huán)釋放舊一代的內(nèi)存塊，并使它看起來(lái)像瑞士奶酪，直到一會(huì)兒JVM無(wú)法處理并不得不停止并停止運(yùn)行。處理碎片。但這還不是故事的結(jié)局，在某些情況下其他收藏家的表現(xiàn)可能優(yōu)于G1。這完全取決于您的要求。

要點(diǎn)：沒(méi)有所有GC問(wèn)題的奇跡解決方案，需要進(jìn)行實(shí)驗(yàn)以幫助您為JVM選擇正確的收集器。

4.平均交易時(shí)間是最重要的指標(biāo)

如果僅監(jiān)視服務(wù)器中的平均交易時(shí)間，那么您會(huì)錯(cuò)過(guò)異常值。人們對(duì)系統(tǒng)用戶(hù)的破壞性知之甚少。例如，通常需要100毫秒以下的事務(wù)可能會(huì)受到GC暫停的影響，并且需要一分鐘才能完成。如果您只查看平均交易時(shí)間，那么除了用戶(hù)以外的任何人都不會(huì)注意到。現(xiàn)在考慮1％或更多用戶(hù)的這種情況，您會(huì)發(fā)現(xiàn)僅查看平均值就可以輕松忽略它。有關(guān)與延遲相關(guān)的更多問(wèn)題以及解決方法，請(qǐng)點(diǎn)擊此處查看Gil Tene的博客。

要點(diǎn)：密切注意異常值，了解系統(tǒng)在第99個(gè)百分位數(shù)（不是1％）上的表現(xiàn)。

5.降低新的對(duì)象分配率將改善GC行為

我們可以將系統(tǒng)中的對(duì)象大致分為三類(lèi)：長(zhǎng)期存在的對(duì)象，通常對(duì)它們我們無(wú)能為力，導(dǎo)致最大問(wèn)題的中期存在的對(duì)象，以及通常被釋放并導(dǎo)致長(zhǎng)期生存的短期對(duì)象分配Swift，因此它們?cè)谙乱粋€(gè)GC周期中消失了。中度對(duì)象是那些注重其分配率可以帶來(lái)積極結(jié)果的對(duì)象。集中精力于短期和長(zhǎng)期的對(duì)象通常不會(huì)被證明是有效的，控制中期對(duì)象通常是一項(xiàng)艱巨的任務(wù)。

要點(diǎn)：并不是唯一的對(duì)象分配速率會(huì)限制您的服務(wù)器，而是造成所有麻煩的對(duì)象類(lèi)型。

6.調(diào)整可以解決所有問(wèn)題

如果您的應(yīng)用程序需要保持經(jīng)常更改的大型狀態(tài)，那么調(diào)整JVM的堆并不會(huì)帶來(lái)太多好處。 GC長(zhǎng)時(shí)間停頓是不可避免的。可以在體系結(jié)構(gòu)更改方面提出解決方案，以確保具有關(guān)鍵過(guò)程/瓶頸影響響應(yīng)時(shí)間的流程不會(huì)包含大狀態(tài)。大型狀態(tài)和響應(yīng)能力不能很好地結(jié)合在一起：將其分解為不同的流程將是解決之道。

總結(jié)：并非所有問(wèn)題都可以通過(guò)調(diào)整JVM標(biāo)志來(lái)解決，有時(shí)您只需要回到繪圖板上即可。

7. GC日志會(huì)導(dǎo)致大量開(kāi)銷(xiāo)

這是完全不正確的，尤其是默認(rèn)的日志設(shè)置。數(shù)據(jù)非常有價(jià)值，并且Java 7引入了掛鉤來(lái)控制它們的大小，并確保它們不會(huì)耗盡您的所有硬盤(pán)驅(qū)動(dòng)器。如果您不收集GC日志數(shù)據(jù)，那么您將失去了解JVM垃圾收集在生產(chǎn)中的行為的唯一途徑。可接受的GC開(kāi)銷(xiāo)通常有5％的上限，要知道系統(tǒng)中的收費(fèi)GC暫停產(chǎn)生了什么樣的費(fèi)用并將其最小化，付出的代價(jià)是很小的。

總結(jié)：竭盡所能，在生產(chǎn)中從系統(tǒng)中獲取最多的數(shù)據(jù)。那里是一個(gè)完全不同的世界。

結(jié)論

我們希望這些內(nèi)容能幫助您更好地了解Java中垃圾回收的真正工作方式。您是否在應(yīng)用程序中認(rèn)識(shí)到其中一些問(wèn)題？您是否遇到其他更常見(jiàn)的垃圾回收錯(cuò)誤？在下面的評(píng)論部分讓我們知道。

翻譯自: https://www.javacodegeeks.com/2015/04/7-things-you-thought-you-knew-about-garbage-collection-and-are-totally-wrong.html