Java GC-了解TargetSurivorRatio

Java GC-了解TargetSurivorRatio,java,garbage-collection,Java,Garbage Collection,有一个GC问题,我似乎无法解决,希望有人能提供一些见解。真正的解决办法是添加额外的JVM以适应负载,但这在目前是我力所不及的 我的问题是,是否有人能解释-XX:TargetSurvivorRatio 根据描述: 如果正在微调的应用程序具有相对一致的对象分配率,则可以将目标幸存者占用率提高到高达-XX:TargetSurvivorRatio=80或-XX:TargetSurvivorRatio=90的水平。这样做的优势有助于减少老化对象所需的幸存者空间量。将-XX:targetSurviorRat

有一个GC问题,我似乎无法解决,希望有人能提供一些见解。真正的解决办法是添加额外的JVM以适应负载,但这在目前是我力所不及的

我的问题是,是否有人能解释
-XX:TargetSurvivorRatio

根据描述:

如果正在微调的应用程序具有相对一致的对象分配率,则可以将目标幸存者占用率提高到高达-XX:TargetSurvivorRatio=80或-XX:TargetSurvivorRatio=90的水平。这样做的优势有助于减少老化对象所需的幸存者空间量。将-XX:targetSurviorRatio=设置得更高的挑战在于,在对象分配率出现峰值的情况下,热点VM无法更好地适应对象老化,这可能会导致对象比您希望的时间更短

对象分配率的峰值正是我所遭受的,如下所示:
2015-07-07T15:24:56.592-0500:2760.113:[GC 2760.113:[ParNew]
所需幸存者大小483183816字节,新阈值5(最大值5)
-年龄1:105182048字节,总计105182048字节
-年龄2:220512字节,总计105402560字节
-年龄3:292176字节,总计105694736
-年龄4:303792字节,总计105998528
-年龄5:494584字节,总计106493112
:3155059K->104104K(3670016K),0.1605850秒]10036522K->6986163K(15204352K),0.1611320秒][次数:用户=0.29系统=0.00,实际=0.16秒]
2015-07-07T15:25:06.838-0500:2770.359:[GC 2770.359:[ParNew
所需幸存者大小483183816字节,新阈值5(最大值5)
-年龄1:405021040字节,总计405021040
-年龄2:114464字节,总计405135504
-年龄3:175872字节,总计405311376
-年龄4:292176字节,总计405603552
-年龄5:302512字节,总计405906064
:3249821K->398565K(3670016K),0.1744060秒]10131880K->7281107K(15204352K),0.1747200秒][次:用户=0.34系统=0.00,实际=0.18秒]
2015-07-07T15:25:14.251-0500:2777.772:[GC 2777.772:[ParNew
所需幸存者大小483183816字节,新阈值1(最大值5)
-年龄1:536174616字节,总计536174616
-年龄2:202152字节,总计536376768
-年龄3:66784字节,总计536443552
-年龄4:175440字节,总计536618992
-年龄5:292176字节,总计536911168
:3544293K->524288K(3670016K),1.3915370秒]10426835K->81248244K(15204352K),1.3919310秒][次:用户=2.70系统=0.00,实际=1.40秒]
2015-07-07T15:25:24.958-0500:2788.479:[GC 2788.479:[ParNew
所需幸存者大小483183816字节,新阈值5(最大值5)
-年龄1:9526032字节,总计9526032
:3670016K->155222K(3670016K),0.3542590秒]11270552K->7846132K(15204352K),0.3546270秒][次数:用户=0.67系统=0.01,实数=0.36秒]

我的JAVA_选项如下:

-Xms15360M
-Xmx15360M
-XX:MaxPermSize=512M
-XX:+CMSClassUnloadingEnabled
-XX:+UseConMarkSweepGC
-详细:gc
-XX:+PrintGCDetails
-XX:+打印日期戳
-Xloggc:logs/gc.log
-XX:+仅使用CMSINITIATING职业
-XX:CMSInitiatingOccupancyFraction=65
-XX:NewSize=4096M
-XX:MaxNewSize=4096M
-XX:生存率=6
-XX:+PrintTenuringDistribution
-XX:PermSize=512M
-XX:-使用自适应策略
-XX:+DisableExplicitGC
-XX:+GC
-XX:MaxTenuringThreshold=5
-XX:TargetSurvivorRatio=90

我一直在减少生存空间(增加可用生存空间),并按比例增加新闻大小,但似乎无论我做什么,我的峰值总是比我的生存空间大20-80MB,我继续推广垃圾

回到手头的问题。。降低TargetSurviviorRatio是否有助于我的扣球?如果是这样,怎么办?将其设置为50%是否会大幅减少我的可用幸存者空间,导致我过早地提升更多的次数?如果您对我如何在第一次高度分配的收藏中幸存下来有任何其他意见,我们将不胜感激。多谢各位

更新

经过几个小时的阅读,以及我在发帖前花了几天的时间进行研究,我想我终于对我的问题得出了结论
targetsurviorratio=90
对于我的用例来说是一个很好的设置。为了将存留空间的内存使用设置为接近TargetRatio,JVM将动态选择一个寿命阈值(当然受MaxTenuring的限制),以达到预期的目标

在我的例子中,物体在4岁以后或多或少是终身的,而且非常小。适应年龄:1是我的首要任务——大量存活下来的物体不能活到年龄:2。我需要尽可能多的幸存者可用空间,因为我有一个已经过大的JVM,旧版本中的空间有限,并且没有能力分配额外的堆。我的用例不是“对象分配率的峰值”,因为我认为该选项指的是。。。这只是一个巨大的钉子

较低的目标比率将有利于将MaxTenuringThreshold设置为一个较高的数字,并始终携带稳定数量的TenuringThreshold对象。如果新保留的对象数量增加,并且TargetRatio设置得太高,JVM将无法调整保留阈值以防止过早升级

至于我的问题的整体解决方案。。通过降低比率和/或增加年轻一代的大小来增加幸存者的大小