每个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