遇到我无法解决的GC问题，并希望有人可以提供一些见解。真正的解决方法是添加额外的JVM以适应负载，但暂时不能用我的力量。
我的问题是，是否有人可以解释-XX:TargetSurvivorRatio
来自说明：
如果被微调的应用程序具有相对一致的对象分配率，则可以将目标幸存者占用率提高到-XX：TargetSurvivorRatio = 80或-XX：TargetSurvivorRatio = 90。能够这样做的优点有助于减少老化物体所需的幸存空间。设置-XX：TargetSurvivorRatio =更高的挑战是HotSpot VM无法在对象分配率出现峰值的情况下更好地适应对象老化，这可能比您想要的更快地导致终身对象
对象分配率的高峰正是我所遭受的，如下所示：
2015-07-07T15:24:56.592-0500: 2760.113: [GC 2760.113: [ParNew
Desired survivor size 483183816 bytes, new threshold 5 (max 5)
- age 1: 105182048 bytes, 105182048 total
- age 2: 220512 bytes, 105402560 total
- age 3: 292176 bytes, 105694736 total
- age 4: 303792 bytes, 105998528 total
- age 5: 494584 bytes, 106493112 total
: 3155059K->104104K(3670016K), 0.1605850 secs] 10036522K->6986163K(15204352K), 0.1611320 secs] [Times: user=0.29 sys=0.00, real=0.16 secs]
2015-07-07T15:25:06.838-0500: 2770.359: [GC 2770.359: [ParNew
Desired survivor size 483183816 bytes, new threshold 5 (max 5)
- age 1: 405021040 bytes, 405021040 total
- age 2: 114464 bytes, 405135504 total
- age 3: 175872 bytes, 405311376 total
- age 4: 292176 bytes, 405603552 total
- age 5: 302512 bytes, 405906064 total
: 3249821K->398565K(3670016K), 0.1744060 secs] 10131880K->7281107K(15204352K), 0.1747200 secs] [Times: user=0.34 sys=0.00, real=0.18 secs]
2015-07-07T15:25:14.251-0500: 2777.772: [GC 2777.772: [ParNew
Desired survivor size 483183816 bytes, new threshold 1 (max 5)
- age 1: 536174616 bytes, 536174616 total
- age 2: 202152 bytes, 536376768 total
- age 3: 66784 bytes, 536443552 total
- age 4: 175440 bytes, 536618992 total
- age 5: 292176 bytes, 536911168 total
: 3544293K->524288K(3670016K), 1.3915370 secs] 10426835K->8124824K(15204352K), 1.3919310 secs] [Times: user=2.70 sys=0.00, real=1.40 secs]
2015-07-07T15:25:24.958-0500: 2788.479: [GC 2788.479: [ParNew
Desired survivor size 483183816 bytes, new threshold 5 (max 5)
- age 1: 9526032 bytes, 9526032 total
: 3670016K->155222K(3670016K), 0.3542590 secs] 11270552K->7846132K(15204352K), 0.3546270 secs] [Times: user=0.67 sys=0.01, real=0.36 secs]
我的JAVA_OPTS如下：
-Xms15360M
-Xmx15360M
-XX:MaxPermSize=512M
-XX:+CMSClassUnloadingEnabled
-XX:+UseConcMarkSweepGC
-verbose:gc
-XX:+PrintGCDetails
-XX:+PrintGCDateStamps
-Xloggc:logs/gc.log
-XX:+UseCMSInitiatingOccupancyOnly
-XX:CMSInitiatingOccupancyFraction=65
-XX:NewSize=4096M
-XX:MaxNewSize=4096M
-XX:SurvivorRatio=6
-XX:+PrintTenuringDistribution
-XX:PermSize=512M
-XX:-UseAdaptiveSizePolicy
-XX:+DisableExplicitGC
-XX:+ScavengeBeforeFullGC
-XX:MaxTenuringThreshold=5
-XX:TargetSurvivorRatio=90
我一直在减少SurvivorRatio（增加可用的幸存者空间），并按比例增加NewSize，但似乎无论我做什么，我的尖峰总是比我的幸存者空间高20-80 MB，我继续推广垃圾。
回到手边的问题..降低TargetSurvivorRatio会帮助我的峰值吗？如果是这样怎么样？不会将它设置为50％会大幅减少我的可用幸存者空间，导致我过早地提升？关于如何在第一个高度分配的集合中存活下来的任何其他输入将非常感激。谢谢
更新
经过几个小时的阅读，以及我在发布之前研究的日子，我想我终于得出了我的问题的结论。 TargetSurvivorRatio=90对我的用例来说是一个很好的设置。为了将幸存者空间的内存使用率设置为接近TargetRatio，JVM将动态选择一个临时阈值（当然受MaxTenuring限制）以满足期望的目标。
在我的情况下，物体在4岁之后或多或少都有用，而且非常小。容纳年龄：1是我的首要任务 - 非常大量幸存的物体不会活着看到年龄：2。我需要尽可能多的幸存者空间，因为我已经有一个已经超大的JVM，有限旧Gen中的空间，无法分配额外的堆。我的用例不是对象分配率的飙升＆＃34;因为我认为这个选项指的是......它只是一个巨大的峰值。
如果较低的目标比率是有益的，则MaxTenuringThreshold设置为较高的数字，并且一直携带稳定数量的终身对象。如果增加的新终身对象数量增加，并且TargetRatio设置得太高，JVM将无法调整终身阈值以防止过早推广。
关于我的问题的整体解决方案..通过降低比率和/或增加年轻基因大小来增加幸存者的数量