垃圾收集器選型因素

• 應用程序的主要關注點是什麼？如果是數據分析、科學計算類的任務，目標是儘快算出結果，那吞吐量就是主要關注點；如果是SLA應用，那停頓時間直接影響服務質量，嚴重的甚至會導致事物超時，這樣延遲就是主要的關注點；而如果是客户端應用或者嵌入式應用，那垃圾收集的內存佔用則是側重點。
• 運行應用的基礎設施如何？譬如硬件規格，要設計的系統時x86-32/64、SPARC還是ARM/Aarch64;處理器的數量是多少，分配的內存大小；選擇的操作系統是Linux、Solaris還是Windos等。
• 使用的JDK的發行版是什麼？版本號是多少？是ZingJDK/Zulu、OracleJDK、OpenJDK、OpenJ9抑或是其他公司的發行版？該JDK對應了《Java虛擬機規範》的哪個版本？

一般來説收集器的選擇就從以上幾點考慮，舉個例子，假設某個直接面向用户提供服務的B/S系統準備選擇垃圾收集器，一般來説延遲時間是這類應用的主要關注點，那麼：

• 如果你有充足的預算單沒有太多調優經驗，那麼一套代商業技術支持的專有硬件或者軟件解決方案是不錯的選擇，Azul公司以前主推的Vega系統和現在主推的Zing VM是這方面的代表，這樣你就可以使用傳説中的C4收集器了。
• 如果你雖然沒有足夠預算去使用商業解決方案，但能夠掌控軟硬件型號，使用較新的版本，同時又特別注重延遲，那ZGC很值得嘗試。
• 如果你對還處於試驗狀態的收集器的穩定性有所顧慮，或者應用必須運行在Windos操作系統下，那ZGC就無緣了，試試Shenandoah吧。
• 如果你接手的是遺留系統，軟硬件基礎設施和JDK版本都比較落後，那就根據內存規模衡量一下，對於大概4GB到6GB以下的堆內存，CMS一般能處理的比較好，而對於更大的堆內存，可重點考察一下G1。