好的，我明白我应该对我的具体应用程序进行基准测试，等等等等等等，但是：
-Xmx的默认JVM设置（默认垃圾收集器等）是大多数典型Java程序的合理默认值，可能不适用于惯用的Scala代码（部分）因为惯用的Scala会产生更多的“垃圾”）。
所以我正在寻找可供选择的建议。典型的Scala程序是否需要更高的-Xmx设置？某些JVM是否比其他JVM更适合scala？对于Scala来说，一个不同的垃圾收集器（-XX：+ UseParallelGC vs XX：+ UseConcMarkSweepGC）通常比Java中通常默认的更安全/更好/更快的猜测/下注/默认值吗？是否有任何其他选项我应该特别考虑Scala代码，以及以何种方式？
由于生成了更多的临时对象，默认情况下通常是否会为“年轻”代提供更多空间？或者 less 空间通常应该给年轻一代强制更频繁的垃圾收集？其他几代呢？
当然，我仍然需要针对我的特定应用程序调整这些内容，但通常我猜测对于典型的Scala程序，我的起点可能与Java中的不同。
我确实发现自己在某些特定应用程序中遇到了内存不足错误和“GC开销限制”，或者只是让应用程序在垃圾收集暂停时花费了太多时间。在某种程度上，我可以通过调整选项来解决这些问题，但我想听听其他经历，一般原则和起点。
答案 0 :(得分：3)
这来自scala用户，纯粹基于个人经验。简而言之：我倾向于进行相当多的JVM优化，因为我发现稍微努力可以让你走很远的路，但我没有找到任何特定于scala的东西。
正如您所说，JVM默认值最多也是合理的。设置正确的堆大小，选择正确的GC，使用服务器VM，调整代数等等都会提高scala应用程序的性能，就像普通java应用程序一样。这并不是说java和scala的配置文件是相同的，只是你的实际应用程序可能会产生更大的影响。
我唯一能从理论方面考虑的事情就是新一代的规模，因为scala可能产生更多短暂的垃圾，而更大的新一代可能会帮助VM一点点。
答案 1 :(得分：2)
我发现优化Eclipse IDE的JVM和GC设置的一件事 - 较大的生成大小，意味着当它最终收集它们时会出现大的暂停。
暂停显然是交互式应用程序的一大烦恼。这里的含义是使用较大的最大值，但不会强制使用较大的最小值。
我确实比较了XX：+ UseParallelGC与XX：+ UseConcMarkSweepGC非常密集 - 但那是在以前的计算机上。我最终在那台机器上使用了XX：+ UseConcMarkSweepGC（单处理器），但对于多核机器而言，Parallel显然是要走的路。
有趣的GC调优提示：
IIRC，我确实找到了低价值＆＃39; -XX：SurvivorRatio = 2或-XX：SurvivorRatio = 3以提供显着的性能优势..我尝试的所有其他选项都没有明显的效果。