一個看似簡單的設(shè)計模式，Stack Overflow 上卻攢了 4000+ 個"為什么我的單例失效了"的提問。

單例模式（Singleton Pattern）被程序員稱為"最容易寫錯的設(shè)計模式"，沒有之一。面試時八股文背得滾瓜爛熟，生產(chǎn)環(huán)境一跑就露餡。線程安全問題、反射攻擊、序列化漏洞——新手寫的單例代碼，往往帶著這三顆定時炸彈上線。

我見過最離譜的 case：某電商大促期間，庫存服務(wù)因?yàn)閱卫恢貜?fù)初始化，導(dǎo)致超賣 3000 多單。事后復(fù)盤，開發(fā)者在單例里加了 `synchronized` 關(guān)鍵字，卻忘了指令重排序的坑。這就像是給門上了鎖，但窗戶還敞著。

初級程序員的"標(biāo)準(zhǔn)錯誤答案"

打開任意一篇中文技術(shù)博客，教你寫單例的第一種寫法大概率是"餓漢式"：

```java public class Singleton { private static Singleton instance = new Singleton(); private Singleton() {} public static Singleton getInstance() { return instance; } } ```

這種寫法線程安全，但問題在于：類加載時就初始化，不管用不用都占著內(nèi)存。對于啟動耗時敏感的大型應(yīng)用，這相當(dāng)于提前把全家桶點(diǎn)好，哪怕你只想要一杯可樂。

于是新手轉(zhuǎn)向"懶漢式"，加個 `if (instance == null)` 判斷延遲加載。多線程環(huán)境一壓測，直接冒出多個實(shí)例。趕緊套上 `synchronized`，性能又?jǐn)嘌率较碌看潍@取實(shí)例都要排隊(duì)，高并發(fā)場景下這行代碼就是瓶頸。

雙重檢查鎖定（Double-Checked Locking）看似解決了性能和線程安全的矛盾，但 `volatile` 關(guān)鍵字漏寫的概率，堪比忘記關(guān)煤氣閥。沒有內(nèi)存屏障保證，指令重排序會讓另一個線程拿到未完全構(gòu)造的對象，然后調(diào)用一個空指針方法。

99% 的初級開發(fā)者，都停留在"能跑就行"的階段。單元測試通過，代碼評審沒人細(xì)看，直到生產(chǎn)環(huán)境炸雷。

Senior Devs 的解法：從"造輪子"到"用現(xiàn)成"

真正寫過百萬行代碼的老手，第一反應(yīng)不是"怎么寫個完美的單例"，而是"為什么需要單例"。

Google 的 Java 開發(fā)規(guī)范里有個冷知識：單例本質(zhì)上是一種全局狀態(tài)，而全局狀態(tài)是測試的天敵。依賴注入框架（Dependency Injection）成熟之后，Spring 容器管理的 Bean 默認(rèn)就是單例，而且線程安全、生命周期可控、支持 AOP 增強(qiáng)。

「我們內(nèi)部已經(jīng)禁止手寫單例了?！鼓愁^部云廠商中間件團(tuán)隊(duì)的技術(shù)負(fù)責(zé)人告訴我，「除非你在寫框架級代碼，否則用 Spring 的 `@Singleton` 或者 Guice 的 Provider，比自己實(shí)現(xiàn)可靠一百倍。」

如果確實(shí)需要裸寫 JVM 層面的單例， senior devs 的選項(xiàng)也變了。枚舉單例（Enum Singleton）從 Java 5 開始就被《Effective Java》作者 Joshua Bloch 推薦：

```java public enum Singleton { INSTANCE; // 業(yè)務(wù)方法 } ```

三行代碼，天然防反射、防序列化攻擊、線程安全由 JVM 保證。這就像是買保險，別人還在對比條款，你已經(jīng)選了理賠最痛快的那個。

更激進(jìn)的方案來自 Kotlin：用 `object` 關(guān)鍵字聲明的類，編譯器直接生成單例。沒有樣板代碼，沒有線程安全隱患，語法糖甜到膩。

比寫法更重要的：單例的"退出策略"

新手關(guān)注"怎么創(chuàng)建"，老手關(guān)注"怎么銷毀"。

單例持有數(shù)據(jù)庫連接池、緩存客戶端、線程池等資源時，應(yīng)用重啟或熱部署階段如果清理不干凈，就是內(nèi)存泄漏和連接數(shù)暴漲的元兇。某金融系統(tǒng)的支付網(wǎng)關(guān)曾經(jīng)因此導(dǎo)致連接池耗盡，交易成功率從 99.9% 跌到 87%。

Java 的 `Runtime.addShutdownHook`、Spring 的 `@PreDestroy`、或者實(shí)現(xiàn) `Closeable` 接口配合 try-with-resources，都是 senior devs 會主動考慮的退出機(jī)制。寫單例時先想怎么關(guān)，比先想怎么開更重要。

另一個被忽視的維度是類加載器隔離。在 Tomcat 熱部署場景下，如果單例被父類加載器持有，而業(yè)務(wù)代碼被 WebApp 類加載器加載，重復(fù)部署會導(dǎo)致舊實(shí)例無法回收。這個問題在微服務(wù)架構(gòu)里不常見，但在傳統(tǒng) Java EE 遺留系統(tǒng)中，排查起來能讓人掉光頭發(fā)。

2024 年，單例模式正在"退環(huán)境"

云原生和 Serverless 架構(gòu)的普及，讓"全局唯一實(shí)例"這個假設(shè)本身變得可疑。

容器水平擴(kuò)容時，每個 Pod 都有自己的 JVM 進(jìn)程，單例變成了"每個實(shí)例里的單例"。如果需要跨進(jìn)程唯一，就得引入分布式鎖或一致性哈?！@時候你面對的問題，已經(jīng)不是設(shè)計模式能解決的。

無狀態(tài)服務(wù)（Stateless Service）成為主流架構(gòu)原則后，把狀態(tài)外移到 Redis、Etcd 或數(shù)據(jù)庫，比在代碼里維護(hù)單例更符合 12-Factor 規(guī)范。某跨境電商的技術(shù) VP 跟我聊過，他們?nèi)ツ曛貥?gòu)核心交易鏈路時，一口氣干掉了 47 個手寫單例，P99 延遲下降了 23%。

函數(shù)式編程的興起也在改寫游戲規(guī)則。Scala 的 `object`、Rust 的 `lazy_static`、甚至 Java 的 `Supplier` 接口配合 `memoize` 操作，都在用更聲明式的方式表達(dá)"只計算一次"的語義，而不必套用 GoF 的類結(jié)構(gòu)。

Stack Overflow 2023 年度開發(fā)者調(diào)查顯示，設(shè)計模式相關(guān)問題的瀏覽量同比下降 18%。這不是說設(shè)計模式過時了，而是現(xiàn)代語言和框架把最佳實(shí)踐封裝進(jìn)了語法和庫，普通開發(fā)者不再需要親自操刀。

回到開頭那個超賣 3000 單的案例。事后團(tuán)隊(duì)復(fù)盤，技術(shù)負(fù)責(zé)人把單例實(shí)現(xiàn)換成了枚舉類型，同時在架構(gòu)評審環(huán)節(jié)加了"禁止手寫單例"的 checklist。三個月后，同一場大促，庫存服務(wù)零故障。

你代碼庫里還有手寫的單例嗎？最近一次 code review，有人問過它該怎么銷毀嗎？