設計模式是穩健軟體架構的基礎。在建立型模式中，單例模式經常被討論，卻也經常被誤解。它確保一個類別僅有一個實例，並提供一個全域存取點。雖然這聽起來對資源管理很有幫助，但卻帶來了全域狀態管理方面的重大挑戰。本指南探討單例模式的運作機制、與全域狀態相關的風險，以及在物件導向分析與設計中化解這些問題的策略。
🧩 理解物件導向程式設計中的單例模式
單例模式確保一個類別僅有一個實例，並提供一個全域存取點。在物件導向分析與設計中，這通常用於管理設定、連接池或記錄服務。核心要求是對實例化進行嚴格控制。
- 私有建構函式： 防止使用
new關鍵字進行外部實例化。 - 靜態實例： 保存類別內單一物件的參考。
- 公開存取器： 回傳實例的靜態方法。
雖然實作看似簡單，但其架構影響遠超過單一方法呼叫。此模式實際上創造了一個全域變數，這是一種特定類型的全域狀態。全域狀態指的是任何可從系統中任何位置存取的資料或資源，無論呼叫程式碼的範圍為何。
🚫 全域狀態的隱藏代價
全域狀態經常被視為現代軟體工程中的反模式。雖然單例模式本身並非本質上惡劣，但它會加劇與全域狀態相關的問題。理解這些問題是化解它們的第一步。
1. 緊密耦合
當一個類別依賴於單例時，它依賴的是具體實作而非抽象。這使得程式碼變得僵硬。如果需求變更，需要更換實作，所有引用單例的類別都必須更新。這違反了依賴反轉原則。
2. 隱藏的相依性
相依性最好明確表示。使用單例時，相依性是隱含的。一個方法可能呼叫單例，卻未在其簽章中表明需要特定資源。這使得程式碼更難閱讀與理解。新開發人員必須追蹤整個呼叫堆疊，才能發現使用了哪些資源。
3. 測試困難
測試是全域狀態最嚴重的犧牲品。當單元測試執行時，期望系統處於已知狀態。如果單例持有來自前一個測試的可變狀態，當前測試可能會無法預測地失敗。重設單例通常需要破壞封裝性或使用反射，這會使測試套件變得脆弱。
4. 並行問題
在多執行緒環境中，若未正確同步就存取共享實例，可能導致競爭條件。如果單例是延遲初始化，兩個執行緒可能同時嘗試建立實例，導致產生多個實例。這破壞了該模式的核心合約。
⚡ 實作執行緒安全的單例
為了安全地使用單例模式，必須處理並行問題。有幾種方法可在不影響效能的情況下確保執行緒安全。
- 急切初始化： 實例在類別載入時建立。由於類別載入由執行時期環境同步，因此本方式天生執行緒安全。然而，若實例從未被使用，可能會浪費資源。
- 延遲初始化搭配鎖定： 實例在首次存取時建立。鎖機制確保僅有一個執行緒建立它。這方式簡單，但如果存取器被頻繁呼叫，可能成為效能瓶頸。
- 雙重檢查鎖定： 在获取鎖之前檢查實例是否存在。這可以減少鎖定開銷，但需要仔細處理記憶體屏障，以防止重排序問題。
- 初始化區塊： 使用靜態區塊或內部靜態輔助類別（Bill Pugh 解法）可確保執行緒安全，而無需明確的鎖定。JVM 會在類別載入期間處理同步。
每種方法都有其權衡。急切初始化簡單但缺乏彈性。雙重檢查鎖定效率高但複雜。初始化區塊通常是靜態單例的推薦做法。
🔄 單例模式的替代方案
由於全域狀態存在諸多陷阱，許多架構師更傾向於選擇能達成類似目標但無此缺點的替代方案。這些模式促進鬆散耦合，並更容易測試。
1. 依賴注入（DI）
依賴注入是標準的替代方案。與類別直接取得單例不同，單例（或其所代表的服務）會被傳遞給類別，通常透過建構函式。這使依賴關係變得明確，並允許消費者在測試時接收模擬或存根物件。
範例邏輯：
- 為服務定義一個介面。
- 建立具體的實作。
- 將實作註冊到容器中，或手動傳遞。
- 將介面注入需要它的類別中。
2. 服務定位器
服務定位器是一種服務註冊表。類別向定位器請求服務，而非自行建立。雖然這相比直接存取單例能降低耦合，但仍隱藏了依賴關係。它通常被視為反服務定位器反模式的一種變體。
3. 工廠模式
工廠用來建立物件。如果工廠確保僅建立一個物件並加以快取，就能模擬單例行為。然而，工廠本身也可以被注入，使邏輯得以替換或模擬，而不影響客戶端程式碼。
📊 狀態管理方法的比較
下表總結了透過單例、依賴注入與工廠模式管理狀態時的權衡。
| 功能 | 單例 | 依賴注入 | 工廠 |
|---|---|---|---|
| 全域狀態 | 高 | 低 | 中等 |
| 可測試性 | 低 | 高 | 中等 |
| 執行緒安全性 | 需要手動處理 | 由容器管理 | 由實作管理 |
| 耦合度 | 緊密 | 鬆散 | 鬆散 |
| 效能 | 快速（直接存取） | 可變（注入開銷） | 可變（工廠開銷） |
📦 為可測試性管理狀態
如果你必須使用單例模式，你必須確保它能夠被測試。這需要將單例模式視為一種可重置或替換的資源。
- 使用介面： 始終依賴介面，而非具體的單例類別。這讓你可以注入模擬實作。
- 重置機制： 提供一個靜態方法來清除實例。這僅應在測試環境中使用，以確保測試案例之間的狀態隔離。
- 作用域管理： 在網頁應用程式中，如果單例模式持有使用者特定資料，則應針對每個請求或會話管理其生命週期。真正的單例模式不應持有暫時性的使用者資料。
考慮單例模式持有資料庫連接的情境。如果測試套件執行多個會修改資料庫的測試，狀態會持續存在。使用 DI 容器可為每個測試提供新的連接，確保隔離性。
🛠️ 重構單例模式以避免全域狀態
重構遺留系統以移除全域狀態需要系統性的方法。你不能簡單地刪除單例模式而不會破壞應用程式。
- 識別相依性： 列出所有直接呼叫單例模式的類別。
- 引入介面： 建立一個介面，定義單例模式所使用的方法。
- 實作介面： 確保單例模式實作了此介面。
- 注入介面： 修改依賴的類別，使其透過建構函式或設定器注入來接受介面。
- 連結實例： 在應用程式入口點，實例化單例並傳遞給根物件。
- 驗證： 執行測試套件以確保行為保持一致。
此過程將隱藏的相依性轉換為明確的相依性。它提升了程式碼的清晰度，並降低了副作用的風險。
⚖️ 何時使用單例模式
儘管存在風險，單例模式在特定情境下仍然適用。關鍵在於限制其範圍與使用。
- 設定管理器： 在啟動時讀取設定是一種常見用例。由於設定在執行期間很少變更，全域存取是可以接受的。
- 記錄系統： 集中化的記錄機制通常受益於單一控制點，以管理輸出串流與格式化。
- 資源池： 連接池或執行緒池需要管理有限的資源集。單例模式可確保資源池在應用程式中被高效共用。
在這些情況下，狀態是極少或不可變的。單例模式管理的是資源，而非業務邏輯。此區別至關重要。包含業務邏輯的單例模式是一種程式碼壞味道。
🔒 安全性考量
全域狀態會引入安全風險。如果單例模式持有敏感資料，例如加密金鑰或驗證權杖，它就會成為高價值目標。系統中的任何程式碼都能存取它。
- 最小權限： 確保只有必要的元件能存取單例模式。
- 資料隔離： 不要在進程層級的單例模式中儲存使用者特定資料。應改用會話層級的儲存空間。
- 加密： 如果必須儲存敏感資料，請確保其在靜態儲存與記憶體中均已被加密。
📉 性能影響
使用單例模式可透過減少物件建立的開銷來提升效能。然而，在現代環境中物件配置成本低廉，此優勢通常可忽略不計。執行緒安全所需的鎖定成本，可能超過單一實例所帶來的節省。
此外，如果單例模式持有經常被修改的狀態，它可能成為瓶頸。多個執行緒存取同一物件時可能爭奪鎖，導致吞吐量下降。在高併發系統中，通常更傾向於使用無狀態服務而非有狀態的單例模式。
🧭 架構指南
為維持乾淨的架構，處理單例模式時應遵循以下指南：
- 保持無狀態： 優先使用作為管理員或協調者角色的單例，而非資料的持有者。
- 限制範圍： 若可能，應使用請求範圍或會話範圍，而非應用程式範圍。
- 記錄使用方式： 清楚記錄使用單例的原因。若理由僅是「方便存取」，這並不足以作為合理依據。
- 避免嵌套單例： 不要建立依賴其他單例的單例。這會造成隱藏的依賴關係網。
遵循這些原則，你可以在降低與全域狀態相關風險的同時，發揮單例模式的優勢。目標並非完全禁止此模式，而是以明確意圖與紀律來使用它。
🔍 實作上的最後想法
是否使用單例的決定應是架構性的，而非偶然的。這需要對其所管理資料的生命周期有清晰的理解。當全域狀態無法避免時，必須以與其他共享資源同等嚴謹的方式進行管理。同步、隔離與可測試性必須從設計之初就融入其中。
現代框架通常提供內建機制，透過依賴注入容器來管理單一實例。這些工具抽象了執行緒安全與生命週期管理的複雜性，讓開發者能專注於業務邏輯。利用這些工具通常比自行實作自訂單例更安全。
最終，軟體系統的健康取決於其可維護性。過度依賴全域狀態的程式碼難以維護、重構與擴展。透過優先考慮明確的依賴關係與受控的狀態，你才能建立出具韌性且能適應變化的系統。