從臺式機上的小applet到大型服務器上的web服務，各種應用程序都使用Java。爲了支持這種不同範圍的部署，滿足不同的要求，JVM提供了多個垃圾收集器。這是滿足大型和小型應用程序需求的一個重要部分。Java SE根據運行應用程序的計算機選擇最合適的垃圾收集器。然而，這種選擇可能不是對每個應用程序都是最優的。
具有嚴格性能目標或其他需求的用戶、開發人員和管理員可能需要顯式地選擇垃圾收集器，並調優某些參數，以實現所需的性能級別。本文檔提供了幫助完成這些任務的信息。首先，在本系列的上下文中描述了垃圾收集器的一般特性和基本調優選項，stop-the-world收集器。然後給出了其他收集器的具體特性以及選擇收集器時要考慮的因素。
垃圾收集器就是一個內存管理工具，通過以下操作實現自動內存管理：
- 將對象分配給年輕代，並將老的對象提升到老年代。
- 通過併發(並行)標記階段在老年代中找到活動對象。當JVM中Java堆佔用總量超過默認閾值時觸發標記階段。請參閱CMS和G1。
- 通過並行複製壓縮活動對象來恢復空閒內存。請參閱並行收集器和G1。
什麼時候垃圾收集器的選擇很重要？對於一些應用，答案是永遠都不重要。也就是說，應用程序可以在存在垃圾收集的情況下正常運行，暫停的頻率和持續時間都不高。但是，對於大型應用程序，特別是具有大量數據(幾個gb)、多線程和高事務率的應用程序，情況就不一樣了。
Amdahl定律（給定問題的並行加速受問題的順序部分的限制）意味着大多數工作負載不能完全並行化;有些部分總是順序的，並不會從並行中獲益。對於Java平臺也是如此。特別是，針對Java SE 1.4之前的Java平臺的Oracle虛擬機不支持並行垃圾收集，因此與其他並行應用程序相比，垃圾收集對多處理器系統的影響越來越大。
圖1-1"比較垃圾收集花費時間百分比"爲一個理想的系統建模，該系統除了垃圾收集（GC）之外是完全可伸縮的。紅線是一個應用程序在單處理器系統上只花費1%的時間進行垃圾收集。這意味着32個處理器的系統的吞吐量損失超過20%。洋紅色的線顯示，對於垃圾收集時間佔10%的應用程序（在單處理器應用程序中垃圾收集的時間不算多），當擴展到32個處理器時，超過75%的吞吐量會丟失。
這表明，當在小型系統上開發時，可以忽略的速度問題可能會成爲擴展到大型系統時的主要瓶頸。然而，在減少這種瓶頸方面的小的改進可以在性能上產生很大的提高。對於足夠大的系統，選擇正確的垃圾收集器並在必要時對其進行調優是值得的。
串行收集器通常適用於大多數“小型”應用程序（在現代處理器上，這些應用程序需要高達100 MB的堆）。其他收集器有額外的開銷或複雜性，這是專門化行爲的代價。如果應用程序不需要特殊行爲的收集器，則使用串行收集器。串行收集器在具有大量內存和兩個或更多處理器的機器上運行的大型、多線程的應用程序中使用不被認爲是最佳選擇。當應用程序在這樣的服務器機器上運行時，默認情況下選擇並行收集器。參見人機工程學。
本文檔是使用Solaris操作系統（SPARC平臺版）上的Java SE 8作爲參考開發的。但是，這裏提出的概念和建議適用於所有受支持的平臺，包括Linux、Microsoft Windows、Solaris操作系統（x64平臺版）和OS X。此外，上面提到的命令行選項在所有受支持的平臺上都是可用的，儘管某些選項的默認值在每個平臺上可能不同。