4.單例模式詳解

4.1.課程目標

1、掌握單例模式的應用場景。

2、掌握IDEA環境下的多線程調試方式。

3、掌握保證線程安全的單例模式策略。

4、掌握反射暴力攻擊單例解決方案及原理分析。

5、序列化破壞單例的原理及解決方案。

6、掌握常見的單例模式寫法。

4.2.內容定位

1、聽說過單例模式，但不知道如何應用的人群。

2、單例模式是非常經典的高頻面試題，希望通過面試單例彰顯技術深度，順利拿到Offer的人群。

4.3.單例模式的應用場景

單例模式(SingletonPattern)是指確保一個類在任何情況下都絕對只有一個實例，并提供一個全局訪問點。單例模式是創建型模式。單例模式在現實生活中應用也非常廣泛，例如，公司CEO、部門經 理 等 。 J2EE 標 準 中 的 ServletContext 、 ServletContextConfig 等 、 Spring 框 架 應 用 中 的 ApplicationContext、數據庫的連接池BDPool等也都是單例形式。

4.4.餓漢式單例模式

方法1.靜態方法獲得私有成員對象

?/**? * 優點：執行效率高，性能高，沒有任何的鎖? * 缺點：某些情況下，可能會造成內存浪費? */?public class HungrySingleton {? ? ?//先靜態、后動態 ? ? ?//先屬性、后方法 ? ? ?//先上后下? ? ?private static final HungrySingleton hungrySingleton = new HungrySingleton();??? ? ?private HungrySingleton(){}??? ? ?public static HungrySingleton getInstance(){? ? ? ? ?return ?hungrySingleton;? ? }?}

方法2.利用靜態代碼塊與類同時加載的特性生成單例對象

?//餓漢式靜態塊單例模式?public class HungryStaticSingleton {? ? ?//先靜態后動態? ? ?//先上，后下? ? ?//先屬性后方法? ? ?private static final HungryStaticSingleton hungrySingleton;??? ? ?//裝個B? ? ?static {? ? ? ? ?hungrySingleton = new HungryStaticSingleton();? ? }??? ? ?private HungryStaticSingleton(){}??? ? ?public static HungryStaticSingleton getInstance(){? ? ? ? ?return ?hungrySingleton;? ? }?}

類結構圖

優缺點

優點：沒有加任何鎖、執行效率比較高，用戶體驗比懶漢式單例模式更好。

缺點：類加載的時候就初始化，不管用與不用都占著空間，浪費了內存，有可能“占著茅坑不拉屎”。

源碼

Spring中IoC容器ApplicationContext本身就是典型的餓漢式單例模式

4.5.懶漢式單例模式

特點

懶漢式單例模式的特點是：被外部類調用的時候內部類才會加載。

方法1.加大鎖

?/**? * 優點：節省了內存,線程安全? * 缺點：性能低? */?//懶漢式單例模式在外部需要使用的時候才進行實例化?public class LazySimpleSingletion {? ? ?private static LazySimpleSingletion instance;? ? ?//靜態塊，公共內存區域 ? ? ?private LazySimpleSingletion(){}??? ? ?public synchronized static LazySimpleSingletion getInstance(){? ? ? ? ?if(instance == null){? ? ? ? ? ? ?instance = new LazySimpleSingletion();? ? ? ? }? ? ? ? ?return instance;? ? }?}???public class ExectorThread implements Runnable {? ? ?public void run() {? ? ? ? ?LazySimpleSingletion instance = LazySimpleSingletion.getInstance();? ? ? ? ?System.out.println(Thread.currentThread().getName() + ":" + instance);? ? }?}???public class LazySimpleSingletonTest {? ? ?public static void main(String[] args) {? ? ? ? ?Thread t1 = new Thread(new ExectorThread());? ? ? ? ?Thread t2 = new Thread(new ExectorThread());? ? ? ? ?t1.start();? ? ? ? ?t2.start();? ? ? ? ?System.out.println("End");? ? }?}

給getInstance()加上synchronized關鍵字，使這個方法變成線程同步方法：

當執行其中一個線程并調用getInstance()方法時，另一個線程在調用getInstance() 方法，線程的狀態由 RUNNING 變成了 MONITOR，出現阻塞。直到第一個線程執行完，第二個線程 才恢復到RUNNING狀態繼續調用getInstance()方法

線程切換調試

上圖完美地展現了 synchronized 監視鎖的運行狀態，線程安全的問題解決了。但是，用 synchronized加鎖時，在線程數量比較多的情況下，如果CPU分配壓力上升，則會導致大批線程阻塞， 從而導致程序性能大幅下降。那么，有沒有一種更好的方式，既能兼顧線程安全又能提升程序性能呢？ 答案是肯定的。我們來看雙重檢查鎖的單例模式：

方法2.雙重檢查鎖

?/**? * 優點:性能高了，線程安全了? * 缺點：可讀性難度加大，不夠優雅? */?public class LazyDoubleCheckSingleton {? ? ?// volatile解決指令重排序? ? ?private volatile static LazyDoubleCheckSingleton instance;??? ? ?private LazyDoubleCheckSingleton() {? ? }??? ? ?public static LazyDoubleCheckSingleton getInstance() {? ? ? ? ?//檢查是否要阻塞，第一個instance == null是為了創建后不再走synchronized代碼，提高效率。可以理解是個開關。創建后這個開關就關上，后面的代碼就不用執行了。? ? ? ? ?if (instance == null) {? ? ? ? ? ? ?synchronized (LazyDoubleCheckSingleton.class) {? ? ? ? ? ? ? ? ?//檢查是否要重新創建實例? ? ? ? ? ? ? ? ?if (instance == null) {? ? ? ? ? ? ? ? ? ? ?instance = new LazyDoubleCheckSingleton();? ? ? ? ? ? ? ? ? ? ?//指令重排序的問題? ? ? ? ? ? ? ? ? ? ?//1.分配內存給這個對象 ? ? ? ? ? ? ? ? ? ? ?//2.初始化對象? ? ? ? ? ? ? ? ? ? ?//3.設置 lazy 指向剛分配的內存地址? ? ? ? ? ? ? ? }? ? ? ? ? ? }? ? ? ? }? ? ? ? ?return instance;? ? }?}???public class ExectorThread implements Runnable {? ? ?public void run() {? ? ? ? ?LazyDoubleCheckSingleton instance = LazyDoubleCheckSingleton.getInstance();? ? ? ? ?System.out.println(Thread.currentThread().getName() + ":" + instance);? ? }?}???public class LazySimpleSingletonTest {? ? ?public static void main(String[] args) {? ? ? ? ?Thread t1 = new Thread(new ExectorThread());? ? ? ? ?Thread t2 = new Thread(new ExectorThread());? ? ? ? ?t1.start();? ? ? ? ?t2.start();? ? ? ? ?System.out.println("End");? ? }?}

當第一個線程調用 getInstance()方法時，第二個線程也可以調用。當第一個線程執行到 synchronized時會上鎖，第二個線程就會變成 MONITOR狀態，出現阻塞。此時，阻塞并不是基于整 個LazySimpleSingleton類的阻塞，而是在getInstance()方法內部的阻塞，只要邏輯不太復雜，對于 調用者而言感知不到。

但是，用到 synchronized 關鍵字總歸要上鎖，對程序性能還是存在一定影響的。難道就真的沒有更好的方案嗎？當然有。我們可以從類初始化的角度來考慮，看下面的代碼，采用靜態內部類的方式：

方法3.靜態內部類

?/*? ?ClassPath : LazyStaticInnerClassSingleton.class? ? ? ? ? ? ? ?LazyStaticInnerClassSingleton$LazyHolder.class? ? 優點：寫法優雅，利用了Java本身語法特點，性能高，避免了內存浪費,不能被反射破壞? ? 缺點：不優雅? */?//這種形式兼顧餓漢式單例模式的內存浪費問題和 synchronized 的性能問題 ?//完美地屏蔽了這兩個缺點?//自認為史上最牛的單例模式的實現方式 ?public class LazyStaticInnerClassSingleton {??? ? ?//使用 LazyInnerClassGeneral 的時候，默認會先初始化內部類 ? ? ?//如果沒使用，則內部類是不加載的? ? ?private LazyStaticInnerClassSingleton(){? ? ? ? ?// if(LazyHolder.INSTANCE != null){? ? ? ? ?// ? ? throw new RuntimeException("不允許非法創建多個實例");? ? ? ? ?// }? ? }??? ? ?//每一個關鍵字都不是多余的，static 是為了使單例的空間共享，保證這個方法不會被重寫、重載 ? ? ?private static LazyStaticInnerClassSingleton getInstance(){? ? ? ? ?//在返回結果以前，一定會先加載內部類 ? ? ? ? ?return LazyHolder.INSTANCE;? ? }??? ? ?//默認不加載 ? ? ?private static class LazyHolder{? ? ? ? ?private static final LazyStaticInnerClassSingleton INSTANCE = new LazyStaticInnerClassSingleton();? ? }?}

這種方式兼顧了餓漢式單例模式的內存浪費問題和 synchronized 的性能問題。內部類一定是要在方法調用之前初始化，巧妙地避免了線程安全問題。由于這種方式比較簡單，我們就不帶大家一步一步 調試了。

內部類語法特性 ： 內部類用時才加載

4.6.反射破壞單例

?public class ReflectTest {??? ? ?public static void main(String[] args) {? ? ? ? ?try {? ? ? ? ? ? ?//在很無聊的情況下，進行破壞 ? ? ? ? ? ? ?Class> clazz = LazyStaticInnerClassSingleton.class;? ? ? ? ? ? ?//通過反射獲取私有的構造方法? ? ? ? ? ? ?Constructor c = clazz.getDeclaredConstructor(null);? ? ? ? ? ? ?//強制訪問 ? ? ? ? ? ? ?c.setAccessible(true);? ? ? ? ? ? ?//暴力初始化? ? ? ? ? ? ?Object instance1 = c.newInstance();? ? ? ? ? ? ?//調用了兩次構造方法，相當于“new”了兩次，犯了原則性錯誤 ? ? ? ? ? ? ?Object instance2 = c.newInstance();? ? ? ? ? ? ?System.out.println(instance1);? ? ? ? ? ? ?System.out.println(instance2);? ? ? ? ? ? ?System.out.println(instance1 == instance2);? // Enum? ? ? ? }catch (Exception e){? ? ? ? ? ? ?e.printStackTrace();? ? ? ? }? ? }?}???com.gupaoedu.vip.pattern.singleton.lazy.LazyStaticInnerClassSingleton@64cee07?com.gupaoedu.vip.pattern.singleton.lazy.LazyStaticInnerClassSingleton@1761e840?false

大家有沒有發現，上面介紹的單例模式的構造方法除了加上 private 關鍵字，沒有做任何處理。如 果我們使用反射來調用其構造方法，再調用 getInstance()方法，應該有兩個不同的實例。現在來看一 段測試代碼，以LazyInnerClassSingleton為例：

顯然，創建了兩個不同的實例。現在，我們在其構造方法中做一些限制，一旦出現多次重復創建， 則直接拋出異常。所以需要在私有構造方法添加異常：

? ? ?private LazyStaticInnerClassSingleton(){? ? ? ? ?if(LazyHolder.INSTANCE != null){? ? ? ? ? ? ?throw new RuntimeException("不允許非法創建多個實例");? ? ? ? }? ? }

4.7.序列化破壞單例(擴展知識)

一個單例對象創建好后，有時候需要將對象序列化然后寫入磁盤，下次使用時再從磁盤中讀取對象 并進行反序列化，將其轉化為內存對象。反序列化后的對象會重新分配內存，即重新創建。如果序列化 的目標對象為單例對象，就違背了單例模式的初衷，相當于破壞了單例，來看一段代碼：

?//反序列化導致破壞單例模式 ?public class SeriableSingleton implements Serializable {? ? ?//序列化? ? ?//把內存中對象的狀態轉換為字節碼的形式? ? ?//把字節碼通過IO輸出流，寫到磁盤上? ? ?//永久保存下來，持久化? ? ?? ? ?//反序列化? ? ?//將持久化的字節碼內容，通過IO輸入流讀到內存中來? ? ?//轉化成一個Java對象? ? ?? ? ?// 餓漢式? ? ?public ?final static SeriableSingleton INSTANCE = new SeriableSingleton();? ? ?private SeriableSingleton(){}? ? ?public static SeriableSingleton getInstance(){? ? ? ? ?return INSTANCE;? ? }? ? ?// private Object readResolve(){ return INSTANCE;}?}???public class SeriableSingletonTest {? ? ?public static void main(String[] args) {? ? ? ? ?SeriableSingleton s1 = null;? ? ? ? ?SeriableSingleton s2 = SeriableSingleton.getInstance();? ? ? ? ?FileOutputStream fos = null;? ? ? ? ?try {? ? ? ? ? ? ?fos = new FileOutputStream("SeriableSingleton.obj");? ? ? ? ? ? ?ObjectOutputStream oos = new ObjectOutputStream(fos);? ? ? ? ? ? ?oos.writeObject(s2);? ? ? ? ? ? ?oos.flush();? ? ? ? ? ? ?oos.close();? ? ? ? ? ? ?FileInputStream fis = new FileInputStream("SeriableSingleton.obj");? ? ? ? ? ? ?ObjectInputStream ois = new ObjectInputStream(fis);? ? ? ? ? ? ?s1 = (SeriableSingleton)ois.readObject();? ? ? ? ? ? ?ois.close();? ? ? ? ? ? ?System.out.println(s1);? ? ? ? ? ? ?System.out.println(s2);? ? ? ? ? ? ?System.out.println(s1 == s2);? ? ? ? } catch (Exception e) {? ? ? ? ? ? ?e.printStackTrace();? ? ? ? }? ? }?}???打印結果：?com.gupaoedu.vip.pattern.singleton.seriable.SeriableSingleton@68837a77?com.gupaoedu.vip.pattern.singleton.seriable.SeriableSingleton@4b6995df?false

從運行結果可以看出，反序列化后的對象和手動創建的對象是不一致的，實例化了兩次，違背了單 例模式的設計初衷。那么，我們如何保證在序列化的情況下也能夠實現單例模式呢？其實很簡單，只需 要增加readResolve()方法即可。

再看運行結果，如下圖所示。

?com.gupaoedu.vip.pattern.singleton.seriable.SeriableSingleton@4b6995df?com.gupaoedu.vip.pattern.singleton.seriable.SeriableSingleton@4b6995df?true

大家一定會想：這是什么原因呢？為什么要這樣寫？看上去很神奇的樣子，也讓人有些費解。不如 我們一起來看看JDK的源碼實現以了解清楚。我們進入ObjectInputStream類的readObject()方法， 代碼如下：

?public final Object readObject()? ? ? ? ?throws IOException, ClassNotFoundException? ? {? ? ? ? ?if (enableOverride) {? ? ? ? ? ? ?return readObjectOverride();? ? ? ? }??? ? ? ? ?// if nested read, passHandle contains handle of enclosing object? ? ? ? ?int outerHandle = passHandle;? ? ? ? ?try {? ? ? ? ? ? ?Object obj = readObject0(false);? ? ? ? ? ? ?handles.markDependency(outerHandle, passHandle);? ? ? ? ? ? ?ClassNotFoundException ex = handles.lookupException(passHandle);? ? ? ? ? ? ?if (ex != null) {? ? ? ? ? ? ? ? ?throw ex;? ? ? ? ? ? }? ? ? ? ? ? ?if (depth == 0) {? ? ? ? ? ? ? ? ?vlist.doCallbacks();? ? ? ? ? ? }? ? ? ? ? ? ?return obj;? ? ? ? } finally {? ? ? ? ? ? ?passHandle = outerHandle;? ? ? ? ? ? ?if (closed && depth == 0) {? ? ? ? ? ? ? ? ?clear();? ? ? ? ? ? }? ? ? ? }? ? }

我們發現，在readObject()方法中又調用了重寫的readObject0()方法。進入readObject0()方法， 代碼如下：

?private Object readObject0(boolean unshared) throws IOException {? ...? ? ?case TC_OBJECT:? ? return checkResolve(readOrdinaryObject(unshared));? ? ...?}

我們看到TC_OBJECT中調用了ObjectInputStream的readOrdinaryObject()方法，看源碼：

? ? ?private Object readOrdinaryObject(boolean unshared)? ? ? ? ?throws IOException? ? {? ? ? ? ?if (bin.readByte() != TC_OBJECT) {? ? ? ? ? ? ?throw new InternalError();? ? ? ? }??? ? ? ? ?ObjectStreamClass desc = readClassDesc(false);? ? ? ? ?desc.checkDeserialize();??? ? ? ? ?Class> cl = desc.forClass();? ? ? ? ?if (cl == String.class || cl == Class.class? ? ? ? ? ? ? ? ?|| cl == ObjectStreamClass.class) {? ? ? ? ? ? ?throw new InvalidClassException("invalid class descriptor");? ? ? ? }??? ? ? ? ?Object obj;? ? ? ? ?try {? ? ? ? ? ? ?obj = desc.isInstantiable() ? desc.newInstance() : null;? ? ? ? } catch (Exception ex) {? ? ? ? ? ? ?throw (IOException) new InvalidClassException(? ? ? ? ? ? ? ? ?desc.forClass().getName(),? ? ? ? ? ? ? ? ?"unable to create instance").initCause(ex);? ? ? ? }? ...??? ? ? ? ?return obj;? ? }

我們發現調用了ObjectStreamClass的isInstantiable()方法，而isInstantiable()方法的代碼如下：

? ? ?boolean isInstantiable() {? ? ? ? ?requireInitialized();? ? ? ? ?return (cons != null);? ? }

上述代碼非常簡單，就是判斷一下構造方法是否為空，構造方法不為空就返回true。這意味著只要 有無參構造方法就會實例化。

這時候其實還沒有找到加上 readResolve()方法就避免了單例模式被破壞的真正原因。再回到 ObjectInputStream的readOrdinaryObject()方法，繼續往下看：

? ? ?private Object readOrdinaryObject(boolean unshared)? ? ? ? ?throws IOException? ? {? ? ? ? ?if (bin.readByte() != TC_OBJECT) {? ? ? ? ? ? ?throw new InternalError();? ? ? ? }??? ? ? ? ?ObjectStreamClass desc = readClassDesc(false);? ? ? ? ?desc.checkDeserialize();??? ? ? ? ?Class> cl = desc.forClass();? ? ? ? ?if (cl == String.class || cl == Class.class? ? ? ? ? ? ? ? ?|| cl == ObjectStreamClass.class) {? ? ? ? ? ? ?throw new InvalidClassException("invalid class descriptor");? ? ? ? }??? ? ? ? ?Object obj;? ? ? ? ?try {? ? ? ? ? ? ?obj = desc.isInstantiable() ? desc.newInstance() : null;? ? ? ? } catch (Exception ex) {? ? ? ? ? ? ?throw (IOException) new InvalidClassException(? ? ? ? ? ? ? ? ?desc.forClass().getName(),? ? ? ? ? ? ? ? ?"unable to create instance").initCause(ex);? ? ? ? }??? ? ? ? ...? ? ? ? ?if (obj != null &&? ? ? ? ? ? ?handles.lookupException(passHandle) == null &&? ? ? ? ? ? ?desc.hasReadResolveMethod())? ? ? ? {? ? ? ? ? ? ?Object rep = desc.invokeReadResolve(obj);? ? ? ? ? ? ?if (unshared && rep.getClass().isArray()) {? ? ? ? ? ? ? ? ?rep = cloneArray(rep);? ? ? ? ? ? }? ? ? ? ? ? ?if (rep != obj) {? ? ? ? ? ? ? ? ?// Filter the replacement object? ? ? ? ? ? ? ? ?if (rep != null) {? ? ? ? ? ? ? ? ? ? ?if (rep.getClass().isArray()) {? ? ? ? ? ? ? ? ? ? ? ? ?filterCheck(rep.getClass(), Array.getLength(rep));? ? ? ? ? ? ? ? ? ? } else {? ? ? ? ? ? ? ? ? ? ? ? ?filterCheck(rep.getClass(), -1);? ? ? ? ? ? ? ? ? ? }? ? ? ? ? ? ? ? }? ? ? ? ? ? ? ? ?handles.setObject(passHandle, obj = rep);? ? ? ? ? ? }? ? ? ? }??? ? ? ? ?return obj;? ? }

判斷無參構造方法是否存在之后，又調用了hasReadResolveMethod()方法，來看代碼：

? ? ?boolean hasReadResolveMethod() {? ? ? ? ?requireInitialized();? ? ? ? ?return (readResolveMethod != null);? ? }

上述代碼邏輯非常簡單，就是判斷 readResolveMethod 是否為空，不為空就返回 true。那么 readResolveMethod是在哪里賦值的呢？通過全局查找知道，在私有方法 ObjectStreamClass()中給 readResolveMethod進行了賦值，來看代碼：

? ? ?private final void requireInitialized() {? ? ? ? ?if (!initialized)? ? ? ? ? ? ?throw new InternalError("Unexpected call when not initialized");? ? }

上面的邏輯其實就是通過反射找到一個無參的 readResolve()方法，并且保存下來。現在回到 ObjectInputStream 的 readOrdinaryObject()方法繼續往下看，如果 readResolve()方法存在則調用 invokeReadResolve()方法，來看代碼：

? ? ?Object invokeReadResolve(Object obj)? ? ? ? ?throws IOException, UnsupportedOperationException? ? {? ? ? ? ?requireInitialized();? ? ? ? ?if (readResolveMethod != null) {? ? ? ? ? ? ?try {? ? ? ? ? ? ? ? ?return readResolveMethod.invoke(obj, (Object[]) null);? ? ? ? ? ? } catch (InvocationTargetException ex) {? ? ? ? ? ? ? ? ?Throwable th = ex.getTargetException();? ? ? ? ? ? ? ? ?if (th instanceof ObjectStreamException) {? ? ? ? ? ? ? ? ? ? ?throw (ObjectStreamException) th;? ? ? ? ? ? ? ? } else {? ? ? ? ? ? ? ? ? ? ?throwMiscException(th);? ? ? ? ? ? ? ? ? ? ?throw new InternalError(th); ?// never reached? ? ? ? ? ? ? ? }? ? ? ? ? ? } catch (IllegalAccessException ex) {? ? ? ? ? ? ? ? ?// should not occur, as access checks have been suppressed? ? ? ? ? ? ? ? ?throw new InternalError(ex);? ? ? ? ? ? }? ? ? ? } else {? ? ? ? ? ? ?throw new UnsupportedOperationException();? ? ? ? }? ? }

我們可以看到，在invokeReadResolve()方法中用反射調用了readResolveMethod方法。

通過JDK源碼分析我們可以看出，雖然增加 readResolve()方法返回實例解決了單例模式被破壞的 問題，但是實際上實例化了兩次，只不過新創建的對象沒有被返回而已。如果創建對象的動作發生頻率加快，就意味著內存分配開銷也會隨之增大，難道真的就沒辦法從根本上解決問題嗎？下面講的注冊式單例也許能幫助到你。

為什么添加了readResolve()方法就可以了?

ObjectInputStream源碼中，讀取文件時寫死判斷是否有readResolve()方法，有調用這個方法，沒有則重新創建對象。

4.8.注冊式單例模式

將每一個實例都緩存到統一的容器中，使用唯一表示獲取實例。

注冊式單例模式又稱為登記式單例模式，就是將每一個實例都登記到某一個地方，使用唯一的標識獲取實例。注冊式單例模式有兩種：一種為枚舉式單例模式，另一種為容器式單例模式。

方法1. 枚舉式單例模式

先來看枚舉式單例模式的寫法，來看代碼，創建EnumSingleton類：

?public enum EnumSingleton {? ? ?INSTANCE;??? ? ?private Object data;??? ? ?public Object getData() {? ? ? ? ?return data;? ? }??? ? ?public void setData(Object data) {? ? ? ? ?this.data = data;? ? }??? ? ?public static EnumSingleton getInstance(){return INSTANCE;}?}

來看測試代碼：

?public class EnumSingletonTest {? ? ?public static void main(String[] args) {? ? ? ? EnumSingleton instance = EnumSingleton.getInstance();? ? ? ? instance.setData(new Object());? ? ? ? ?try {? ? ? ? ? ? ?Class clazz = EnumSingleton.class;? ? ? ? ? ? ?Constructor c = clazz.getDeclaredConstructor(String.class, int.class);? ? ? ? ? ? ?c.setAccessible(true);? ? ? ? ? ? ?System.out.println(c);? ? ? ? ? ? ?Object o = c.newInstance();? ? ? ? ? ? ?System.out.println(o);? ? ? ? } catch (Exception e) {? ? ? ? ? ? ?e.printStackTrace();? ? ? ? }? ? }?}?java.lang.Object@2acf57e3?java.lang.Object@2acf57e3?true

沒有做任何處理，我們發現運行結果和預期的一樣。那么枚舉式單例模式如此神奇，它的神秘之處 在哪里體現呢？下面通過分析源碼來揭開它的神秘面紗。

下載一個非常好用的 Java反編譯工具 Jad(下載地址：https://varaneckas.com/jad/)，解壓后 配置好環境變量(這里不做詳細介紹)，就可以使用命令行調用了。找到工程所在的Class目錄，復制 EnumSingleton.class 所在的路徑，如下圖所示。

然后切換到命令行，切換到工程所在的Class目錄，輸入命令 jad 并在后面輸入復制好的路徑，在 Class 目錄下會多出一個 EnumSingleton.jad 文件。打開 EnumSingleton.jad 文件我們驚奇地發現有 如下代碼：

?static { ? ? ?INSTANCE = new EnumSingleton("INSTANCE", 0); ? ? ?$VALUES = (new EnumSingleton[] { ? ? ? ? ?INSTANCE ? ? }); ?}

原來，枚舉式單例模式在靜態代碼塊中就給INSTANCE進行了賦值，是餓漢式單例模式的實現。至 此，我們還可以試想，序列化能否破壞枚舉式單例模式呢？不妨再來看一下 JDK 源碼，還是回到 ObjectInputStream的readObject0()方法：

? ? ?private Object readObject0(boolean unshared) throws IOException {? ? ? ? ...? ? ? ? ?case TC_ENUM:? ? ? ? return checkResolve(readEnum(unshared));? ? ? ? ...? ? }

我們看到，在readObject0()中調用了readEnum()方法，來看readEnum()方法的代碼實現：

? ? ?private Enum> readEnum(boolean unshared) throws IOException {? ? ? ? ?if (bin.readByte() != TC_ENUM) {? ? ? ? ? ? ?throw new InternalError();? ? ? ? }??? ? ? ? ?ObjectStreamClass desc = readClassDesc(false);? ? ? ? ?if (!desc.isEnum()) {? ? ? ? ? ? ?throw new InvalidClassException("non-enum class: " + desc);? ? ? ? }??? ? ? ? ?int enumHandle = handles.assign(unshared ? unsharedMarker : null);? ? ? ? ?ClassNotFoundException resolveEx = desc.getResolveException();? ? ? ? ?if (resolveEx != null) {? ? ? ? ? ? ?handles.markException(enumHandle, resolveEx);? ? ? ? }??? ? ? ? ?String name = readString(false);? ? ? ? ?Enum> result = null;? ? ? ? ?Class> cl = desc.forClass();? ? ? ? ?if (cl != null) {? ? ? ? ? ? ?try {? ? ? ? ? ? ? ? ?@SuppressWarnings("unchecked")? ? ? ? ? ? ? ? ?Enum> en = Enum.valueOf((Class)cl, name);? ? ? ? ? ? ? ? ?result = en;? ? ? ? ? ? } catch (IllegalArgumentException ex) {? ? ? ? ? ? ? ? ?throw (IOException) new InvalidObjectException(? ? ? ? ? ? ? ? ? ? ?"enum constant " + name + " does not exist in " +? ? ? ? ? ? ? ? ? ? ?cl).initCause(ex);? ? ? ? ? ? }? ? ? ? ? ? ?if (!unshared) {? ? ? ? ? ? ? ? ?handles.setObject(enumHandle, result);? ? ? ? ? ? }? ? ? ? }??? ? ? ? ?handles.finish(enumHandle);? ? ? ? ?passHandle = enumHandle;? ? ? ? ?return result;? ? }

我們發現，枚舉類型其實通過類名和類對象類找到一個唯一的枚舉對象。因此，枚舉對象不可能被 類加載器加載多次。那么反射是否能破壞枚舉式單例模式呢？來看一段測試代碼：

? ? ?public static void main(String[] args) {? ? ? ? ?try {? ? ? ? ? ? ?Class clazz = EnumSingleton.class;? ? ? ? ? ? ?Constructor c = clazz.getDeclaredConstructor();? ? ? ? ? ? ?c.newInstance();? ? ? ? } catch (Exception e) {? ? ? ? ? ? ?e.printStackTrace();? ? ? ? }? ? }

運行結果如下圖所示。

結果中報的是 java.lang.NoSuchMethodException異常，意思是沒找到無參的構造方法。這時候， 我們打開 java.lang.Enum的源碼，查看它的構造方法，只有一個protected類型的構造方法，代碼如 下：

? ? ?protected Enum(String name, int ordinal) {? ? ? ? ?this.name = name;? ? ? ? ?this.ordinal = ordinal;? ? }

我們再來做一個下面這樣的測試：

? ? ?public static void main(String[] args) {? ? ? ? ?try {? ? ? ? ? ? ?Class clazz = EnumSingleton.class;? ? ? ? ? ? ?Constructor c = clazz.getDeclaredConstructor(String.class, int.class);? ? ? ? ? ? ?c.setAccessible(true);? ? ? ? ? ? ?EnumSingleton enumSingleton = (EnumSingleton) c.newInstance("Tom", 666);? ? ? ? } catch (Exception e) {? ? ? ? ? ? ?e.printStackTrace();? ? ? ? }? ? }

運行結果如下圖所示

這時錯誤已經非常明顯了，“Cannot reflectively create enum objects”，即不能用反射來創建 枚舉類型。還是習慣性地想來看看JDK源碼，進入Constructor的newInstance()方法：

? ? ?@CallerSensitive? ? ?public T newInstance(Object ... initargs)? ? ? ? ?throws InstantiationException, IllegalAccessException,? ? ? ? ? ? ? ? IllegalArgumentException, InvocationTargetException? ? {? ? ? ? ?if (!override) {? ? ? ? ? ? ?if (!Reflection.quickCheckMemberAccess(clazz, modifiers)) {? ? ? ? ? ? ? ? ?Class> caller = Reflection.getCallerClass();? ? ? ? ? ? ? ? ?checkAccess(caller, clazz, null, modifiers);? ? ? ? ? ? }? ? ? ? }? ? ? ? ?if ((clazz.getModifiers() & Modifier.ENUM) != 0)? ? ? ? ? ? ?throw new IllegalArgumentException("Cannot reflectively create enum objects");? ? ? ? ?ConstructorAccessor ca = constructorAccessor; ? // read volatile? ? ? ? ?if (ca == null) {? ? ? ? ? ? ?ca = acquireConstructorAccessor();? ? ? ? }? ? ? ? ?@SuppressWarnings("unchecked")? ? ? ? ?T inst = (T) ca.newInstance(initargs);? ? ? ? ?return inst;? ? }

從上述代碼可以看到，在 newInstance()方法中做了強制性的判斷，如果修飾符是Modifier.ENUM 枚舉類型，則直接拋出異常。

到此為止，我們是不是已經非常清晰明了呢？枚舉式單例模式也是《EffectiveJava》書中推薦的一種單例模式實現寫法。JDK枚舉的語法特殊性及反射也為枚舉保駕護航，讓枚舉式單例模式成為一種比 較優雅的實現。

枚舉源碼

java.lang.Enum通過valueOf獲得值

? ? ?public static > T valueOf(Class enumType,? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?String name) {? ? ? ? ?T result = enumType.enumConstantDirectory().get(name);? ? ? ? ?if (result != null)? ? ? ? ? ? ?return result;? ? ? ? ?if (name == null)? ? ? ? ? ? ?throw new NullPointerException("Name is null");? ? ? ? ?throw new IllegalArgumentException(? ? ? ? ? ? ?"No enum constant " + enumType.getCanonicalName() + "." + name);? ? }??? ? ?Map enumConstantDirectory() {? ? ? ? ?if (enumConstantDirectory == null) {? ? ? ? ? ? ?T[] universe = getEnumConstantsShared();? ? ? ? ? ? ?if (universe == null)? ? ? ? ? ? ? ? ?throw new IllegalArgumentException(? ? ? ? ? ? ? ? ? ? ?getName() + " is not an enum type");? ? ? ? ? ? ?Map m = new HashMap<>(2 * universe.length);? ? ? ? ? ? ?for (T constant : universe)? ? ? ? ? ? ? ? ?m.put(((Enum>)constant).name(), constant);? ? ? ? ? ? ?enumConstantDirectory = m;? ? ? ? }? ? ? ? ?return enumConstantDirectory;? ? }? ? ?private volatile transient Map enumConstantDirectory = null;

枚舉模式的實例天然具有線程安全性，防止序列化與反射的特性。

有點像餓漢式單例。創建時就將常量存放在map容器中。

優點：寫法優雅。加載時就創建對象。線程安全。

缺點：不能大批量創建對象，否則會造成浪費。spring中不能使用它。

結論：如果不是特別重的對象，建議使用枚舉單例模式，它是JVM天然的單例。

方法2. 容器式單例

Spring改良枚舉寫出的改良方法：IOC容器

接下來看注冊式單例模式的另一種寫法，即容器式單例模式，創建ContainerSingleton類：

?public class ContainerSingleton {??? ? ?private ContainerSingleton(){}??? ? ?private static Map ioc = new ConcurrentHashMap();??? ? ?public static Object getInstance(String className){? ? ? ? ?Object instance = null;? ? ? ? ?if(!ioc.containsKey(className)){? ? ? ? ? ? ?try {? ? ? ? ? ? ? ? ?instance = Class.forName(className).newInstance();? ? ? ? ? ? ? ? ?ioc.put(className, instance);? ? ? ? ? ? }catch (Exception e){? ? ? ? ? ? ? ? ?e.printStackTrace();? ? ? ? ? ? }? ? ? ? ? ? ?return instance;? ? ? ? }else{? ? ? ? ? ? ?return ioc.get(className);? ? ? ? }? ? }?}

測試

?public class ContainerSingletonTest {? ? ?public static void main(String[] args) {? ? ? ? ?Object instance1 = ContainerSingleton.getInstance("com.gupaoedu.vip.pattern.singleton.test.Pojo");? ? ? ? ?Object instance2 = ContainerSingleton.getInstance("com.gupaoedu.vip.pattern.singleton.test.Pojo");? ? ? ? ?System.out.println(instance1 == instance2);? ? }?}

結果

?true

容器式單例模式適用于實例非常多的情況，便于管理。但它是非線程安全的。到此，注冊式單例模式介紹完畢。我們再來看看Spring中的容器式單例模式的實現代碼：

?public abstract class AbstractAutowireCapableBeanFactory extends AbstractBeanFactory? implements AutowireCapableBeanFactory {? ? ?? /** Cache of unfinished FactoryBean instances: FactoryBean name --> BeanWrapper */? private final Map factoryBeanInstanceCache =? new ConcurrentHashMap(16);?}

容器為啥不能被反射破壞？秩序的維護者，創造了一個生態

4.9.線程單例實現ThreadLocal

最后贈送給大家一個彩蛋，講講線程單例實現 ThreadLocal。ThreadLocal 不能保證其創建的對象 是全局唯一的，但是能保證在單個線程中是唯一的，天生是線程安全的。下面來看代碼：

?public class ThreadLocalSingleton {? ? ?private static final ThreadLocal threadLocaLInstance =? ? ? ? ? ? ?new ThreadLocal(){? ? ? ? ? ? ? ? ?@Override? ? ? ? ? ? ? ? ?protected ThreadLocalSingleton initialValue() {? ? ? ? ? ? ? ? ? ? ?return new ThreadLocalSingleton();? ? ? ? ? ? ? ? }? ? ? ? ? ? };??? ? ?private ThreadLocalSingleton(){}??? ? ?public static ThreadLocalSingleton getInstance(){? ? ? ? ?return threadLocaLInstance.get();? ? }?}

寫一下測試代碼：

?public class ThreadLocalSingletonTest {??? ? ?public static void main(String[] args) {? ? ? ? ?System.out.println(ThreadLocalSingleton.getInstance());? ? ? ? ?System.out.println(ThreadLocalSingleton.getInstance());? ? ? ? ?System.out.println(ThreadLocalSingleton.getInstance());? ? ? ? ?System.out.println(ThreadLocalSingleton.getInstance());? ? ? ? ?System.out.println(ThreadLocalSingleton.getInstance());? ? ? ? ?Thread t1 = new Thread(new ExectorThread());? ? ? ? ?Thread t2 = new Thread(new ExectorThread());? ? ? ? ?t1.start();? ? ? ? ?t2.start();? ? ? ? ?System.out.println("End");? ? }?}

運行結果如下圖所示。

?com.gupaoedu.vip.pattern.singleton.threadlocal.ThreadLocalSingleton@1761e840?com.gupaoedu.vip.pattern.singleton.threadlocal.ThreadLocalSingleton@1761e840?com.gupaoedu.vip.pattern.singleton.threadlocal.ThreadLocalSingleton@1761e840?com.gupaoedu.vip.pattern.singleton.threadlocal.ThreadLocalSingleton@1761e840?com.gupaoedu.vip.pattern.singleton.threadlocal.ThreadLocalSingleton@1761e840?End?Thread-0:com.gupaoedu.vip.pattern.singleton.lazy.LazyDoubleCheckSingleton@551f86f1?Thread-1:com.gupaoedu.vip.pattern.singleton.lazy.LazyDoubleCheckSingleton@551f86f1

我們發現，在主線程中無論調用多少次，獲取到的實例都是同一個，都在兩個子線程中分別獲取到 了不同的實例。那么 ThreadLocal是如何實現這樣的效果的呢？我們知道，單例模式為了達到線程安全 的目的，會給方法上鎖，以時間換空間。ThreadLocal 將所有的對象全部放在 ThreadLocalMap 中，為每個線程都提供一個對象，實際上是以空間換時間來實現線程隔離的。

不是線程作為key，而是threadlocal本身。

ThreadLocal源碼

?public T get() {? ? ?Thread t = Thread.currentThread();? ? ?ThreadLocalMap map = getMap(t);? ? ?if (map != null) {? ? ? ? ?ThreadLocalMap.Entry e = map.getEntry(this);? ? ? ? ?if (e != null) {? ? ? ? ? ? ?@SuppressWarnings("unchecked")? ? ? ? ? ? ?T result = (T)e.value;? ? ? ? ? ? ?return result;? ? ? ? }? ? }? ? ?return setInitialValue();?}

5.0.源碼

AbstractFactoryBean

? public final T getObject() throws Exception {? if (isSingleton()) {? return (this.initialized ? this.singletonInstance : getEarlySingletonInstance());? }? else {? return createInstance();? }? }??? private T getEarlySingletonInstance() throws Exception {? Class[] ifcs = getEarlySingletonInterfaces();? if (ifcs == null) {? throw new FactoryBeanNotInitializedException(? getClass().getName() + " does not support circular references");? }? if (this.earlySingletonInstance == null) {? this.earlySingletonInstance = (T) Proxy.newProxyInstance(? this.beanClassLoader, ifcs, new EarlySingletonInvocationHandler());? }? return this.earlySingletonInstance;? }

MyBatis的ErrorContext使用了ThreadLocal

?public class ErrorContext {??? ?private static final ThreadLocal LOCAL = new ThreadLocal<>();??? ?private ErrorContext() {? }??? ?public static ErrorContext instance() {? ? ?ErrorContext context = LOCAL.get();? ? ?if (context == null) {? ? ? ?context = new ErrorContext();? ? ? ?LOCAL.set(context);? ? }? ? ?return context;? }?}

5.0.單例模式小結

單例模式優點：

在內存中只有一個實例，減少了內存開銷。

可以避免資源的多重占用。

設置全局訪問點，嚴格控制訪問。

單例模式的缺點：

沒有接口，擴展困難。

如果要擴展單例對象，只有修改代碼，沒有其他途徑。

學習單例模式的知識重點總結

私有化構造器

保證線程安全

單例模式可以保證內存里只有一個實例，減少了內存的開銷，還可以避免對資源的多重占用。單例模式看起來非常簡單，實現起來其實也非常簡單，但是在面試中卻是一個高頻面試點。希望“小伙伴們” 通過本章的學習，對單例模式有了非常深刻的認識，在面試中彰顯技術深度，提升核心競爭力，給面試 加分，順利拿到錄取通知(Offer)。

5.1.作業

1、解決容器式單例的線程安全問題。

兩種方法：雙重檢查鎖，利用ConcurrentHashMap#putIfAbsent()方法的原子性。

?public class ContainerSingleton {??? ? ?private static Map ioc = new ConcurrentHashMap();??? ? ?private ContainerSingleton() {? ? ? ? ?throw new RuntimeException("不可被實例化！");? ? }??? ? ?// 方法一：雙重檢查鎖? ? ?public static Object getInstance(String className) {? ? ? ? ?Object instance = null;? ? ? ? ?if (!ioc.containsKey(className)) {? ? ? ? ? ? ?synchronized (ContainerSingleton.class) {? ? ? ? ? ? ? ? ?if (!ioc.containsKey(className)) {? ? ? ? ? ? ? ? ? ? ?try {? ? ? ? ? ? ? ? ? ? ? ? ?instance = Class.forName(className).newInstance();? ? ? ? ? ? ? ? ? ? ? ? ?ioc.put(className, instance);? ? ? ? ? ? ? ? ? ? } catch (Exception e) {? ? ? ? ? ? ? ? ? ? ? ? ?e.printStackTrace();? ? ? ? ? ? ? ? ? ? }? ? ? ? ? ? ? ? ? ? ?return instance;? ? ? ? ? ? ? ? } else {? ? ? ? ? ? ? ? ? ? ?return ioc.get(className);? ? ? ? ? ? ? ? }? ? ? ? ? ? }? ? ? ? }? ? ? ? ?return ioc.get(className);? ? }??? ? ?// 方法二：利用ConcurrentHashMap#putIfAbsent()方法的原子性? ? ?public static Object getInstance1(String className){? ? ? ? ?Object instance = null;? ? ? ? ?try {? ? ? ? ? ? ?ioc.putIfAbsent(className, Class.forName(className).newInstance());? ? ? ? }catch (Exception e){? ? ? ? ? ? ?e.printStackTrace();? ? ? ? }? ? ? ? ?return ioc.get(className);? ? }?} 《新程序員》：云原生和全面數字化實踐50位技術專家共同創作，文字、視頻、音頻交互閱讀

總結

以上是生活随笔為你收集整理的以下属于单例模式的优点的是_三、单例模式详解的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。