Question

我注意到在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分配，因为staring /暂停音频不会更改GC图表。这是visualgc与并行gc一起显示的内容： alt text

图表在启动时开始，我开始播放。标记是

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

谢谢。

Answer 1

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

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

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

我会马上做的事情;

更改您的日志记录，以便您输出可由脚本轻松解析的单行（可能是启动时间，结束时间，持续时间）
添加PrintGCApplicationStoppedTime和PrintGCApplicationConcurrentTime开关，以便您获得每次 STW暂停的记录，而不仅仅是GC事件
使用最新的JVM（即6u23），因为在过去的一两年里，热点已经有了很多改进，所以使用较旧的一个
你没有说你是否受内存限制，但如果可以，我肯定会增加堆大小，40M非常小，所以你没有足够的空间可以玩
运行连接visualgc的应用，可以更全面地了解IMO的内容，因为您一次拥有所有不同的观看次数

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

要记住的其他一些事情......

iCMS（增量版）适用于1或2台核心机器，是否描述了您的机器？你有多少核心？你可能只想删除该选项
CMS确实有一个单线程阶段（init标记），这可能会伤害你
CMS通常比其他收藏家更喜欢堆，你的收藏很小

将visualgc图表添加到问题后进行修改由于你的内存受限，你需要充分利用你拥有的空间，唯一的方法就是通过重复的基准测试...理想情况下可以通过可重复的测试。

您可以使用-Xmn指定设定年轻一代的规模，剩余部分将用于终身。
你可能想调整你对幸存者空间的使用，这样你就可以让它们在被交换之前变得更饱满，并让对象在它们终身前更长时间存在
- -XX:TargetSurvivorRatio=90设置它以便幸存者空间在复制之前需要90％满，显然这里需要在复制和使用空间的成本之间进行权衡
- 使用-XX:+PrintTenuringDistribution显示每个空间的大小以及具体情况，您也可以在visualgc中看到这一点
- 使用-XX:+MaxTenuringThreshold来指定一个对象在年轻集合（从1个幸存者空间复制到另一个幸存者空间）之前能够存活多少次，例如，如果你知道你只得到短暂的垃圾或永远存在的东西，那么把它设置为1是明智的
您需要了解触发终身收藏的内容，并考虑采取措施以便稍后触发
- 对于CMS，这可能涉及调整-XX:CMSInitiatingOccupancyFraction=<value>，例如设置为80，它将触发CMS 80％的终身入住率（注意：这是一个坏事，所以你可能更喜欢让热点管理这个;设置太小，它收集过于频繁的杀戮性能，设置它太大了，它可能触发得太晚导致计划外的完整收集，并有相应长的暂停时间
如果真的是旧的收藏品会伤到你，你需要低停顿然后使用CMS和ParNew

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

Answer 2

这意味着太多的对象被提升出伊甸园空间，因为主要的GC不应该处理太多。您可以使用-XX：NewRatio增加给予新一代的空间比率。试试10然后向上移动更好的是，研究如何减少程序中对象的引用范围。

Answer 3

好的，简而言之，您对未指定满足此要求的系统有非功能性要求。 “正确”的答案是使用实时能力的JVM实现。但大多数都很昂贵，我认为你会接受99.9％的正确解决方案。

首先想一想，你应该做的是找到一种方法来衡量这种中断。否则，任何比较不同垃圾收集器的实验都注定不可靠。

在这个介绍声明之后，让我们来解决你的问题：

你说垃圾收集器在声音播放中引入了暂停。您的选择是：

使用更合适的选项改进垃圾收集器。
产生更少的垃圾。
定期调用垃圾收集器，但这可能会导致相反的效果。你必须衡量！
使用延迟隐藏技术来减少垃圾收集器引起的暂停的影响。

结束：如果你真的想摆脱这个问题，（1）找到一种方法来衡量它，（2）做实验，（3）找到根本原因，（4）解决根本原因，（5）衡量你真的解决了它。

Answer 4

我知道这是一个老问题，OP可能甚至不再感兴趣了，但这些线路在他的配置中让我感到困扰：

-XX:MaxHeapFreeRatio=10
-XX:MinHeapFreeRatio=10

对我而言，这意味着他的VM将尝试从系统中不断地请求内存或释放它 - 我非常确定这两个数字之间必须存在差距。

此外，对于其他任何尝试使用实时java系统的人来说，诀窍是预先分配所有对象，然后再分配任何其他对象。

这可能很棘手，但是远远不是不可能 - 打开-verbose：gc并且只删除“新”和其他分配内存的东西，直到你根本看不到任何gcs。

在GUI中，顺便说一下，这意味着预先创建所有GUI元素，永远不会释放它们，只是隐藏和显示。它也意味着没有字符串操作（仅使用StringBuffers和字符串常量 - 这是最难解决的问题，因为很多系统调用都依赖于字符串）

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

4 个答案: