gc 吞吐量和停顿时间

每个Java应用程序都必须解决的一种类型的问题与垃圾回收有关。 当垃圾收集器工作时，它代表了一项奇妙的发明。 如果不是这样，或者GC做家务的方式变得不可预测，那么您就有一个朋友变成了敌人。

这篇文章是关于垃圾收集暂停时间的。 或更准确地说-为什么您要关心停顿。

之前，我曾通过苹果首席执行官蒂姆·库克 （ Tim Cook）先生针对iPad需求进行规划并建立工厂来解释吞吐量和延迟 。 我将坚持同样的说明性故事：

• 我们有一条工厂线，每秒生产一台iPad。 每秒，每秒。 因此，该生产线的吞吐量为每天86,400个iPad
• 从完成外壳成型的一开始到完成iPad的验收测试，整个过程需要四个小时。 因此，该线路的等待时间为四个小时 。

上面的系统和计算是基于这样的假设，即工厂生产线每天每天24小时都在运行。 但是所有工厂生产线都需要维护，这相当于在JVM内部运行垃圾回收。

举个例子–让我们承担一些小的维护任务，这些任务可以处理而不会造成很多干扰。 例如，可以在机器中加油或从成型设备旁边的地板上捡拾多余的垃圾。 这些操作与JVM中的次要GC相似–它是您必须处理的维护，但是实现非常聪明，以至于不会影响系统性能。

但是在同一个工厂里 蒂姆·库克（Tim Cook）也将面临长期的维护任务。 这些任务涉及停止整个生产线，并且等效于Full GC运行，在JVM中，JVM需要停止服务线程以执行一些重要的内部管理任务。

现在，让我们假设经过数月不间断的服务后，我们假设的工厂生产线被堵塞，技术团队需要四个小时才能解决问题。 在此期间，线路停止。 我们如何衡量效果？ 与往常一样，可以通过两种不同的方式来衡量影响：

• 对吞吐量的影响 。 四个小时的停止表示我们有14,400秒的时间没有完成iPad。 就吞吐量而言，这意味着我们已将这一天的系统容量从86,400减少至72,000。 这意味着吞吐量损失约16.5％ 。
• 对延迟的影响 。 现在，如果我们拿着一台在中断发生时仍在生产中的iPad，则完成该过程所花的时间不是四个，而是八个小时。 这表示最坏情况下的延迟增加了100％ 。

如果您还记得，那么先生。 库克并不关心延迟 。 对他来说重要的是较长时间内的总吞吐量，所以先生。 Cook将决定以使其对生产量的影响最小的方式优化其流程。

在软件开发中也需要做出类似的决定。 如果您有负责订单处理的Java EE应用程序，则GC暂停四秒钟将肯定会降低系统的吞吐量。 但是对于我们大多数人来说，这将不是主要问题。 另一方面，试图在四秒钟内停止执行清理任务的用户试图完成任务的用户会感到我们的系统很慢。 并且，运营一种被用户视为迟钝的服务是一种倒闭的好方法。

故事的士气？ 明智地选择目标，并确保不要将吞吐量与延迟混淆。 然后，通过监视GC日志，查找意外的完整GC并调整您的应用程序和/或GC来最大程度地减少影响，以确保您了解GC对这两个方面的影响。

翻译自: https://www.javacodegeeks.com/2014/01/gc-impact-on-throughput-and-latency.html

gc 吞吐量和停顿时间