當前位置：首頁 > 编程资源 > 编程问答 >内容正文

编程问答

单例模式应用场景_三、单例模式详解

發布時間：2025/4/5 编程问答 16 豆豆

生活随笔收集整理的這篇文章主要介紹了单例模式应用场景_三、单例模式详解小編覺得挺不錯的,現在分享給大家,幫大家做個參考.

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;?//裝個Bstatic {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.classLazyStaticInnerClassSingleton$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@64cee07com.gupaoedu.vip.pattern.singleton.lazy.LazyStaticInnerClassSingleton@1761e840false

大家有沒有發現，上面介紹的單例模式的構造方法除了加上 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@68837a77com.gupaoedu.vip.pattern.singleton.seriable.SeriableSingleton@4b6995dffalse

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

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

com.gupaoedu.vip.pattern.singleton.seriable.SeriableSingleton@4b6995dfcom.gupaoedu.vip.pattern.singleton.seriable.SeriableSingleton@4b6995dftrue

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

public final Object readObject()throws IOException, ClassNotFoundException{if (enableOverride) {return readObjectOverride();}?// if nested read, passHandle contains handle of enclosing objectint 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()方法，看源碼：

我們發現調用了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 objectif (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 suppressedthrow 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) {try {EnumSingleton instance1 = null;EnumSingleton instance2 = EnumSingleton.getInstance();instance2.setData(new Object());FileOutputStream fos = new FileOutputStream("EnumSingleton.obj");ObjectOutputStream oos = new ObjectOutputStream(fos);oos.writeObject(instance2);oos.flush();oos.close();FileInputStream fis = new FileInputStream("EnumSingleton.obj");ObjectInputStream ois = new ObjectInputStream(fis);instance1 = (EnumSingleton) ois.readObject();ois.close();System.out.println(instance1.getData());System.out.println(instance2.getData());System.out.println(instance1.getData() == instance2.getData());} catch (Exception e) {e.printStackTrace();}} }java.lang.Object@2acf57e3java.lang.Object@2acf57e3true

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

下載一個非常好用的 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()方法：

@CallerSensitivepublic 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 volatileif (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 extends Enum<T>> T valueOf(Class<T> 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<String, T> enumConstantDirectory() {if (enumConstantDirectory == null) {T[] universe = getEnumConstantsShared();if (universe == null)throw new IllegalArgumentException(getName() + " is not an enum type");Map<String, T> m = new HashMap<>(2 * universe.length);for (T constant : universe)m.put(((Enum<?>)constant).name(), constant);enumConstantDirectory = m;}return enumConstantDirectory;}private volatile transient Map<String, T> enumConstantDirectory = null;

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

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

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

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

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

方法2. 容器式單例

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

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

public class ContainerSingleton {?private ContainerSingleton(){}?private static Map<String,Object> ioc = new ConcurrentHashMap<String, Object>();?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 AbstractBeanFactoryimplements AutowireCapableBeanFactory {/** Cache of unfinished FactoryBean instances: FactoryBean name --> BeanWrapper */private final Map<String, BeanWrapper> factoryBeanInstanceCache =new ConcurrentHashMap<String, BeanWrapper>(16);}

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

4.9.線程單例實現ThreadLocal

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

public class ThreadLocalSingleton {private static final ThreadLocal<ThreadLocalSingleton> threadLocaLInstance =new ThreadLocal<ThreadLocalSingleton>(){@Overrideprotected 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@1761e840com.gupaoedu.vip.pattern.singleton.threadlocal.ThreadLocalSingleton@1761e840com.gupaoedu.vip.pattern.singleton.threadlocal.ThreadLocalSingleton@1761e840com.gupaoedu.vip.pattern.singleton.threadlocal.ThreadLocalSingleton@1761e840com.gupaoedu.vip.pattern.singleton.threadlocal.ThreadLocalSingleton@1761e840EndThread-0:com.gupaoedu.vip.pattern.singleton.lazy.LazyDoubleCheckSingleton@551f86f1Thread-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<ErrorContext> 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<String, Object> ioc = new ConcurrentHashMap<String, Object>();?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);}}

總結

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

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

上一篇：豪沃重汽变速副箱油后面的油管起什么作用
下一篇： spring boot 邮件端口_不会吧