糾結單例模式有幾種寫法有用嗎？有點用，面試中經常選擇其中一種或幾種寫法作爲話頭，考查設計模式和coding style的同時，還很容易擴展到其他問題。這裏講解幾種猴哥常用的寫法，但切忌生搬硬套，去記“茴香豆的寫法”。編程最大的樂趣在於“know everything, control everything”。
大體可分爲4類，下面分別介紹他們的基本形式、變種及特點。
飽漢模式
飽漢是變種最多的單例模式。我們從飽漢出發，通過其變種逐漸瞭解實現單例模式時需要關注的問題。
基礎的飽漢
飽漢，即已經吃飽，不着急再吃，餓的時候再吃。所以他就先不初始化單例，等第一次使用的時候再初始化，即“懶加載”。
飽漢模式的核心就是懶加載。好處是更啓動速度快、節省資源，一直到實例被第一次訪問，才需要初始化單例；小壞處是寫起來麻煩，大壞處是線程不安全，if語句存在競態條件。
寫起來麻煩不是大問題，可讀性好啊。因此，單線程環境下，基礎飽漢是猴哥最喜歡的寫法。但多線程環境下，基礎飽漢就徹底不可用了。下面的幾種變種都在試圖解決基礎飽漢線程不安全的問題。
飽漢 – 變種 1
最粗暴的犯法是用synchronized關鍵字修飾getInstance()方法，這樣能達到絕對的線程安全。
變種1的好處是寫起來簡單，且絕對線程安全；壞處是併發性能極差，事實上完全退化到了串行。單例只需要初始化一次，但就算初始化以後，synchronized的鎖也無法避開，從而getInstance()完全變成了串行操作。性能不敏感的場景建議使用。
飽漢 – 變種 2
變種2是“臭名昭著”的DCL 1.0。
針對變種1中單例初始化後鎖仍然無法避開的問題，變種2在變種1的外層又套了一層check，加上synchronized內層的check，即所謂“雙重檢查鎖”（Double Check Lock，簡稱DCL）。
變種2的核心是DCL，看起來變種2似乎已經達到了理想的效果：懶加載+線程安全。可惜的是，正如註釋中所說，DCL仍然是線程不安全的，由於指令重排序，你可能會得到“半個對象”。詳細在看完變種3後，可參考猴子之前的一篇文章，這裏不再贅述。
參考：volatile關鍵字的作用、原理（https://monkeysayhi.github.io/2016/11/29/volatile關鍵字的作用、原理/）。
飽漢 – 變種 3
變種3專門針對變種2，可謂DCL 2.0。
針對變種3的“半個對象”問題，變種3在instance上增加了volatile關鍵字，原理見上述參考。
多線程環境下，變種3更適用於性能敏感的場景。但後面我們將瞭解到，就算是線程安全的，還有一些辦法能破壞單例。
餓漢模式
與飽漢相對，餓漢很餓，只想着儘早吃到。所以他就在最早的時機，即類加載時初始化單例，以後訪問時直接返回即可。
餓漢的好處是天生的線程安全（得益於類加載機制），寫起來超級簡單，使用時沒有延遲；壞處是有可能造成資源浪費（如果類加載後就一直不使用單例的話）。
值得注意的時，單線程環境下，餓漢與飽漢在性能上沒什麼差別；但多線程環境下，由於飽漢需要加鎖，餓漢的性能反而更優。
Holder模式
我們既希望利用餓漢模式中靜態變量的方便和線程安全；又希望通過懶加載規避資源浪費。Holder模式滿足了這兩點要求：核心仍然是靜態變量，足夠方便和線程安全；通過靜態的Holder類持有真正實例，間接實現了懶加載。
相對於餓漢模式，Holder模式僅增加了一個靜態內部類的成本，與飽漢的變種3效果相當（略優），都是比較受歡迎的實現方式。同樣建議考慮。
枚舉模式
用枚舉實現單例模式，相當好用，但可讀性是不存在的。
基礎的枚舉
將枚舉的靜態成員變量作爲單例的實例：
代碼量比餓漢模式更少。但用戶只能直接訪問實例Singleton4.SINGLETON——事實上，這樣的訪問方式作爲單例使用也是恰當的，只是犧牲了靜態工廠方法的優點，如無法實現懶加載。
醜陋但好用的語法糖
Java的枚舉是一個“醜陋但好用的語法糖”。
枚舉型單例模式的本質
通過反編譯（jad，源碼|String拼接操作”+”的優化？（https://monkeysayhi.github.io/2017/09/23/源碼%7CString拼接操作”-”的優化%EF%BC%9F/）也用到了）打開語法糖，就看到了枚舉類型的本質，簡化如下：
本質上和餓漢模式相同，區別僅在於公有的靜態成員變量。
用枚舉實現一些trick
這一部分與單例沒什麼關係，可以跳過。如果選擇閱讀也請認清這樣的事實：雖然枚舉相當靈活，但如何恰當的使用枚舉有一定難度。一個足夠簡單的典型例子是TimeUnit類，建議有時間耐心閱讀。
上面已經看到，枚舉型單例的本質仍然是一個普通的類。實際上，我們可以在枚舉型型單例上增加任何普通類可以完成的功能。要點在於枚舉實例的初始化，可以理解爲實例化了一個匿名內部類。爲了更明顯，我們在Singleton4_1中定義一個普通的私有成員變量，一個普通的公有成員方法，和一個公有的抽象成員方法，如下：
這樣，枚舉類Singleton4_1中的每一個枚舉實例不僅繼承了父類Singleton4_1的成員方法print()，還必須實現父類Singleton4_1的抽象成員方法testAbsMethod()。
總結
上面的分析都忽略了反射和序列化的問題。通過反射或序列化，我們仍然能夠訪問到私有構造器，創建新的實例破壞單例模式。此時，只有枚舉模式能天然防範這一問題。反射和序列化猴子還不太瞭解，但基本原理並不難，可以在其他模式上手動實現。
下面繼續忽略反射和序列化的問題，做個總結回味一下：
| 實現方式 | 關鍵點 | 資源浪費 | 線程安全 | 多線程環境的性能足夠優化 |
|---|---|---|---|---|
| 基礎飽漢 | 懶加載 | 否 | 否 | - |
| 飽漢變種1 | 懶加載、同步 | 否 | 是 | 否 |
| 飽漢變種2 | 懶加載、DCL | 否 | 否 | - |
| 飽漢變種3 | 懶加載、DCL、volatile | 否 | 是 | 是 |
| 餓漢 | 靜態變量初始化 | 是 | 是 | 是 |
| Holder | 靜態變量初始化、holder | 否 | 是 | 是 |
| 枚舉 | 枚舉本質、靜態變量初始化 | 否 | 是 | 是 |
單例模式是面試中的常考點，寫起來非常簡單。一方面考查正確性，看本文分析；一方面考查coding style，參考：程序猿應該記住的幾條基本規則（https://monkeysayhi.github.io/2017/09/20/程序猿應該記住的幾條基本規則/）。