吞吐量、延迟、内存：深入理解垃圾回收的“三元悖论”

垃圾回收算法的评价标准：吞吐量、延迟、内存，孰轻孰重？
评估和选择垃圾回收器时，不存在一体通用的最优解。不同的应用场景对性能的要求截然不同，因此需要通过一套标准化的指标来衡量垃圾回收算法的特性。通常，关注三个主要的、且相互制约的评价指标：吞吐量（Throughput）、最大暂停时间（Max Pause Time / Latency）以及堆使用效率（Heap Usage Efficiency）。

吞吐量
在计算机科学领域，吞吐量泛指单位时间内完成的工作量。在垃圾回收的上下文中，吞吐量有一个更精确的定义：应用程序代码运行时间占总运行时间（应用程序代码运行时间 + GC运行时间）的比例。其公式为：

Throughput= Application Time+GC Time/Application Time

高吞吐量意味着垃圾回收占用的处理器时间片较少，应用程序能够将更多的计算资源投入到执行实际的业务逻辑中。因此，对于那些追求极致计算性能、对单次暂停不敏感的后台计算密集型任务，如科学计算、大数据批处理、ETL作业等，应优先选择以高吞吐量为目标的垃圾回收器（如Parallel GC）。这类应用的最终目标是尽快完成整个任务，即使过程中有几次较长的停顿也是可以接受的。

最大暂停时间
最大暂停时间是指垃圾回收过程中应用程序的最长停顿时间。在垃圾回收过程中，应用程序的线程可能会被暂停，以便垃圾回收线程可以找到并清理无用的对象。如果暂停时间过长，用户可能会感到应用程序卡顿或无响应。
因此，对于需要快速响应的应用程序，如用户界面、在线交易系统或实时系统，应选择最大暂停时间短的垃圾回收算法。例如，一些并发和增量垃圾回收算法就是通过牺牲一部分吞吐量来降低最大暂停时间。
最大暂停时间，也常被称为延迟（Latency），是指在整个垃圾回收周期中，由“Stop-the-world”导致的应用程序最长的一次停顿时间。在STW期间，所有应用线程都会被完全冻结，无法响应任何外部请求或执行任何任务。这种暂停会直接影响应用的响应性。如果暂停时间过长，用户可能会感到界面卡顿、请求超时或系统无响应，这在交互式应用中是致命的。
因此，对于需要与用户实时交互或对响应时间有严格要求的应用，如Web服务器、在线交易系统、微服务网关，控制最大暂停时间是首要目标。开发者会选择那些旨在缩短停顿时间的垃圾回收器，例如CMS、G1，乃至以超低延迟为目标的ZGC和Shenandoah。

堆使用效率
堆使用效率衡量的是垃圾回收算法对Java堆内存的利用情况。一个高效率的垃圾回收算法，可以用更少的内存空间来支撑同样规模的应用运行，或者说，在给定的堆大小下，留给应用程序自由分配的“净空间”更大。
影响堆使用效率的因素主要有两个方面：
1）垃圾回收自身的数据结构开销：例如，G1需要使用记忆集（Remembered Sets）来记录跨区引用，这会占用一部分堆内存。
2）堆的碎片化程度：一些不带压缩整理阶段的垃圾回收算法（如CMS）会产生大量内存碎片，导致虽然总的空闲内存很多，但没有足够大的连续空间来分配一个大对象，从而提前触发Full GC。
提高堆使用效率通常也需要付出代价。例如，为了进行空间整理以消除碎片，垃圾回收器需要移动大量对象，这会增加处理器的消耗和暂停时间。总的来说，堆使用效率、吞吐量和最大暂停时间构成了一个“不可能三角”，无法同时将三者都优化到极致。
一个简单的经验法则是：更大的堆内存通常能带来更短的垃圾回收时间和更高的吞吐量，因为垃圾回收可以降低运行频率，且有更多空间进行对象腾挪；反之，若要在有限的堆内存下运行，垃圾回收必然会更加频繁和耗时，从而影响吞吐量和延迟。

未完待续

很高兴与你相遇！如果你喜欢本文内容，记得关注哦