狀態物件：Java 系統中被忽視的核心概念

為什麼狀態比資料庫更重要？

許多開發者習慣將「資料庫資料」等同於「系統狀態」。實則不然：

• 持久化狀態：資料庫、檔案中靜止的資料快照。
• 活動狀態物件：JVM 記憶體中、隨業務流程變化的領域模型實例。

系統運行時主要操作的是活動狀態。若直接以資料庫取代記憶體狀態，會導致頻繁 I/O、破壞物件封裝、產生貧血模型，系統退化為傳統兩層架構。

狀態的三大生命週期

Session 狀態管理：惡魔藏在細節

常見災難

• 將大量資料庫查詢結果塞入 Session，併發用戶暴增 → Heap 爆滿 → Full GC 風暴 → 系統凍結。
• Session 逾時設定過長 (預設 30 分鐘)，無用物件長期佔用記憶體。
• 叢集環境 Session 複製頻寬壓力大。

最佳實務

1. 能用 Request 就不用 Session：縮短生命週期，降低 GC 壓力。
2. 共享唯讀資料放 Application 快取：搭配 OsCache、Ehcache、Redis 等快取中介軟體，支援 LRU 淘汰、分散式同步。
3. 手動管理 Session 物件：設定容量上限、定期清理、閒置序列化至磁碟。
4. 避免在 Singleton/Static 欄位持有狀態：多執行緒併發寫入極難控制，J2EE 禁忌。

快取中間層：Application 狀態的專業化

• 單機：OsCache、Ehcache 配置於 web.xml 或程式碼初始化。
• 叢集：JBoss Cache (現 Infinispan)、Terracotta、Redis、Hazelcast 提供分散式快取一致性。
• 關鍵挑戰：快取鍵值設計、失效策略 (TTL/事件驅動)、資料庫同步 (Write-through/Write-behind)。

框架級解決方案：Jdon Framework

領域模型類別實作特定介面/繼承基類，框架自動攔截持久化操作，透明整合快取：

// 領域模型
public class Forum extends DomainModel {
    private String name;
    private String description;
    // 狀態欄位：最新貼文、貼文數 — 生命週期短、變動頻繁
    private Post latestPost;
    private int postCount;
}

框架基於 IoC/AOP，底層快取實作可熱插拔 (OsCache → Redis)，業務碼零侵入。

狀態建模的難點：屬性 vs 狀態

Forum 範例：

• 屬性 (靜態)：名稱、描述 — 隨論壇生命週期同存亡。
• 狀態 (動態)：最新貼文、貼文數 — 高頻變更、可獨立快取、甚至可由不同服務維護。

分離依據：生存週期不同。不熟悉業務領域時，難以精準切分。MDA 四色原型 (Archetype) 可輔助識別：Moment-Interval (粉紅) 代表業務事件產生的臨時狀態。

中介軟體演進：EJB → Spring → Jdon

結語

掌握狀態的生命週期、併發特性、快取策略，是從「寫 CRUD」進化為「設計領域模型」的分水嶺。框架能簡化管道，但狀態建模的決策永遠屬於架構師。