积极的垃圾收集器策略

您无需提及正在运行的JVM的哪个内部版本，这是至关重要的信息。您也没有提到应用程序倾向于运行多长时间（例如，工作时间长短还是一周还是更少？）

其他几点

1. 如果您由于分配速度比年轻一代的速度快而不断泄漏对象的使用权，那么您的世代大小将不正确。您将需要对应用程序的行为进行一些适当的分析，以便能够正确调整它们的大小，您可以为此使用visualgc。
2. 吞吐量收集器旨在接受单个较大的停顿，而不是许多较小的停顿，其好处是它是紧凑的收集器，可实现更高的总吞吐量
3. CMS的存在是为了服务于频谱的另一端，即有更多得多的更小的停顿，但总吞吐量却更低。不利的一面是它没有压缩，所以碎片可能是一个问题。碎片问题在6u26中得到了改善，因此，如果您不在该版本上，则可能是升级时间。请注意，您提到的“流血到长期使用”效应加剧了碎片问题，并且在一定的时间内，这将导致升级失败（也就是计划外的完整gc和关联的STW暂停）。我以前就这个问题写过一个答案
   1. 如果运行的RAM> 4GB的64位JVM和最近使用的JVM足够多，请确保您

      -XX:+UseCompressedOops

      只是在浪费空间，因为对于没有它的相同工作负载，64位JVM的空间约为32位JVM的1.5倍（并且如果不是，请升级以访问更多RAM）

您可能还需要阅读我针对该主题写的另一个答案，该答案可以用来确定幸存者的空间并适当调整伊甸园的大小。基本上，您想要实现的是；

• 伊甸园足够大，不会经常收集
• 幸存者空间的大小与保有权期限相匹配
• 设置使用期限阈值，以尽可能确保只有真正长期存在的对象才能使用该期限

因此，假设您有一个6G堆，您可能会做类似5G eden + 16M幸存者空间+任期阈值1的 *** 作。

基本过程是

1. 分配到伊甸园
2. 伊甸园充满了
3. 活物扫向幸存者空间
4. 幸存者空间中的活对象要么复制到到空间，要么提升为保有期限（取决于保有权阈值和可用空间，并且没有将它们从1复制到另一个的次数）
5. 伊甸园里剩下的一切都被清除了

因此，如果给定的空间大小适合您的应用程序的分配配置文件，则完全有可能对系统进行配置，使其能够很好地处理负载。一些注意事项；

1. 您需要一些长时间运行的测试才能正确执行此 *** 作（例如，可能需要几天时间才能解决CMS碎片问题）
2. 您需要多次进行每次测试才能获得良好的结果
3. 您需要在GC配置中一次更改1件事
4. 您需要能够向应用程序呈现合理的可重复工作量，否则很难客观地比较不同测试运行的结果
5. 如果工作负载不可预测并且具有巨大的高峰/低谷，那么这将很难可靠地完成。

1-3点表示这可能需要一段时间才能正确。另一方面，您可能能够很快使它变得足够好，这取决于您的肛门状况！

最后，与彼得·劳里（Peter Lawrey）的观点相呼应，如果您对对象分配确实非常严格，则可以省去很多麻烦（尽管引入了其他麻烦）。