在 IBM Developer Kit for the Java 5.0 Platform（IBM SDK）中，垃圾收集（GC）可配置為四種截然不同的策略。本文作為 GC 專題兩部曲的第一部分，將詳細介紹這些策略的核心機制與適用場景。閱讀前建議具備 Java 平台垃圾收集的基礎認識，第二部分將提供量化選型方法與實戰案例。
不同的 GC 演算法各有優劣，取決於具體工作負載類型。IBM SDK 5.0 提供四種策略供開發者選擇，賦予了對應用程式行為更精細的控制權。預設策略足以應對大多數應用，若無特殊效能需求，可直接使用預設配置。但當應用追求極致吞吐量、或對 GC 停頓時間極度敏感時，深入理解並選擇適當策略便至關重要。
Java 執行期無法自動做出最佳選擇，因為難以洞察開發者的真實需求：有時優先追求高吞吐量，有時則需壓縮停頓時間以保障回應速度。
| 策略 | 啟動選項 | 核心描述 | 適用場景 |
|---|---|---|---|
| 吞吐量優化 | -Xgcpolicy:optthruput（預設） | 標記-清除-壓縮收集器，GC 期間應用完全停頓 | 吞吐量優於短暫停頓的應用 |
| 停頓時間優化 | -Xgcpolicy:optavgpause | 並發標記/掃描，在高吞吐量與短停頓間折中 | 對回應時間敏感、大堆（>3-4GB）、GUI 應用 |
| 分代並發 | -Xgcpolicy:gencon | 區分短/長生命週期物件，針對大量短命物件優化 | 大量短命物件、堆碎片化、交易型應用 |
| 子池 | -Xgcpolicy:subpool | 類似預設演算法，但採用適合多處理器的分配策略 | 16+ CPU 的 SMP 系統（僅限 pSeries/zSeries） |
建議優先使用預設策略，並在實測發現瓶頸後再評估替代方案。以下情況提示可能需要切換：
重要提醒：上述只是啟發式指引，非效能保證。所有情況下必須實測吞吐量、回應時間與 GC 停頓，第二部分將示範完整評測流程。
GC 週期包含三階段：標記（遍歷可達物件並標記）、清除（回收未標記物件至空閒列表）、壓縮（選擇性執行，將存活物件向堆首遷移消除碎片）。壓縮屬高成本操作，僅在空閒空間碎片化導致分配失敗時觸發。
所有執行緒共享連續堆區，分配需獲取全域堆鎖，多核下易成瓶頸。為緩解此問題，每個執行緒擁有專屬的執行緒分配緩存（TLH），在 TLH 內分配無需鎖。碎片化會縮小 TLH，導致頻繁爭用堆鎖——此時 gencon 或 subpool 可能是更優選擇。
設計目標為最小化停頓時間（不保證硬性上限）。透過兩大機制實現：
代價為吞吐量下降 5%-10%。灰色區域表示並發追蹤階段，Mutator 需讓出部分 CPU；藍色框為完整 GC 停頓，時間跨度遠小於 optthruput。
將堆劃分為新生代（短命物件）與老年代（長命物件），針對不同代採用不同演算法。新生代頻繁小規模 GC，老年代較少觸發並發收集。對大量短命物件的應用（如交易系統），能同時實現低停頓與高吞吐，並有效緩解碎片化。
僅支援 IBM pSeries/zSeries。堆佈局同 optthruput，但空閒列表按大小劃分為多個子池，分配請求直接從對應大小子池以原子指令彈出，免除全域堆鎖。處理器局部小堆減少快取衝突，顯著提升多核擴展性。啟動及壓縮後初期不使用子池，首次 GC 掃描階段開始填充。
IBM SDK 5.0 提供四種 GC 策略，預設策略覆蓋大多數場景。面對特定效能挑戰時，optavgpause、gencon、subpool 各有針對性優勢。關鍵在於實測驗證——第二部分將詳細演示如何科學評估與選型。
