原文网址：https://plumbr.eu/blog/gc-impact-on-throughput-and-latency
译文网址：http://blog.dontcareabout.us/2014/03/gc-throughput.html
BBS 版以 markdown 语法撰写
______________________________________________________________________
有一类问题是每一个 Java application 都会遇到的，那就是 GC。
当 GC 正常运作时，它是一个美妙的发明；
当它没有运作、或是 GC 用出乎意料的方式运作，
那你的朋友就会翻脸变成仇人。
这篇文章是关于 GC 造成的暂停时间。
或著更精确地说：为什么你要在意这些暂停时间？
前几篇文章，我用 Apple CEO [Tim Cook] 针对 iPad 需求与建厂的规划，
来[解释 throughput 与延迟时间][T and L]。
这里我将沿用同一个例子：
* 我们有一个生产线每秒可以制造一台 iPad。
所以**这条生产线的 throughput 是每天 86400 台 iPad**。
* 从外壳成型开始到验收测试结束，一台 iPad 需要 4 小时的时间。
所以**这条生产线的延迟时间是 4 个小时**。
上述系统以及计算结果，是假设生产线每天不间断地运作 24 小时。
但是所有生产线都需要保养，对应到 JVM 就是执行 GC。
举例来说，作小型保养可以在不怎么中断制程的情况下处理完毕；
可能是帮机器上油、或是把塑模设备旁边地板的垃圾捡起来。
这些操作行为跟 JVM 中的 minor GC 相似，你必须作这些维护。
不过，因为实作写得太聪明，所以对系统效能来说没什么影响。
跟 Tim Cook 一样，还是得面对长时间的维护任务。
这些任务得停止整个生产线，
相当于执行 full GC 时 JVM 需要暂停 thread 以作一些整理的工作。
现在假设在几个月不间断的服务之后，
我们想像中的生产线卡住了，
技术团队需要 4 个小时才能解决问题，
这段时间生产线是停止的。
我们要如何计算影响程度？
一如往常，影响程度可以从两个不同面相去评估：
* **throughput 的影响**：
停机的这 4 个小时代表有 14400 秒没办法做出 iPad。
以 throughput 来看，在这特定的一天当中，
系统的产能会从 86400 降到 72000。
这代表 **throughput 损失了约 16.5%**。
* **延迟时间的影响**：
如果一台 iPad 在中断作业的时候仍然在生产线上，
则它的完成时间会长达 8 个小时而不是 4 个小时。
这表示**在最坏的情况下延迟时间增加了 100%**。
如果你还记得，其实 Cook [并不在意延迟时间][T and L]。
对他而言，重点在于长时间区段内的整体 throughput。
所以 Cook 决定以尽可能不影响 throughput 的方式来调整生产流程。
软件开发也需要做出类似的决定。
如果你有负责处理订单的 Java EE application，
那么 GC 暂停超过 4 秒，肯定会降低系统的 throughput。
但对大多数的人而言，这不是主要议题。
另一方面，试图在清理空间的这四秒钟内作某些事情的使用者，
会觉得我们的系统很迟钝。
让使用者觉得服务操作起来很迟钝，这是商业软件的大忌。
这个故事告诉我们什么？
明智地选择你的目标，
并且确定你有搞清楚 throughput 跟延迟时间的区别。
然后确保你了解 GC 的影响，
无论是监看 GC 的 log 或是找寻意料外的 full GC 动作，
并且调整 application 以及 GC 来将影响降到最低。
如果你看到这边，那我还有一个有趣的故事。
请看我们的[旧文章]，并考虑关注[我们的 Twitter]。
[Tim Cook]: http://en.wikipedia.org/wiki/Tim_Cook
[T and L]: https://plumbr.eu/blog/
throughput-and-latency-performance-tuning-made-simple
[旧文章]: https://plumbr.eu/blog
[我们的 Twitter]: https://twitter.com/intent/
follow?region=follow_link&screen_name=javaplumbr