本文已收錄到我的 github 地址: https://github.com/allentofight/easy-cs ，歡迎大家關注並給個 star，這對我非常重要，感謝支持！之後碼海的每篇文章都會收錄至此地址以方便大家查閱!
前言
單例模式可以說是設計模式中最簡單和最基礎的一種設計模式了，哪怕是一個初級開發，在被問到使用過哪些設計模式的時候，估計多數會說單例模式。但是你認爲這麼基本的”單例模式“真的就那麼簡單嗎？或許你會反問：「一個簡單的單例模式該是咋樣的？」哈哈，話不多說，讓我們一起拭目以待，堅持看完，相信你一定會有收穫！
餓漢式
餓漢式是最常見的也是最不需要考慮太多的單例模式，因爲他不存在線程安全問題，餓漢式也就是在類被加載的時候就創建實例對象。餓漢式的寫法如下：
public class SingletonHungry {
private static SingletonHungry instance = new SingletonHungry();
private SingletonHungry() {
}
private static SingletonHungry getInstance() {
return instance;
}
}
測試代碼如下：
class A {
public static void main(String[] args) {
IntStream.rangeClosed(1, 5)
.forEach(i -> {
new Thread(
() -> {
SingletonHungry instance = SingletonHungry.getInstance();
System.out.println("instance = " + instance);
}
).start();
});
}
}
優點:線程安全，不需要關心併發問題，寫法也是最簡單的。
缺點:在類被加載的時候對象就會被創建，也就是說不管你是不是用到該對象，此對象都會被創建，浪費內存空間
懶漢式
以下是最基本的餓漢式的寫法，在單線程情況下，這種方式是非常完美的，但是我們實際程序執行基本都不可能是單線程的，所以這種寫法必定會存在線程安全問題
public class SingletonLazy {
private SingletonLazy() {
}
private static SingletonLazy instance = null;
public static SingletonLazy getInstance() {
if (null == instance) {
return new SingletonLazy();
}
return instance;
}
}
演示多線程執行
class B {
public static void main(String[] args) {
IntStream.rangeClosed(1, 5)
.forEach(i -> {
new Thread(
() -> {
SingletonLazy instance = SingletonLazy.getInstance();
System.out.println("instance = " + instance);
}
).start();
});
}
}
結果很顯然，獲取的實例對象不是單例的。也就是說這種寫法不是線程安全的，也就不能在多線程情況下使用
DCL（雙重檢查鎖式）
DCL 即 Double Check Lock 就是在創建實例的時候進行雙重檢查，首先檢查實例對象是否爲空，如果不爲空將當前類上鎖，然後再判斷一次該實例是否爲空，如果仍然爲空就創建該是實例；代碼如下：
public class SingleTonDcl {
private SingleTonDcl() {
}
private static SingleTonDcl instance = null;
public static SingleTonDcl getInstance() {
if (null == instance) {
synchronized (SingleTonDcl.class) {
if (null == instance) {
instance = new SingleTonDcl();
}
}
}
return instance;
}
}
測試代碼如下：
class C {
public static void main(String[] args) {
IntStream.rangeClosed(1, 5)
.forEach(i -> {
new Thread(
() -> {
SingleTonDcl instance = SingleTonDcl.getInstance();
System.out.println("instance = " + instance);
}
).start();
});
}
}
相信大多數初學者在接觸到這種寫法的時候已經感覺是「高大上」了，首先是判斷實例對象是否爲空，如果爲空那麼就將該對象的 Class 作爲鎖，這樣保證同一時刻只能有一個線程進行訪問，然後再次判斷實例對象是否爲空，最後纔會真正的去初始化創建該實例對象。一切看起來似乎已經沒有破綻，但是當你學過JVM後你可能就會一眼看出貓膩了。沒錯，問題就在 instance = new SingleTonDcl(); 因爲這不是一個原子的操作，這句話的執行是在 JVM 層面分以下三步：
1.給 SingleTonDcl 分配內存空間 2.初始化 SingleTonDcl 實例 3.將 instance 對象指向分配的內存空間（ instance 爲 null 了）
正常情況下上面三步是順序執行的，但是實際上JVM可能會「自作多情」得將我們的代碼進行優化，可能執行的順序是1、3、2，如下代碼所示
public static SingleTonDcl getInstance() {
if (null == instance) {
synchronized (SingleTonDcl.class) {
if (null == instance) {
1. 給 SingleTonDcl 分配內存空間
3.將 instance 對象指向分配的內存空間（ instance 不爲 null 了）
2. 初始化 SingleTonDcl 實例
}
}
}
return instance;
}
假設現在有兩個線程 t1, t2
如果 t1 執行到以上步驟 3 被掛起 然後 t2 進入了 getInstance 方法，由於 t1 執行了步驟 3，此時的 instance 已經不爲空了，所以 if (null == instance) 這個條件不爲空，直接返回 instance, 但由於 t1 還未執行步驟 2，導致此時的 instance 實際上是個半成品，會導致不可預知的風險!
該怎麼解決呢，既然問題出在指令有可能重排序上，不讓它重排序不就行了，volatile 不就是幹這事的嗎，我們可以在 instance 變量前面加上一個 volatile 修飾符
畫外音：volatile 的作用
1.保證的對象內存可見性
2.防止指令重排序
優化後的代碼如下
public class SingleTonDcl {
private SingleTonDcl() {
}
//在對象前面添加 volatile 關鍵字即可
volatile private static SingleTonDcl instance = null;
public static SingleTonDcl getInstance() {
if (null == instance) {
synchronized (SingleTonDcl.class) {
if (null == instance) {
instance = new SingleTonDcl();
}
}
}
return instance;
}
}
到這裏似乎問題已經解決了，雙重鎖機制 + volatile 實際上確實基本上解決了線程安全問題，保證了“真正”的單例。但真的是這樣的嗎？繼續往下看
靜態內部類
先看代碼
public class SingleTonStaticInnerClass {
private SingleTonStaticInnerClass() {
}
private static class HandlerInstance {
private static SingleTonStaticInnerClass instance = new SingleTonStaticInnerClass();
}
public static SingleTonStaticInnerClass getInstance() {
return HandlerInstance.instance;
}
}
測試代碼如下：
class D {
public static void main(String[] args) {
IntStream.rangeClosed(1, 5)
.forEach(i->{
new Thread(()->{
SingleTonStaticInnerClass instance = SingleTonStaticInnerClass.getInstance();
System.out.println("instance = " + instance);
}).start();
});
}
}
靜態內部類的特點：
這種寫法使用 JVM 類加載機制保證了線程安全問題；由於 SingleTonStaticInnerClass 是私有的，除了 getInstance() 之外沒有辦法訪問它，因此它是懶漢式的；同時讀取實例的時候不會進行同步，沒有性能缺陷；也不依賴 JDK 版本；
但是，它依舊不是完美的。
不安全的單例
上面實現單例都不是完美的，主要有兩個原因
1. 反射攻擊
首先要提到 java 中讓人又愛又恨的反射機制, 閒言少敘，我們直接邊上代碼邊說明，這裏就以 DCL 舉例（爲什麼選擇 DCL 因爲很多人覺得 DCL 寫法是最高大上的....這裏就開始去”打他們的臉“）
將上面的 DCl 的測試代碼修改如下：
class C {
public static void main(String[] args) throws NoSuchMethodException, IllegalAccessException, InvocationTargetException, InstantiationException {
Class<SingleTonDcl> singleTonDclClass = SingleTonDcl.class;
//獲取類的構造器
Constructor<SingleTonDcl> constructor = singleTonDclClass.getDeclaredConstructor();
//把構造器私有權限放開
constructor.setAccessible(true);
//反射創建實例 注意反射創建要放在前面，纔會攻擊成功，因爲如果反射攻擊在後面，先使用正常的方式創建實例的話，在構造器中判斷是可以防止反射攻擊、拋出異常的，
//因爲先使用正常的方式已經創建了實例，會進入if
SingleTonDcl instance = constructor.newInstance();
//正常的獲取實例方式 正常的方式放在反射創建實例後面，這樣當反射創建成功後，單例對象中的引用其實還是空的，反射攻擊才能成功
SingleTonDcl instance1 = SingleTonDcl.getInstance();
System.out.println("instance1 = " + instance1);
System.out.println("instance = " + instance);
}
}
居然是兩個對象！內心是不是異常平靜？果然和你想的不一樣？其他的方式基本類似，都可以通過反射破壞單例。
2. 序列化攻擊
我們以「餓漢式單例」爲例來演示一下序列化和反序列化攻擊代碼，首先給餓漢式單例對應的類添加實現 Serializable 接口的代碼，
public class SingletonHungry implements Serializable {
private static SingletonHungry instance = new SingletonHungry();
private SingletonHungry() {
}
private static SingletonHungry getInstance() {
return instance;
}
}
然後看看如何使用序列化和反序列化進行攻擊
SingletonHungry instance = SingletonHungry.getInstance();
ObjectOutputStream oos = new ObjectOutputStream(new FileOutputStream("singleton_file")));
// 序列化【寫】操作
oos.writeObject(instance);
File file = new File("singleton_file");
ObjectInputStream ois = new ObjectInputStream(new FileInputStream(file))
// 反序列化【讀】操作
SingletonHungry newInstance = (SingletonHungry) ois.readObject();
System.out.println(instance);
System.out.println(newInstance);
System.out.println(instance == newInstance);
來看下結果
果然出現了兩個不同的對象！這種反序列化攻擊其實解決方式也簡單，重寫反序列化時要調用的 readObject 方法即可
private Object readResolve(){
return instance;
}
這樣在反序列化時候永遠只讀取 instance 這一個實例，保證了單例的實現。
真正安全的單例: 枚舉方式
public enum SingleTonEnum {
/**
* 實例對象
*/
INSTANCE;
public void doSomething() {
System.out.println("doSomething");
}
}
調用方法
public class Main {
public static void main(String[] args) {
SingleTonEnum.INSTANCE.doSomething();
}
}
枚舉模式實現的單例纔是真正的單例模式，是完美的實現方式
有人可能會提出疑問：枚舉是不是也能通過反射來破壞其單例實現呢？
試試唄，修改枚舉的測試類
class E{
public static void main(String[] args) throws NoSuchMethodException, IllegalAccessException, InvocationTargetException, InstantiationException {
Class<SingleTonEnum> singleTonEnumClass = SingleTonEnum.class;
Constructor<SingleTonEnum> declaredConstructor = singleTonEnumClass.getDeclaredConstructor();
declaredConstructor.setAccessible(true);
SingleTonEnum singleTonEnum = declaredConstructor.newInstance();
SingleTonEnum instance = SingleTonEnum.INSTANCE;
System.out.println("instance = " + instance);
System.out.println("singleTonEnum = " + singleTonEnum);
}
}
沒有無參構造？我們使用 javap 工具來查下字節碼看看有啥玄機
好傢伙，發現一個有參構造器 String Int ,那就試試唄
//獲取構造器的時候修改成這樣子
Constructor<SingleTonEnum> declaredConstructor = singleTonEnumClass.getDeclaredConstructor(String.class,int.class);
好傢伙，拋出了異常，異常信息寫着: 「Cannot reflectively create enum objects」
源碼之下無祕密，我們來看看 newInstance() 到底做了什麼？爲啥用反射創建枚舉會拋出這麼個異常？
真相大白！如果是枚舉，不允許通過反射來創建，這纔是使用 enum 創建單例纔可以說是真正安全的原因！
結束語
以上就是一些關於單例模式的知識點彙總，你還真不要小看這個小小的單例，面試的時候多數候選人寫不對這麼一個簡單的單例，寫對的多數也僅止於 DCL，但再問是否有啥不安全，如何用 enum 寫出安全的單例時，幾乎沒有人能答出來！有人說能寫出 DCL 就行了，何必這麼鑽牛角尖？但我想說的是正是這種鑽牛角尖的精神能讓你逐步積累技術深度，成爲專家，對技術有一探究竟的執著，何愁成不了專家?
最後歡迎大家關注我的公號，加我好友:「geekoftaste」,一起交流，共同進步！
