Java 即時應用記憶體管理：從 GC 延遲到 RTSJ 解決方案

垃圾回收（GC）是 Java 自動記憶體管理的基石，但其非決定性特徵對即時系統構成嚴重挑戰。本文剖析 GC 造成的不可預測延遲問題，並探討 RTSJ（Java 即時規範）提供的替代方案與 WebLogic 實時版（WLRT）的改良策略。

核心矛盾：GC 的非決定性 vs 即時系統的硬性時限

標準 JVM 的 GC 執行過程中會遍歷堆疊，識別不可達物件並回收。此過程佔用 CPU 週期，若發生在應用程式執行期間，會導致回應時間不可預測地延長。對於要求在確定、已知延遲下執行的即時應用，這種「延遲尖峰」是不可接受的。

解決方案演進

方案一：放棄 Java（下策）

雖能規避問題，但犧牲了 Java 的跨平台、生態豐富等核心優勢，非最佳選擇。

方案二：RTSJ 引入非堆疊記憶體區域（犧牲易用性）

RTSJ 定義兩種繞過 GC 的記憶體區域：

• 不朽記憶體： JVM 存活期間永不回收，適合存放全域長期物件。
• 作用域記憶體： 以區塊為單位分配/釋放，開發者顯式建立區域存放物件，區域銷毀時一次性釋放。

代價： 記憶體管理負擔重回開發者肩上，類似 C/C++ 手動管理，易導致記憶體洩漏與崩潰，開發複雜度大增。

方案三：約束式 GC——WLRT 的實時化改良（平衡易用性與確定性）

重新審視 GC：核心問題在於「不可預測的延遲尖峰」。若能限制最大延遲時間，GC 即變為可預測、可建模的任務。

WLRT 採用更高頻率的 GC 執行策略，將每次 GC 的工作量壓縮在極小範圍內，從而將最長停頓時間控制在已知閾值內。開發者可據此進行排程分析與系統建模，且完全保留了 Java 的易用性與自動記憶體管理優勢。

總結對比

對於大多數尋求即時能力的 Java 專案，約束式 GC 提供了最佳平衡點：在不犧牲生產力的前提下，賦予系統可預測的時間行為。