有没有人发现垃圾收集调整很有用？答案

【问题标题】：Has anyone found Garbage Collection tuning to be useful?有没有人发现垃圾收集调整很有用？
【发布时间】：2010-10-12 01:21:37
【问题描述】：

我阅读了大量关于在 Java 中调整 GC 的文章，并且经常想知道有多少人真正使用了一些更高级的功能。

我总是尽可能避免调整，而是专注于编写尽可能简单的代码（Brian Goetz 的建议）——到目前为止，这似乎对我来说效果很好。

这些调优策略是否能够适应不同 VM 版本的变化，还是需要不断重新评估？

我使用的一个调整是 -server 标志。

【问题讨论】：

请注意，如果您实际部署在服务器上，通常不需要 -server 标志。 JVM 会检测它运行在什么样的环境中
这在 Windows 上不起作用。不过，它确实适用于 Linux 和 Solaris。大多数 Windows 机器都超过了标准的服务器要求。据推测，它们将用于客户使用。

标签： java garbage-collection performance

【解决方案1】：

我目前的部分工作是维护和提供一个大型 Java 应用程序，该应用程序设计为使用大量内存（目前约为 8 Gb）运行，主要是由于正在进行大量缓存数据的计算。我使用标准 GC 设置进行了初始部署，主要是因为没有简单的方法来模拟全速运行的生产环境。

在接下来的几个月中，我分阶段自定义了 GC 设置。一般来说，最大的可用旋钮似乎是调整增量 gc 的频率和幅度 - 最大的改进是用较大的周期性 gc 换取更小和更频繁的 gc。但我们肯定能够看到性能改进。

我不会发布我的具体设置，因为 a) 它们特定于我们的设置，b) 因为我手边没有它们 :)。但总的来说，我发现的是

在调整默认 gc 设置。几乎默认设置总是比我做的任何调整都好。
至少对我来说， gc 调优实际上是值得的已经够极端了不合理地试图模拟他们，所以我不得不这样做实验性和渐进性。

Here's 上一个很好的参考。 stackoverflow 讨论。

【讨论】：

【解决方案2】：

绝大多数开发人员将永远不必（或想要）调整 GC。我曾与不得不调整它的人一起工作，这里是建议：

在尝试调整垃圾之前收藏家 100% 确定你有已验证，使用探查器。什么是继续。一旦你开始调整确保您使用探查器验证它产生了积极的影响。

您还应该重新审视您运行的每个版本的 VM 所做的更改（不同的 VM 将有不同的调整策略）。

我曾经帮助过一个 GC 问题的人，结果证明他们没有关闭 JDBC 结果集（或类似的问题）。这导致内存永远不会被释放（他的代码出于某种原因保留在它们上面）。解决该问题使程序从 20 分钟缩短到 30 秒或几分钟。内存使用率也下降了很多。

【讨论】：

这就是我所关心的。每当 JVM 发布时，甚至在整个开发周期中定期检查，任何调优策略都需要检查——这就是我避免调优的原因。
VM 是不稳定的，他们在每次发布时都会对 GC 进行更改/改进，所以当你听到它们时，即使是关于性能改进的“都市传说”也可能是错误的……总是把你的代码写得干净而且我可能会足够快，否则会更容易加快速度。

【解决方案3】：

我不得不说，我自己并没有太多需要使用调优。但我与编写延迟至关重要的代码的人密切合作：他们大量使用这种调整 - 指定要使用的 GC 算法、最大暂停时间、幸存率等。

因此我猜答案是：如果延迟对应用程序至关重要，您可能需要考虑调整 GC

【讨论】：

【解决方案4】：

我想说最常见的调整是最大内存大小。大多数其他内存选项都有合理的默认值，并且经常过度调整恕我直言。即当它真的没有太大区别时设置。我经常看到人们设置了很多选项，而其中一半是默认选项。 ;)

使用分析器是改善 GC 行为最有用的方法（通过减少创建的对象数量）

【讨论】：

我不确定大多数人是否会将 Xmx 参数设置为“调整”GC。
我有点不同意。如果您有一个繁忙的盒子并分配了太多内存 - 这可能会导致盒子交换内存过多。
好点，使用 -mx 可能不被视为 GC 调整，但它通常是您唯一需要做对的事情。正如@Fortyrunner 指出的那样，您不希望它太大或太小。如果可以的话，我发现你不希望 JVM 使用多个内存库。

【解决方案5】：

我有，但最近没有。我正在开发的应用程序是实时渲染由单个运动 JPEG 图像构成的视频流。当时（大约 JDK 1.2 和 1.3），-Xincgc 设置会将客户端垃圾收集器从更多的大爆炸式清理切换到定期清理一些垃圾的模式。因此，帧延迟的分布要低得多，给人的印象是视频更流畅（而不是 1-2-3-pause，1-2-3-pause）。

我已经很长时间没有查看该代码了，但我强烈怀疑，使用现代垃圾收集算法，-Xincgc 实际上会降低性能。

在当今世界，我想说标准优化怀疑论应该始终适用：profile profile profile。你确定瓶颈真的是垃圾收集器吗……？

【讨论】：

它可能确实会降低整体性能，但它仍然可以大大改善延迟。例如，C++ shared_ptr 引用计数可能比 Java GC 慢，但整体效果平滑得多。
@Zan，我想我不明白你的评论。我说的是 -Xincgc 现在太天真了。现代 GC 有更多有用的选项。我什至不认为 -Xincgc 会在没有测试的情况下导致更平滑的延迟。
我评论的重点是，持续进行小规模清理可能会使应用程序运行时间更长，但使用起来会更愉快（如果应用程序是用户交互的）。
@Zan，是的，这绝对是真的。也就是说，我认为使用现代 GC 算法，您会发现比旧的 -Xincgc 运行更快的更流畅的性能。

【解决方案6】：

简而言之，是的，它对于调优任何严肃的 Java 应用程序都非常有用。我们经常发现，在生产场景中，稳定的应用程序和完全不可预测的应用程序之间存在差异。这当然不是我做的第一件事，但是一旦你的应用程序可以工作并且可以对其施加真正的负载，这是当时首先要调查的事情之一。

【讨论】：