Java 理論與實踐：安全構造技術——防止 this 引用在建構期間逸出

Java 的執行緒機制看似簡單，但併發程式設計暗藏殺機：在建構函式完成前讓 this 引用逸出，會導致不可預期的資料競爭與可見性問題。由於多執行緒錯誤難以重現、測試成本極高，從一開始就遵循「安全構造」規範至關重要。

危險的逸出引用

當建構函式尚未完成，this 引用就被發布給其他執行緒可見的場所（靜態欄位、集合、事件監聽器、內部類實例、新啟動的執行緒），其他執行緒可能看到「半初始化」的物件，導致 NullPointerException、資料不一致或更隱蔽的邏輯錯誤。

典型陷阱 1：在建構函式中註冊監聽器

public class EventListener {
    public EventListener(EventSource source) {
        // 初始化...
        source.registerListener(this); // this 逸出！
    }
    public void onEvent(Event e) { ... }
}

若建立子類 RecordingEventListener，父類建構函式執行時子類欄位尚未初始化，事件到來會觸發 NullPointerException。

典型陷阱 2：隱式逸出——非靜態內部類

public class EventListener2 {
    public EventListener2(EventSource source) {
        source.registerListener(new EventListener() { // 隱含 this 參考
            public void onEvent(Event e) { eventReceived(e); }
        });
    }
}

非靜態內部類實例持有外部類 this 引用，風險等同顯式傳遞 this。

典型陷阱 3：在建構函式中啟動執行緒

新執行緒啟動前，建構函式可能尚未完成；若執行緒為內部類或接收 this 參數，同樣導致逸出。解決方案：提供 start() 方法，由呼叫端在建構完成後啟動執行緒。

何謂「發布」？安全與不安全用法對照

只有讓其他執行緒可見的引用才屬於「發布」。

深層原因：記憶體模型與 JSR-133

• Java 語言規範保證 Thread.start() 前對執行緒 A 可見的變數，對執行緒 B 也可見。若在建構函式中啟動執行緒，這項保證失效。
• JSR-133 修訂記憶體模型，賦予 final 與 volatile 更強語義，但前提是建構期間 this 不逸出。

最佳實務總結

1. 建構函式中完全避免使用 this（直接或間接）。
2. 若無法避免，務必確保 this 不被發布到其他執行緒可見處。
3. 使用靜態工廠方法 + 私有建構函式，在工廠方法中完成初始化後再發布引用。
4. 執行緒啟動與物件發布分離：提供 start() 方法。

結語

「安全構造」不是可選項，而是編寫正確併發程式的前提。遵循簡單規範，即可在源頭消除一大類難以診斷的執行緒安全隱患。