为Java音频应用程序调整GC

您提供的日志太小，无法提供真实的分析结果，但它说，由于旧发电机已基本满，它花了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调整的黑洞中！