日志片段显示您拥有大量可存活超过320秒的对象（每个年轻集合大约40
s，并且在升级之前，对象可以通过8个集合生存）。剩余的对象随后流失到永久使用权，最终您遇到了一个明显意外的完整gc，实际上并没有收集太多。
3453285K->3099828K(4194304K)
也就是说，您有一个4G的使用权，在触发时使用率约为〜82％（3453285/4194304），而在13秒钟后则约为〜74％。
这意味着要花13秒钟才能收集到约350M的总数，这在6G堆的情况下是不多的。
这基本上意味着您的堆不够大，或者更有可能发生内存泄漏。像这样的泄漏对于CMS来说是一个可怕的事情，因为并发的权属集合是非压缩事件，这意味着权属是自由列表的集合，这意味着碎片对于CMS可能是个大问题，这意味着权能的使用效率越来越低，意味着升级失败事件的可能性增加（尽管如果是这样的事件，那么我希望看到一条日志消息说），因为它想将X
MB升级为（或认为需要升级）X终身制但没有可用的（连续的）空闲列表，该列表> = X MB。这将触发意外的永久集合，这是一个不是远程并发的STW事件。
一些一般性的指示在很大程度上重申了弗拉基米尔·西尼托夫所说的…
- 在多核计算机上使用iCMS没有任何意义（除非您在该计算机上运行了 许多 JVM或其他进程，使得JVM确实缺乏CPU），因此请删除此开关
- 由于每个幸存者空间之间会在每个集合之间复制相对大量的内存，因此您的年轻集合会不必要地长，150-200ms是一个非常庞大的
ParNew
集合- 对年轻一代问题的正确答案取决于分配行为的真正含义（例如，也许您会更好地尽早使用权，并减少碎片化对长期收藏的影响，或者也许您会拥有更多新的更好的选择并减少年轻一代的收集频率，这样可以减少推广的对象，从而使流失到使用年限的可能性降到最低。
一些问题…
- 最终会达到OoM还是恢复？
- 在此日志摘要中，应用程序处于稳定状态（在启动后的某个时刻承受一致的负载）还是处于压力之下？
