當前位置：首頁 > 编程语言 > java >内容正文

java

java 垃圾回收手动回收_Java垃圾回收（4）

發(fā)布時間：2023/12/3 java 46 豆豆

生活随笔收集整理的這篇文章主要介紹了 java 垃圾回收手动回收_Java垃圾回收（4）小編覺得挺不錯的,現(xiàn)在分享給大家,幫大家做個參考.

java 垃圾回收手動回收

G1：垃圾優(yōu)先

G1收集器是熱點JVM中要實現(xiàn)的最新收集器。自Java 7 Update 4以來，它一直是受支持的收集器。OracleGC團隊也公開表示，他們對低暫停GC的希望是完全實現(xiàn)的G1。這篇文章來自我之前的垃圾收集博客文章：

GC熱點概述。

并行垃圾收集器。

并發(fā)標記掃描。

問題：大堆意味著長暫停時間

并發(fā)標記和掃描（CMS）收集器是當前推薦的低暫停收集器，但是不幸的是，其暫停時間隨使用權區(qū)域中活動對象的數(shù)量而變化。這意味著盡管使用較小的堆相對容易獲得短暫的GC暫停，但是一旦開始使用10或100千兆字節(jié)的堆，時間就會開始增加。

CMS也不會“整理”其堆，因此在某個時間點您會遇到并發(fā)模式故障（CMF），從而觸發(fā)完整的gc。進入完整的gc場景后，您可以預期每千兆字節(jié)活動對象大約在1秒鐘的時間內(nèi)出現(xiàn)暫停。使用CMS，您的100GB堆可能是等待1.5分鐘的GC暫停滴答定時炸彈……

良好的GC調優(yōu)可以解決此問題，但有時只會將問題推向前進。并發(fā)模式故障和完整GC不可避免地會在足夠長的時間范圍內(nèi)出現(xiàn)，除非您處在一小部分專門避免填充其使用期限的人員中。

G1堆布局

G1收集器試圖通過將堆分成不同的區(qū)域來將單個集合的暫停時間與堆的整體大小分開。每個區(qū)域的大小都是固定的，介于1MB和32MB之間，JVM的目標是總共創(chuàng)建大約2000個區(qū)域。

您可能還記得以前的文章，其他收集器將堆分為Eden，Survior Space和Tenured內(nèi)存池。 G1保留相同類別的池，但不是將它們作為連續(xù)的內(nèi)存塊，而是將每個區(qū)域在邏輯上分類為這些池之一。

還有另一種類型的區(qū)域-巨大的區(qū)域。這些對象用于存儲大小比大多數(shù)對象大的對象，例如，很長的數(shù)組。任何大于區(qū)域大小50％的對象都存儲在巨大的區(qū)域中。它們通過獲取連續(xù)位于內(nèi)存中的多個正常區(qū)域并將它們視為單個邏輯區(qū)域來工作。

記憶集

當然，如果您將不得不掃描整個堆以找出哪些對象被標記為活動對象，那么將堆分成多個區(qū)域毫無意義。實現(xiàn)此目標的第一步是將區(qū)域分成稱為卡的512字節(jié)段。每張卡在卡標記表中都有一個1字節(jié)的條目。

每個區(qū)域都有一個關聯(lián)的記憶集或RSet-這是已寫入的卡集。如果來自存儲在卡中的另一個區(qū)域的對象指向該區(qū)域中的對象，則該卡處于記憶集中。

每當增變器寫入對象引用時，就會使用寫屏障來更新已記住的集。在內(nèi)部，將記住的集合分為不同的集合，以便不同的線程可以在沒有爭用的情況下運行，但是從概念上講，所有集合都是同一集合的一部分。

并發(fā)標記

為了識別哪些堆對象是活動的，G1執(zhí)行活動對象的大部分并發(fā)標記。

標記階段標記階段的目標是弄清楚堆中哪些對象是活動的。為了存儲哪些對象處于活動狀態(tài)，G1使用了標記位圖-堆中每64位存儲一個位。從所有對象的根部開始跟蹤，并在標記位圖中使用活動對象標記區(qū)域。這主要是并發(fā)的，但是有一個類似于CMS的“ 初始標記暫停” ，其中應用程序被暫停并且跟蹤根對象的第一級子級。完成此操作后，重新啟動線程。 G1需要對堆中存在的內(nèi)容保持最新了解，因為不會在標記階段的同一暫停中清理堆。
標記階段標記階段的目標是使標記階段中有關活動對象的信息保持最新。首先要做的是確定何時進行標記。由一定百分比的堆已滿觸發(fā)。這是通過從標記階段和此后的分配數(shù)量中獲取信息來計算的，并告訴G1其是否超過了所需的百分比。 G1使用上述寫屏障來記錄對堆的更改，并將其存儲在一系列更改緩沖區(qū)中。更改緩沖區(qū)中的對象同時在標記位圖中標記。當達到填充百分比時，將再次暫停更改程序線程并處理更改緩沖區(qū)，從而將更改緩沖區(qū)中的對象標記為活動狀態(tài)。
清理階段此時，G1知道哪些對象處于活動狀態(tài)。由于G1專注于可用空間最大的區(qū)域，因此其下一步是通過計算活動對象來計算給定區(qū)域中的可用空間。這是從標記位圖計算得出的，然后根據(jù)最有可能收集哪些區(qū)域來對區(qū)域進行排序。要收集的區(qū)域存儲在所謂的收集集或CSet中。

疏散

與半球年輕一代在并行GC和CMS收集器中采用的方法類似，不會收集死物。取而代之的是，將有生命的物體從某個區(qū)域撤離，然后將整個區(qū)域視為空閑區(qū)域。

G1對于如何回收活動物體很聰明–它不會嘗試在給定的周期內(nèi)回收所有活動物體。它針對的是可能會回收盡可能多空間的區(qū)域，僅將其撤離。它通過計算活動對象在一個區(qū)域內(nèi)的比例并選擇活動對象比例最低的區(qū)域來確定其目標區(qū)域。

將物體從多個其他區(qū)域撤離到自由區(qū)域。這意味著G1在執(zhí)行GC時會壓縮數(shù)據(jù)。這由多個線程并行操作。傳統(tǒng)的“平行GC”可以做到這一點，而CMS不這樣做。

與CMS和Parallel GC相似，存在權屬概念。也就是說，如果年輕對象在足夠的收藏中存活下來，它們就會變“舊”。此數(shù)字稱為任職期限。如果年輕的世代區(qū)域幸存下來，并且保留了足夠的活物以避免被疏散，那么該區(qū)域將得到提升。首先是幸存者，最后是終身制地區(qū)。它從未被疏散。

疏散失敗

不幸的是，G1仍然會遇到類似于并發(fā)模式故障的情況，在這種情況下，它會退回到Stop the World Full GC。這稱為疏散失敗，在沒有空閑區(qū)域時發(fā)生。沒有自由區(qū)域意味著沒有地方疏散物體。

從理論上說，與CMS中的并發(fā)模式故障相比，G1中發(fā)生疏散失敗的可能性較小。這是因為G1會即時壓縮其區(qū)域，而不僅僅是等待壓縮失敗。

結論

盡管進行了壓縮和在低暫停時做出的努力，但G1并不能保證會取得成功，因此采用它的任何嘗試都應伴隨有客觀且可衡量的性能目標以及GC Log分析。所需的方法超出了本博客文章的范圍，但希望我在以后的文章中介紹它。

從算法上講，G1會遇到其他Hotspot收集器不會遇到的開銷。值得注意的是，維護記憶集的成本。并行GC仍然是推薦的吞吐量收集器，并且在許多情況下CMS都比G1更好。

現(xiàn)在說G1是否會比CMS收集器大勝還為時過早，但是在某些情況下，它已經(jīng)為使用它的開發(fā)人員提供了好處。隨著時間的流逝，我們將看到G1的性能限制是否真的是G1的限制，或者開發(fā)團隊是否只是需要更多的工程工作來解決那里的問題。

感謝John Oliver ， Tim Monks和Martijn Verburg審閱了本指南和以前的GC文章的草稿。

參考： Insightful Logic博客上來自我們JCG合作伙伴 Richard Warburton的Java垃圾收集（4）。

翻譯自: https://www.javacodegeeks.com/2013/07/garbage-collection-in-java-4.html