调整GC用于Java音频应用程序

发布时间：2020-12-14 05:44:10 所属栏目：Java 来源：网络整理

导读：我注意到在 java中播放音频时,gc中的MarkSweepCompact阶段太长并导致短暂的静音,这是不可接受的.所以我需要使用低暂停gc.我尝试过Parallel和CMS,它们似乎工作得更好,因为我认为暂停时间更短,并且它们不会像默认那样经常完全收集. 到目前为止,我已经使用Paral

我注意到在 java中播放音频时,gc中的MarkSweepCompact阶段太长并导致短暂的静音,这是不可接受的.所以我需要使用低暂停gc.我尝试过Parallel和CMS,它们似乎工作得更好,因为我认为暂停时间更短,并且它们不会像默认那样经常完全收集.

到目前为止,我已经使用ParallelGC的以下选项测试了我的程序：

-XX:+UseParallelGC 
-XX:MaxGCPauseMillis=70

对于ConcurrentMarkSweep：

-XX:+UseConcMarkSweepGC
-XX:+CMSIncrementalMode
-XX:+CMSIncrementalPacing

我也尝试过G1GC,但它仍然在java 6中实验性.两种模式的选项：

-Xms15m
-Xmx40m
-XX:+UnlockExperimentalVMOptions
-XX:+CMSClassUnloadingEnabled
-XX:+TieredCompilation
-XX:+AggressiveOpts
-XX:+UseAdaptiveSizePolicy
-Dsun.java2d.noddraw=false
-Dswing.aatext=true
-XX:MaxPermSize=25m
-XX:MaxHeapFreeRatio=10
-XX:MinHeapFreeRatio=10

哪种GC在这种情况下更好？是否可以针对最佳CPU性能和最小内存使用量对这些设置进行优化？

编辑为了识别暂停,我记录了将音频数据写入输出线的时间,通常在92到120毫秒之间(我正在写16384字节= ~92毫秒),广告在运行全GC时,它是200毫秒：

65.424: [Full GC (System) [PSYoungGen: 872K->0K(2432K)] [PSOldGen: 12475K->12905K(16960K)] 13348K->12905K(19392K) [PSPermGen: 15051K->15051K(22272K)],0.2145081 secs] [Times: user=0.20 sys=0.00,real=0.21 secs] 
Was writing 16384 bytes,time to write 263 ms

EDIT2我的应用程序的分配模式如下：它在启动时加载一堆对象,然后它开始播放,我猜之后的大多数对象都由gui分配,因为凝视/暂停音频不会改变GC图形许多.这是visualgc与并行gc一起显示的内容：

图表在启动时开始,我开始播放.标记是

1)声音延迟和完整的gc,我认为它增加了旧尺寸：

101.646: [Full GC [PSYoungGen: 64K->0K(6848K)] [PSOldGen: 15792K->12773K(19328K)] 15856K->12773K(26176K) [PSPermGen: 15042K->14898K(23808K)],0.2411479 secs] [Times: user=0.19 sys=0.00,real=0.24 secs]

2)我打开应用程序窗口并暂停播放.什么都没有改变,稍后它增加了伊甸园的大小.

3)我打开窗口再次开始播放.

所以我需要增加分配的旧Gen大小？我怎么做？我正在使用-XX：NewRatio = 10和-XX：NewSize = 10m

谢谢.

解决方法

你提供的日志太小,无法提供真实的分析,但它表示,由于旧的基本上已经满了,它花了200毫秒做v.这意味着您的堆太小或您有内存泄漏.在这种情况下,您无法调整GC算法.因此,本回复的其余部分是关于如何从应用程序中获取更多信息和/或如何在消除内存泄漏或具有更大堆时调整GC.

在很大程度上,低暂停意味着尽一切可能将集合保留为年轻集合.

您确实需要在开始和完成写入时准确记录,然后将其与在此期间发生在JVM中的STW暂停相关联,否则您实际上不知道可能导致问题的原因或问题的严重程度.

我马上做的事情;

>更改日志记录,以便输出可由脚本轻松解析的单行(可能是starttime,endtime,duration)
>添加PrintGCApplicationStoppedTime和PrintGCApplicationConcurrentTime开关,以便获得每个STW暂停的记录,而不仅仅是GC事件
>使用最新的JVM(即6u23),因为在过去的一两年里,热点已经有很多改进,所以有一点使用较旧的
>你没有说你是否受到内存限制但是如果可以的话我肯定会增加堆大小,40M非常小,所以你没有足够的空间来玩
>运行连接visualgc的应用程序,它可以更全面地了解IMO的内容,因为您一次可以查看所有不同的视图

关键是确定你的空间不足以及原因.答案可能在于你的应用程序的分配模式是什么样的,它是否会产生一堆短暂的物体,这样你就可以很快地烧掉你的小伊甸园？暂停阈值太高,以至于你无论如何都要通过幸存者空间ping对象,从而迫使频繁的终身gcs(慢)？

还有一些要记住的事情……

> iCMS(增量版)适用于1或2台核心机器,是否描述了您的机器？你有多少核心？你可能只是想放弃那个选项
> CMS确实有单线程阶段(初始标记),这可能会伤害到你
> CMS通常比其他收藏家更喜欢堆,你的收藏家相当小

在visualgc图表添加到问题后编辑
由于你的内存受限,那么你需要充分利用你拥有的空间,唯一的方法就是通过重复的基准测试…理想情况下可重复测试.

>你可以使用-Xmn指定设置年轻代的大小,剩余部分将给予终身.
>你可能想要调整你对幸存者空间的使用,这样你就可以让它们在被交换之前变得更饱满,并让对象在它们终身之前存活更长时间

> -XX：TargetSurvivorRatio = 90设置它,因此幸存者空间在复制之前需要90％已满,显然这里需要在复制和使用空间的成本之间进行权衡
>使用-XX：PrintTenuringDistribution来显示每个空间的大小以及事物的方式,你也可以在visualgc中看到这个
>使用-XX：MaxTenuringThreshold来指定一个对象在年终集合(从1个幸存者空间复制到另一个幸存者空间)之前能够存活多少次,例如,如果你知道你只是得到了短暂的垃圾或永远存在的东西,那么把它设置为1是明智的

>您需要了解触发终身收藏的内容,并考虑采取措施以便稍后触发

>对于CMS,这可能涉及调整-XX：CMSInitiatingOccupancyFraction =< value>,设置为80,它将触发CMS 80％的终身入住率(注意：这是一个坏事,所以你可能更喜欢让热点管理这个;设置太小,它收集过于频繁的杀戮性能,设置它太大,它可能触发得太晚导致计划外的完整收集,相应的长暂停时间

>如果它真的是旧的收藏品会伤害你,你需要低停顿然后使用CMS和ParNew

最后得到一个分析器并找出垃圾来自哪里,您可能会发现更容易控制垃圾产生的速度,然后将力量投入到可以进行GC调节的黑洞中！

（编辑：李大同）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!