高對象復制時間導致 G1GC 長時間的垃圾收集暫停

Question

我有一個在獨立 JVM 中運行的 Java 應用程序。 該應用程序偵聽一個或多個套接字上的數據，將數據排入隊列，並已調度線程將數據從隊列中拉出並將其持久化。 數據很寬，每條記錄超過 700 個數據元素，盡管所有數據元素都是小的字符串、整數或長整數。

該應用程序在一段時間內平穩運行，有時 30 分鍾到一個小時，但隨后我們會遇到一個或多個長時間的垃圾收集暫停。 大部分暫停時間花在對象復制時間。 相對於其他集合，系統時間也很高。

這是JVM詳細信息：

java version "1.7.0_03" 
Java(TM) SE Runtime Environment (build 1.7.0_03-b04) 
Java HotSpot(TM) 64-Bit Server VM (build 22.1-b02, mixed mode)

以下是 JVM 選項：

-XX:MaxPermSize=256m -XX:PermSize=256m -Xms3G -Xmx3G -XX:+UseG1GC -XX:-UseGCOverheadLimit 

該過程將任務集設置為 4 個內核（都在同一個套接字上），但幾乎沒有使用其中的 2 個。 這個盒子上的所有進程都固定在它們自己的核心上（0 和 1 未使用）。 機器有足夠的空閑內存（20+G），頂部顯示使用2.5G RES內存的過程。

這是一些 gc 日志輸出...

[Object Copy (ms): 2090.4 2224.0 2484.0 2160.1 1603.9 2071.2 887.8 1608.1 1992.0 2030.5 1692.5 1583.9 2140.3 1703.0 2174.0 1949.5 1941.1 2190.1 2153.3 1604.1 1930.8 1892.6 1651.9

[Eden: 1017M(1017M)->0B(1016M) Survivors: 7168K->8192K Heap: 1062M(3072M)->47M(3072M)] 

[Times: user=2.24 sys=7.22, real=2.49 secs]

關於為什么對象復制時間和系統時間如此之高以及如何糾正它的任何想法？ 日志中有許多垃圾收集，它們的 Eden/Survivors/Heap 大小幾乎相同，只需要 10 或 20 毫秒。

Answer 1

3gb 不是一個大堆，survivor 大小也很小。 在這些內核上運行其他任何東西嗎？ 您產生了多少垃圾，收集的頻率如何？ 您可能也想在沒有 G1GC 的情況下嘗試它。

Answer 2

您需要3 GB 的堆嗎？ 隨着堆變大，垃圾收集暫停會變長，因為（雖然不那么頻繁）在最終需要 GC 時有更多的工作要做。

看來您通過設置最小值將堆鎖定在 3 gig。 如果應用程序不需要 3 gig，這將迫使它無論如何都要使用那么多……並在最終確實需要收集 3g 時導致巨大的暫停。

我花了相當多的時間來調整 Eclipse IDE 的響應能力，並且很早就發現緊湊的堆大小比大的具有更好的“低暫停”特性。

除了 JVM 堆設置之外，您還可以確保您的代碼將數據元素和集合項“歸零”，因為它們會被丟棄。

這是java.util Collections 包中的標准做法，但也許您的代碼可以從中受益。 700 條記錄尤其適合這種做法，這有助於簡化 GC 的工作並更好地清理“次要 GC”掃描。