-1

我正在使用 3GB 堆空间运行一个 java 程序。过了一会儿,我在 gc 日志中注意到了这一点。

申请时间:0.8263100秒

2015-03-13T07:24:49.065-0700:77177.620:[GC 前 GC:

BinaryTreeDictionary 的统计信息:


总可用空间:2960457

最大块大小:1233864

块数:393

AV。块大小:7532

树高:19

GC之前:

BinaryTreeDictionary 的统计信息:


总可用空间:0

最大块大小:0

块数:0

树高:0

77177.620:[ParNew(0:提升失败大小 = 2154)(1:提升失败大小 = 2154)(2:提升失败大小 = 2154)(3:提升失败大小 = 2154)(4:提升失败大小 = 2154)( 5:提升失败大小 = 2154)(6:提升失败大小 = 2154)(7:提升失败大小 = 2154)(8:提升失败大小 = 2154)(10:提升失败大小 = 2154)(11:提升失败大小= 2154) (12: 提升失败大小 = 2154) (13: 提升失败大小 = 2154) (14: 提升失败大小 = 2154) (15: 提升失败大小 = 2154) (16: 提升失败大小 = 2154) (17 : 提升失败大小 = 2154) (18: 提升失败大小 = 2154) (19: 提升失败大小 = 2154) (20: 提升失败大小 = 2154) (21: 提升失败大小 = 2154) (22: 提升失败大小 = 2154) (23: 提升失败大小 = 2154) (24:提升失败大小 = 2154) (25: 提升失败大小 = 2154) (26: 提升失败大小 = 2154) (27: 提升失败大小 = 2154) (提升失败): 346350K->333366K(393216K), 0.3779580 秒]77177.998 : [CMSCMS: 大块 0x00000007b7da3200

: 2156277K->1695244K(2621440K), 11.2619970 secs] 2481226K->1695244K(3014656K), [CMS Perm : 193077K->191199K(256000K)]GC后:

BinaryTreeDictionary 的统计信息:


总可用空间:118536640

最大块大小:118536640

块数:1

AV。区块大小:118536640

树高:1

GC之后:

BinaryTreeDictionary 的统计信息:


总可用空间:0

最大块大小:0

块数:0

树高:0

, 11.6404220 秒] [时间:用户=16.85 系统=0.04,实际=11.64 秒]

应用程序线程停止的总时间:11.6432380 秒

申请时间:0.0421420秒

应用程序线程停止的总时间:0.0189740 秒

由于这次 Full GC,我的程序停止了 11 秒。它导致了巨大的性能问题。问题是,人们到处都在说[促销失败=碎片化]。如果是这样,那么为什么 GC 之前的最大块大小(1233864)仍然大于所有提升失败块大小(2154)的总和。

我到处检查,但无法找到导致此问题的原因。

这里有人知道这种情况不断发生的原因吗?

4

1 回答 1

1

使用此收集器时最大的担忧是遇到提升失败,这是在收集年轻代和年老代之间发生竞争条件的情况。如果收集器需要将年轻对象提升到老年代,但没有足够的时间来清理空间,它必须首先这样做,这将导致完整的 STW 收集——这正是这个 CMS 收集器的意思阻止。为了确保不会发生这种情况,您要么增加老年代(或整个堆)的大小,要么为收集器分配更多的后台线程,让他与对象分配的速度竞争。

于 2015-03-16T12:13:46.723 回答