10

目前我面临的问题是我的应用程序偶尔会显示较长的 GC 时间，但所有这些都只是由弱引用处理引起的。所以线程停止时间总是接近weak ref处理时间。所有其他 GC 周期为 0.0001 秒到 0.200 秒。

从 gc.log （重新格式化）：

10388.186: [GC[YG occupancy: 206547 K (306688 K)]10388.186: [Rescan (parallel) , 
 0.1095860 secs]10388.295: [weak refs processing, 2.0799570 secs] 
 [1 CMS-remark:  2973838K(3853568K)] 3180386K(4160256K), 2.1899230 secs] 
 [Times: user=2.51 sys=0.00, real=2.18 secs]
Total time for which application threads were stopped: 2.1906890 seconds

目前我有这些设置。尝试了更简单的设置，但没有改变。

-Xms4g
-Xmx4g
-XX:NewSize=128m
-XX:+UseConcMarkSweepGC
-XX:+CMSIncrementalMode
-XX:MaxGCPauseMillis=50
-XX:CMSInitiatingOccupancyFraction=50
-XX:ParallelGCThreads=16
-XX:+DisableExplicitGC

如果我打开 NewSize，我最终会得到很长的正常 GC 周期。该机器有 8 个核心，不会为应用程序消耗那么多 CPU。试图尽早并同时运行老一代 GC。

是的，我无法摆脱弱引用的使用，因为这是第 3 方库的一部分。

4

1 回答 1

7

我在“hotspot-gc-use”邮件列表中找到了这条消息。

简而言之，试试-XX:+ParallelRefProcEnabled开关。

更新

我在 Jon Masamitsu 的博客中找到了更好的解释：

6）低暂停收集器中的并行引用处理。

对于广泛使用Reference对象的应用程序，处理引用对象的 GC 工作可能很明显。在低暂停收集器中它不一定比在其他收集器中更糟，但它更痛苦（因为我们试图保持低暂停）。并行引用处理可用于低暂停收集器，但默认情况下不启用。除非有大量的引用对象，否则串行执行引用处理通常更快。-XX:+ParallelRefProcEnabled如果您广泛使用Reference对象（大多数应用程序没有），请使用标志打开它。

于 2010-11-04T21:57:44.917 回答