GC 调优的观察

​      大多数回收器的垃圾回收调优都很难做到一定正确，即使你理解了应用程序的特性。下 图显示了 HotSpot JVM 中 CMS 回收器的两组调优参数。虽然它们可能使用相似的参数，但 它们是非常不同的，甚至在某些领域是完全相反的。然而，应用程序的性能可以通过任意一 种设置进行优化，这取决于其特定的特性。对于大多数垃圾回收器来说，没有“一刀切”的 答案存在。开发人员和架构师必须仔细调优，并在每次应用程序、环境或预期的负载变化时 重新调优。错误地获取这些参数可能会在峰值负载时间导致意外的长时间暂停。然而，Azul Zing C4 上运行的应用程序性能“通常”对调整参数不敏感，因为它在年轻代和年老代中都 是并行标记和压缩的，所以唯一重要的参数是堆大小。

       当你在 Zing 运行时中设置堆大小时，C4 回收器自动计算它需要的 GC 时间，以跟上分 配率，不需要设置 GC 期望时间，Zing 的 C4 GC 将在需要时使用与应用程序线程分离的线程 工作，与其他 GC 策略相比，这允许将最坏情况下的暂停时间降低几个数量级。随着 GC 的 退出，到线程安全点的时间将成为下一个主要的延迟来源，当然我们可以使用其他方式来实 现更低的延迟，通常通过操作系统或者通过 JIT 编译器在 JVM 中调整。