为Java音频应用程序调整GC

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字节=〜92ms），广告在运行Full 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）我打开窗户，然后重新开始播放。

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

谢谢。

Answer 1

您提供的日志太小，无法提供真实的分析结果，但它说，由于旧发电机已基本满，它花了200毫秒完成了很少的时间。这意味着您的堆太小或发生内存泄漏。在这种情况下，您没有太多可以调整GC算法的操作。因此，本回复的其余部分是关于如何在消除内存泄漏或拥有更大堆之后如何从应用程序中获取更多信息和/或如何调整GC。

在很大程度上，低停顿意味着您将竭尽所能将这些收藏仅保留为年轻收藏。

您确实确实需要在开始和结束编写时准确记录日志，然后将其与该时间段内JVM中发生的STW暂停相关联，否则您真的不知道是什么引起了问题或问题的严重程度。

我会立即做的事情；

1. 更改日志记录，以便输出可轻松由脚本解析的一行（可能是开始时间，结束时间，持续时间）
2. 添加PrintGCApplicationStoppedTime和PrintGCApplicationConcurrentTime开关，以便获得每个STW暂停的记录，而不仅仅是GC事件
3. 使用最新的JVM（即6u23），因为过去一两年对热点进行了很多改进，因此使用较旧的JVM会有所帮助
4. 您不会说如果内存有限，但如果可以的话，我肯定会增加堆大小，因为40M很小，所以您没有足够的空间玩
5. 在连接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，它将以占用率80％的占用率触发CMS（注意：这是一件很容易出错的事情，因此，您可能宁愿让热点管理此问题；将其设置得太小且设置不正确收集频率过高会导致性能下降，将其设置得过大，可能触发得太晚，导致计划外的完整收集以及相应的暂停时间较长
• 如果确实是旧的集合对您造成了伤害，并且您需要低暂停，那么请使用CMS和ParNew
  最后，获得一个探查器并弄清垃圾的来源，您可能会发现控制垃圾产生的速度更容易，然后将精力投入可以进行GC调整的黑洞中！