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