程式設計面試題：Java 25 StableValue 如何設計安全的一次性初始化？
題幹與適用場景
你維護一個高併發服務，需要延遲建立昂貴且只允許成功發布一次的設定物件。請使用 Java 25 的 StableValue 設計初始化方案，並說明併發、例外、可觀測性、預覽特性與回滾邊界。題目適合考察 Java 併發、JMM 發布語義和現代 JDK API 判斷力。
面試官考察點
- 能否準確說明 StableValue 是 Java SE 25 的 preview API，而非已穩定承諾的長期介面。
- 能否區分「容器只寫一次」和「容器內物件不可變」。
- 能否解釋
orElseSet、trySet、setOrThrow、orElseThrow的失敗與重試語義。 - 能否處理初始化例外、競爭初始化、關閉和升級風險。
回答前需要釐清的問題
- 初始化失敗後是否允許再次嘗試，還是第一次失敗就熔斷？
- 資源建立是否有副作用，競爭執行緒是否必須等待同一個結果？
- 目標執行時期是否能啟用 preview features，發布策略是否允許預覽 API？
- 物件是否真正不可變，還是需要額外的封裝和生命週期管理？
30 秒回答框架
我會把 StableValue 當作「最多成功設定一次」的發布容器，而不是自動讓物件具備執行緒安全。先在工廠方法中完成完整建構，再用 orElseSet 發布；競爭執行緒讀取同一個已發布值。若失敗可重試，必須明確重試上限、例外分類和副作用清理；若失敗即終止，則用 setOrThrow 配合啟動期檢查。由於它在 JDK 25 仍是 preview，我會把啟用參數、監控、回滾和升級驗證寫入發布計畫。
分步驟深入解答
1. StableValue 的核心契約
StableValue 是一個可保存單個非空值的容器，值最多被成功設定一次。它提供讀取、嘗試設定和帶例外的設定方法，目標是讓執行時期識別穩定值並支援安全發布最佳化。
2. 與 volatile 和 AtomicReference 的差異
volatile 允許多次寫入，AtomicReference 也支援更新與比較交換；StableValue 的抽象直接表達「成功後不再改變」。因此它適合一次性設定、解析結果或共享控制代碼，不適合需要刷新或替換的快取。
3. 一次性延遲初始化程式碼
import java.lang.StableValue;
final class CatalogHolder {
private final StableValue<Catalog> catalog = StableValue.of();
Catalog get() {
return catalog.orElseSet(this::loadCatalog);
}
private Catalog loadCatalog() {
return Catalog.loadFrom("/etc/catalog.json");
}
}工廠方法應先完成全部驗證，再把完整物件返回。不要把半初始化物件放入容器後繼續修改。
4. 競爭初始化如何處理
多個執行緒同時呼叫 orElseSet 時，只有一個值會成功發布；其餘執行緒應讀取已發布值。工廠方法可能被併發呼叫，因此必須假設它可執行多次，避免重複註冊、重複扣款或重複開啟檔案等不可逆副作用。
5. 例外和重試策略
若工廠拋出例外，容器不會得到值，後續呼叫仍可能再次嘗試。應區分瞬時故障和確定性設定錯誤，設定退避、次數上限和指標。若不允許重試，可在啟動階段捕獲例外並透過 setOrThrow 或直接終止程序。
6. trySet 與 setOrThrow 的用途
trySet 回報本次設定是否成功，適合顯式競爭控制；setOrThrow 在已設定或值非法時拋出例外，適合你已保證單一寫入者的啟動路徑。讀取側可用 orElseThrow 表達「此時必須已初始化」。
7. 發布可見性與物件狀態
發布容器解決的是值何時對其他執行緒可見，不能取代物件內部的執行緒安全。應讓 Catalog 的欄位在建構完成後不再變化，使用 final 欄位、不可變集合或受控同步；若包含可變資源，還要定義關閉和併發存取協定。
8. 預覽 API 的工程化落地
JDK 25 文件將 StableValue 標為 preview。建置和執行需要啟用對應 preview 選項，並在 CI、容器映像、開發工具和生產啟動腳本中保持一致。應記錄替代實作、相容矩陣和升級回滾步驟，避免把預覽 API 傳播到無法快速回滾的邊界。
設計取捨與邊界
- 需要刷新、替換或按鍵淘汰時使用快取或原子引用，StableValue 不提供這些生命週期操作。
- 工廠有外部副作用時，競爭呼叫可能重複執行；應先做冪等化，或用獨立鎖協調副作用，再發布結果。
- 需要等待初始化完成的場景可在上層使用 Future；不要把阻塞等待誤認為 StableValue 的內建語義。
- 預覽 API 的效能收益不能取代基準測試；比較時要涵蓋冷啟動、競爭、例外和 GC。
落地計畫與證據
- 用 JDK 25 preview 編譯最小實作，驗證
orElseSet、trySet、setOrThrow的回傳值和例外。 - 寫併發壓力測試，統計工廠呼叫次數、發布成功次數、重複副作用和讀取延遲。
- 注入建構例外與逾時，確認重試、退避、告警和程序退出策略。
- 在目標容器中驗證啟動參數、映像 JDK、監控和回滾腳本。
- 記錄 Oracle API、JDK 25 變更說明和 JVM 規範作為評審依據。
常見誤區與追問
誤區一：把 StableValue 說成普通不可變物件
它限制容器的成功寫入次數，不會凍結內部物件。面試時應同時說明物件本身的不可變設計。
誤區二：假設工廠只會執行一次
競爭或失敗重試都可能讓工廠執行多次。必須說明副作用冪等和呼叫計數驗證。
誤區三：忽略 preview 啟用條件
只在本地 JDK 25 編譯通過不代表生產可執行。應檢查編譯、啟動、容器和 CI 的 preview 參數。
追問：為什麼不繼續用 volatile 雙重檢查？
如果目標是可刷新引用，volatile 仍然合適；如果目標是明確的一次性發布，StableValue 的契約更貼近意圖，但要承擔 preview 風險並用基準證明收益。
追問：如何證明沒有重複副作用？
給工廠加入可觀測計數和冪等鍵，在併發、例外和重試測試中驗證計數、資源控制代碼與最終值的一致性。