我正在使用3GB堆空间运行java程序。过了一会儿，我在gc日志中注意到了这一点。
申请时间：0.8263100秒
2015-03-13T07：24：49.065-0700：77177.620：[GC之前GC：
BinaryTreeDictionary的统计信息：
总可用空间：2960457
最大块大小：1233864
街区数量：393
平均。块大小：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：Large 块0x00000007b7da3200
：2156277K-> 1695244K（2621440K），11.2619970 secs] 2481226K-> 1695244K（3014656K），[CMS Perm： 193077K-> 191199K（256000K）] GC之后：
BinaryTreeDictionary的统计信息：
总可用空间：118536640
最大块大小：118536640
块数：1
平均。块大小：118536640
树高：1
GC之后：
BinaryTreeDictionary的统计信息：
总可用空间：0
最大块大小：0
块数：0
树高：0
，11.6404220 secs] [时间：用户= 16.85 sys = 0.04，真实= 11.64秒]
应用程序线程停止的总时间：11.6432380 秒
申请时间：0.0421420秒
应用程序线程停止的总时间：0.0189740 秒
由于这个Full GC，我的程序停止了11秒。它造成了巨大的性能问题。问题是，到处都有人在说[促销失败=碎片化]。如果是这样，那么为什么GC之前的最大块大小（1233864）仍然超过所有促销失败块大小（2154）的总和。
我到处检查，但无法找到导致此问题的原因。
有没有人知道这种情况持续发生的原因？
答案 0 :(得分：1)
使用此收藏家时最大的担忧是遇到促销失败，这是在收集年轻一代和老一代之间发生竞争条件的情况。如果收藏家需要将年轻物品推广到老一代，但没有足够的时间来清空空间，那么首先必须这样做，这将导致完整的STW收藏 - 这就是CMS收藏家的意思阻止。为了确保不会发生这种情况，您可以增加旧代（或整个堆）的大小，或者为收集器分配更多后台线程，以便与对象分配速率竞争。