“你知道茴香豆的‘茴’字有幾種寫法嗎?”
糾結單例模式有幾種寫法有用嗎?有點用,面試中經常選擇其中一種或幾種寫法作為話頭,考查設計模式和coding style的同時,還很容易擴充套件到其他問題。這裡講解幾種猴哥常用的寫法,但切忌生搬硬套,去記“茴香豆的寫法”。程式設計最大的樂趣在於“know everything, control everything”
。
JDK版本:oracle java 1.8.0_102
大體可分為4類,下面分別介紹他們的基本形式、變種及特點。
飽漢模式
飽漢是變種最多的單例模式。我們從飽漢出發,通過其變種逐漸瞭解實現單例模式時需要關注的問題。
基礎的飽漢
飽漢,即已經吃飽,不著急再吃,餓的時候再吃。所以他就先不初始化單例,等第一次使用的時候再初始化,即“懶載入”
。
// 飽漢
// UnThreadSafe
public class Singleton1 {
private static Singleton1 singleton = null;
private Singleton1() {
}
public static Singleton1 getInstance() {
if (singleton == null) {
singleton = new Singleton1();
}
return singleton;
}
}複製程式碼
飽漢模式的核心就是懶載入。好處是更啟動速度快、節省資源,一直到例項被第一次訪問,才需要初始化單例;小壞處是寫起來麻煩,大壞處是執行緒不安全,if語句存在競態條件。
寫起來麻煩不是大問題,可讀性好啊。因此,單執行緒環境下,基礎飽漢是猴哥最喜歡的寫法。但多執行緒環境下,基礎飽漢就徹底不可用了。下面的幾種變種都在試圖解決基礎飽漢執行緒不安全的問題。
飽漢 – 變種 1
最粗暴的犯法是用synchronized關鍵字修飾getInstance()方法,這樣能達到絕對的執行緒安全。
// 飽漢
// ThreadSafe
public class Singleton1_1 {
private static Singleton1_1 singleton = null;
private Singleton1_1() {
}
public synchronized static Singleton1_1 getInstance() {
if (singleton == null) {
singleton = new Singleton1_1();
}
return singleton;
}
}複製程式碼
變種1的好處是寫起來簡單,且絕對執行緒安全;壞處是併發效能極差,事實上完全退化到了序列。單例只需要初始化一次,但就算初始化以後,synchronized的鎖也無法避開,從而getInstance()完全變成了序列操作。效能不敏感的場景建議使用。
飽漢 – 變種 2
變種2是“臭名昭著”的DCL 1.0
。
針對變種1中單例初始化後鎖仍然無法避開的問題,變種2在變種1的外層又套了一層check,加上synchronized內層的check,即所謂“雙重檢查鎖”(Double Check Lock,簡稱DCL)。
// 飽漢
// UnThreadSafe
public class Singleton1_2 {
private static Singleton1_2 singleton = null;
private Singleton1_2() {
}
public static Singleton1_2 getInstance() {
// may get half object
if (singleton == null) {
synchronized (Singleton1_2.class) {
if (singleton == null) {
singleton = new Singleton1_2();
}
}
}
return singleton;
}
}複製程式碼
變種2的核心是DCL,看起來變種2似乎已經達到了理想的效果:懶載入+執行緒安全。可惜的是,正如註釋中所說,DCL仍然是執行緒不安全的,由於指令重排序,你可能會得到“半個物件”。詳細在看完變種3後,可參考猴子之前的一篇文章,這裡不再贅述。
飽漢 – 變種 3
變種3專門針對變種2,可謂DCL 2.0
。
針對變種3的“半個物件”問題,變種3在instance上增加了volatile關鍵字,原理見上述參考。
// 飽漢
// ThreadSafe
public class Singleton1_3 {
private static volatile Singleton1_3 singleton = null;
private Singleton1_3() {
}
public static Singleton1_3 getInstance() {
if (singleton == null) {
synchronized (Singleton1_3.class) {
// must be a complete instance
if (singleton == null) {
singleton = new Singleton1_3();
}
}
}
return singleton;
}
}複製程式碼
多執行緒環境下,變種3更適用於效能敏感的場景。但後面我們將瞭解到,就算是執行緒安全的,還有一些辦法能破壞單例。
餓漢模式
與飽漢相對,餓漢很餓,只想著儘早吃到。所以他就在最早的時機,即類載入時初始化單例,以後訪問時直接返回即可。
// 餓漢
// ThreadSafe
public class Singleton2 {
private static final Singleton2 singleton = new Singleton2();
private Singleton2() {
}
public static Singleton2 getInstance() {
return singleton;
}
}複製程式碼
餓漢的好處是天生的執行緒安全(得益於類載入機制),寫起來超級簡單,使用時沒有延遲;壞處是有可能造成資源浪費(如果類載入後就一直不使用單例的話)。
值得注意的時,單執行緒環境下,餓漢與飽漢在效能上沒什麼差別;但多執行緒環境下,由於飽漢需要加鎖,餓漢的效能反而更優。
Holder模式
我們既希望利用餓漢模式中靜態變數的方便和執行緒安全;又希望通過懶載入規避資源浪費。Holder模式滿足了這兩點要求:核心仍然是靜態變數,足夠方便和執行緒安全;通過靜態的Holder類持有真正例項,間接實現了懶載入。
// Holder模式
// ThreadSafe
public class Singleton3 {
private static class SingletonHolder {
private static final Singleton3 singleton = new Singleton3();
private SingletonHolder() {
}
}
private Singleton3() {
}
/**
* 勘誤:多寫了個synchronized。。
public synchronized static Singleton3 getInstance() {
return SingletonHolder.singleton;
}
*/
public static Singleton3 getInstance() {
return SingletonHolder.singleton;
}
}複製程式碼
相對於餓漢模式,Holder模式僅增加了一個靜態內部類的成本,與飽漢的變種3效果相當(略優),都是比較受歡迎的實現方式。同樣建議考慮。
列舉模式
用列舉實現單例模式,相當好用,但可讀性是不存在的。
基礎的列舉
將列舉的靜態成員變數作為單例的例項:
// 列舉
// ThreadSafe
public enum Singleton4 {
SINGLETON;
}複製程式碼
程式碼量比餓漢模式更少。但使用者只能直接訪問例項Singleton4.SINGLETON
——事實上,這樣的訪問方式作為單例使用也是恰當的,只是犧牲了靜態工廠方法的優點,如無法實現懶載入。
醜陋但好用的語法糖
Java的列舉是一個“醜陋但好用的語法糖”。
列舉型單例模式的本質
通過反編譯(jad,原始碼|String拼接操作”+”的優化?也用到了)開啟語法糖,就看到了列舉型別的本質,簡化如下:
// 列舉
// ThreadSafe
public class Singleton4 extends Enum<Singleton4> {
...
public static final Singleton4 SINGLETON = new Singleton4();
...
}複製程式碼
本質上和餓漢模式相同,區別僅在於公有的靜態成員變數。
用列舉實現一些trick
這一部分與單例沒什麼關係,可以跳過。如果選擇閱讀也請認清這樣的事實:雖然列舉相當靈活,但如何恰當的使用列舉有一定難度。一個足夠簡單的典型例子是TimeUnit類,建議有時間耐心閱讀。
上面已經看到,列舉型單例的本質仍然是一個普通的類。實際上,我們可以在列舉型型單例上增加任何普通類可以完成的功能。要點在於列舉例項的初始化,可以理解為例項化了一個匿名內部類。為了更明顯,我們在Singleton4_1
中定義一個普通的私有成員變數,一個普通的公有成員方法,和一個公有的抽象成員方法,如下:
// 列舉
// ThreadSafe
public enum Singleton4_1 {
SINGLETON("enum is the easiest singleton pattern, but not the most readable") {
public void testAbsMethod() {
print();
System.out.println("enum is ugly, but so flexible to make lots of trick");
}
};
private String comment = null;
Singleton4_1(String comment) {
this.comment = comment;
}
public void print() {
System.out.println("comment=" + comment);
}
abstract public void testAbsMethod();
public static Singleton4_1 getInstance() {
return SINGLETON;
}
}複製程式碼
這樣,列舉類Singleton4_1
中的每一個列舉例項不僅繼承了父類Singleton4_1
的成員方法print()
,還必須實現父類Singleton4_1
的抽象成員方法testAbsMethod()
。
總結
上面的分析都忽略了反射和序列化的問題。通過反射或序列化,我們仍然能夠訪問到私有構造器,建立新的例項破壞單例模式。此時,只有列舉模式能天然防範這一問題。反射和序列化猴子還不太瞭解,但基本原理並不難,可以在其他模式上手動實現。
下面繼續忽略反射和序列化的問題,做個總結回味一下:
實現方式 | 關鍵點 | 資源浪費 | 執行緒安全 | 多執行緒環境的效能足夠優化 |
---|---|---|---|---|
基礎飽漢 | 懶載入 | 否 | 否 | – |
飽漢變種1 | 懶載入、同步 | 否 | 是 | 否 |
飽漢變種2 | 懶載入、DCL | 否 | 否 | – |
飽漢變種3 | 懶載入、DCL、volatile | 否 | 是 | 是 |
餓漢 | 靜態變數初始化 | 是 | 是 | 是 |
Holder | 靜態變數初始化、holder | 否 | 是 | 是 |
列舉 | 列舉本質、靜態變數初始化 | 否 | 是 | 是 |
單例模式是面試中的常考點,寫起來非常簡單。一方面考查正確性,看本文分析;一方面考查coding style,參考:程式猿應該記住的幾條基本規則
本文連結:面試中單例模式有幾種寫法?
作者:猴子007
出處:monkeysayhi.github.io
本文基於 知識共享署名-相同方式共享 4.0 國際許可協議釋出,歡迎轉載,演繹或用於商業目的,但是必須保留本文的署名及連結。