垃圾回收算法的評價標準：吞吐量、延遲、內存，孰輕孰重？
評估和選擇垃圾回收器時，不存在一體通用的最優解。不同的應用場景對性能的要求截然不同，因此需要通過一套標準化的指標來衡量垃圾回收算法的特性。通常，關注三個主要的、且相互制約的評價指標：吞吐量（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。
提高堆使用效率通常也需要付出代價。例如，為了進行空間整理以消除碎片，垃圾回收器需要移動大量對象，這會增加處理器的消耗和暫停時間。總的來説，堆使用效率、吞吐量和最大暫停時間構成了一個“不可能三角”，無法同時將三者都優化到極致。
一個簡單的經驗法則是：更大的堆內存通常能帶來更短的垃圾回收時間和更高的吞吐量，因為垃圾回收可以降低運行頻率，且有更多空間進行對象騰挪；反之，若要在有限的堆內存下運行，垃圾回收必然會更加頻繁和耗時，從而影響吞吐量和延遲。

未完待續

很高興與你相遇！如果你喜歡本文內容，記得關注哦