JAVA 調優有一部分工作就是減少GC對系統的影響，主要從以下幾個方面：

• FULL GC頻繁執行
• FULL GC執行導致系統停頓

針對上面這兩個問題，從垃圾回收器選擇，垃圾回收引數調整兩方面進行JVM調優。本文只說明從JVM的引數方面的調優，程式碼的優化也減少上面的問題，有時起到更佳效果。

一、垃圾收集器選擇

現代 JVM 的 型別 繁多， 最 主流 的 四個 垃圾 收集 器 分別 是： Serial 收集 器（ 常 用於 單 CPU 環境）、 Throughput（ 或者 Parallel） 收集 器、 Concurrent 收集 器（併發環境下，且堆記憶體不大情況下使用） 和 G1 收集 器（堆記憶體大的情況下使用）。

• 所有 的 GC 演算法 都將 堆 劃分 成了 老 年代 和 新生代。 
• 所有 的 GC 演算法 在 清理新生代物件時， 都使用 了“ 時空 停頓”（ stop- the- world） 方式的垃圾收集方法， 通常此過程較快。

GC 演算法 的 選擇一方面取決於應用程式的特徵， 另一方面取決於應用的效能目標。

1、當進行批量任務或關注程式吞吐量時，一句話總結：CPU夠用時，Concurrent 收集器效果更好。

• 使用 Throughput 收集器處理應用程式執行緒的批量任務能最大程度地利用 CPU 的處理能力， 通常能獲得更好的效能。
•  如果批量任務並沒有使用機器上所有可用的CPU 資源， 那麼 切換 到 Concurrent 收集器往往能取得更好的效能。

2、當關注相應時間時，需要進行效能測試才能得出結論，但一般情況下，CPU夠用時，Concurrent 收集器效果更好。

• 選擇 Concurrent 收集器時， 如果堆較小， 推薦使用CMS 收集 器。
• G1的設計使得它能夠在不同的分割槽（ Region） 處理堆， 因此它的擴充套件性更好， 比 CMS更易於處理超大堆的情況。

二、堆大小調整

• 執行的所有JVM例項的堆記憶體和不要超過實體記憶體，超過會進行記憶體頁切換，降級效能。
• 經驗值為每次GC回收可以回收掉70%的記憶體。設定方法：-Xms=初始大小  -Xmx=最大值 。

• 通常情況下， 我們應該開啟自適應調整， 因為垃圾回收演算法依賴於調整 後的代的大小來達到它停頓時間的效能目標。

三、併發控制

• 1. 幾乎所有的垃圾收集演算法中基本的垃圾回收執行緒數都依據機器上的CPU數目計算得出。
• 2. 多個JVM 運行於同一臺物理機上時， 依據公式計算出的執行緒數可能過高， 必須進行優化（ 減少）。比如16CPU的機器，執行4個JVM, 可以控制每個JVM的並行GC執行緒為4。-XX ParallelGCThreads=N來控制。