簡介
從web服務到各種桌面app，各種各樣的程序都使用到了Java。根據程序的不同部署範圍，Java提供了多個垃圾收集器，每個垃圾收集器都爲不同的需求進行設計，通常情況下，Java平臺會根據程序運行的計算機類型選擇最合適的垃圾收集器。但是，這種選擇並不適用於每個應用程序，如果用戶對於程序性能有較爲嚴格的要求，則需要開發人員顯示地選擇垃圾收集器並調優某些參數，以達到所需的性能水平。
垃圾收集器（GC）是什麼？
垃圾收集器(gc)自動管理應用程序的動態內存分配需求，垃圾收集器通過以下操作執行自動動態內存管理:
1.從操作系統申請以及釋放內存
2.根據應用程序的內存請求進行內存分配
3.確定應用程序仍然在使用內存的哪些部分
4.回收未使用的內存以供應用程序重用
Java HostSpot垃圾收集器使用多種技術來提高上述操作的效率：
1.分代：新生代與老年代結合，將精力集中在堆上最有可能包含許多可回收內存的區域上
2.併發：使用多線程主動地使操作並行，或者在後臺執行一些與應用程序併發的長時間運行的操作。
3.整理：嘗試通過壓縮活動對象來恢復更大的連續空閒內存。
爲何垃圾收集器（GC）的選擇很重要？
垃圾收集器的目的是將應用程序開發人員從手動動態內存管理中解放出來。開發人員不再需要匹配分配與釋放，也不需要密切關注已分配動態內存的生存期。這完全消除了與內存管理相關的一些類型的錯誤，但代價是增加一些運行時開銷。Java HotSpot VM提供了可供選擇的垃圾收集算法。
雖然某些應用程序（大多數情況下此類應用程序規模較小）在適當頻率和持續時間的垃圾收集中擁有良好的性能。但是，對於大型應用程序，特別是那些具有大量數據(多個gb)、多個線程和高事務率的應用程序，情況並非如此。
根據Amdahl定理，大多數工作並不能完全並行化，順序執行的部分並不能從並行中獲益，目前Java平臺中，除了Serial GC，其他方案都支持並行化以提高性能，保持垃圾收集的開銷儘可能低是非常重要的。
假設有一個可以進行完美擴展的Java程序，在單處理器情況下，需要花費1%的時間進行垃圾回收（假設使用Serial GC），如果將這個程序擴展到32個處理器，那麼，根據Amdahl定理（S=1/(1-a+a/n)，a爲並行計算部分所佔比例，n爲並行處理結點個數）計算可得到S=24.42，1-(24.42/32)>23%，即程序會損失超過23%的吞吐量，當垃圾回收時間佔比越高，則吞吐量的損失越明顯，當單處理器下花費10%的時間進行垃圾回收，擴展到32處理器下，程序損失吞吐量超過75%。因此，在小型系統中可以忽略的吞吐量問題，擴展到大型系統時，反而成爲了主要的性能瓶頸，我們在這樣的瓶頸方面進行一些小的改進，能夠在程序性能上取得較大的提升，因此，在足夠大型系統中，要保證程序性能，進行GC的調優非常重要。
Serial GC通常適用於大多數小型應用程序，特別是佔堆內存100mb左右的應用程序。其他垃圾收集器由於一些專門化行爲，因此會帶來額外的開銷或複雜性。如果應用程序不需要收集器的專門行爲，則使用串行收集器。但是，在運行大量內存和兩個或更多處理器的機器上的大型、線程密集的應用程序的情況下，串行收集器可能不是最佳選擇。當應用程序在這樣的服務器上運行時，默認選擇垃圾優先(G1)收集器。