實時 Java 開發（二）：從 JVM 到應用層消除抖動，提升服務質量

Java 應用的延遲抖動可源自硬件、固件、OS、JVM（GC、JIT、類加載）乃至應用自身。高層難以彌補底層抖動，幸好實時 Java 在 JVM 與應用層提供了系統級工具。本文系統梳理抖動源頭與對策，並以一個簡單服務器演示調優全過程。

三大 JVM 級抖動源頭與對策

1. 垃圾收集暫停

• 分代 GC：新/舊代分離，年輕代回收快但老年代回收可能產生長尾延遲。適合「朝生夕滅」對象多、老年代穩定的場景。
• 實時 GC（如 Metronome）：增量式回收，配合應用利用率契約（默認 70%），將單次暫停壓至百微秒級。需以更大堆換取可預測性。

關鍵參數：-Xgcpolicy:metronome -Xgcthreads8 -Xmx700m -Xgc:targetUtilization=70

2. 類加載延遲

首次觸達類時觸發解析、驗證、初始化。熱點路徑外的異常類、反射生成類是常見「隱形炸彈」。

• 啟動階段預加載：Class.forName(name); clazz.getName(); 強制初始化。
• 輔助工具：-verbose:class 收集類列表，或使用 RATCAT / Real Time Application Execution Optimizer 自動化。

3. JIT 編譯暫停

JIT 異步編譯會搶佔應用線程；激進優化（如數組複製專門化）更可能導致「快慢路徑」極端分化。

• 預編譯 + 禁用 JIT：Compiler.compileClass(clazz); Compiler.disable(); 消除運行時編譯抖動，犧牲峰值吞吐。
• 實時 JVM 多策略：AOT 編譯、受控編譯、禁用重編譯等，按確定性需求選擇。

應用層：線程調度與優先級反轉

標準 Java 線程模型僅提示優先級，映射到 OS 由實現定義，無法保證搶佔式調度。RTSJ 引入 RealtimeThread / NoHeapRealtimeThread：

• 真正的固定優先級搶佔式 FIFO 調度，高優先級任務可立即搶佔低優先級。
• 需謹慎避免 Thread.yield()、自旋鎖等與 FIFO 衝突的模式。
• 配合實時 GC，將最差情況延遲從 500ms+ 壓至 20ms 以內（示例中從 542ms 降至 19ms）。

實戰演示：從 500ms 抖動到 19ms 確定性

基於 ExecutorService 的簡單服務器 + 持續產生垃圾的 GCStressThread：

1. 基線（分代 GC + JIT）：99% 在 10ms，但長尾達 542ms。
2. 預加載類 + 預編譯方法 + 禁用 JIT：抖動分佈收斂，但吞吐下降 20%。
3. 切換 Metronome 實時 GC：最大延遲降至 112ms，但抖動分佈展寬、吞吐暴跌。
4. 工作者線程改用 RealtimeThread（最高優先級 + FIFO）：最差 19ms，吞吐回升至 357 ops/s，抖動顯著改善。

代價是吞吐量下降約 40%，但換來了硬實時級的服務質量保證。

結語

實時 Java 並非銀彈，而是「確定性換吞吐」的工具箱。根據業務 SLA 選擇：軟實時可在標準 JVM 做預加載/預編譯；硬實時需實時 JVM + RTSJ 線程 + 實時 GC。核心原則：在抖動源頭攔截，而非事後補救。