三、單例模式詳解

来源:https://www.cnblogs.com/amiaojiang/archive/2020/02/27/12374489.html
-Advertisement-
Play Games

4.單例模式詳解 4.1.課程目標 1、掌握單例模式的應用場景。 2、掌握IDEA環境下的多線程調試方式。 3、掌握保證線程安全的單例模式策略。 4、掌握反射暴力攻擊單例解決方案及原理分析。 5、序列化破壞單例的原理及解決方案。 6、掌握常見的單例模式寫法。 4.2.內容定位 1、聽說過單例模式，但 ...


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()方法

線程切換調試

image-20200227132959169

上圖完美地展現了 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();
        }
    }

運行結果如下圖所示。

image-20200227191227392

結果中報的是 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();
        }
    }

運行結果如下圖所示

image-20200227191559008

這時錯誤已經非常明顯了，“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 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 AbstractBeanFactory
        implements 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>(){
                @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<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.單例模式小結

單例模式優點：

  1. 在記憶體中只有一個實例，減少了記憶體開銷。
  2. 可以避免資源的多重占用。
  3. 設置全局訪問點，嚴格控制訪問。

單例模式的缺點：

  1. 沒有介面，擴展困難。
  2. 如果要擴展單例對象，只有修改代碼，沒有其他途徑。

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

  1. 私有化構造器
  2. 保證線程安全

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

您的分享是我們最大的動力!

-Advertisement-
Play Games
更多相關文章
  • 一篇文章帶你搞定 ElasticSearch 術語
    這篇文章主要介紹 ElasticSearch 的基本概念，學習文檔、索引、集群、節點、分片等概念，同時會將 ElasticSearch 和關係型資料庫做簡單的類比，還會簡單介紹 REST API 的使用用法。 ElasticSearch 術語 索引和文檔是偏向於邏輯上的概念，節點和分片更偏向於物理上 ...
  • java開發JSP+Servlet+bootstrap開發電影院購票系統 源碼
    基於JSP+Servlet+bootstrap開發電影院購票系統：開發環境: Windows操作系統開發工具： MyEclipse+Jdk+Tomcat+Mysql資料庫 程式要求：電影院訂票系統 用戶信息管理：用戶註冊後，可修改個人信息、登錄密碼等 影片分類：對影片進行分類，按類型、國家區域分類， ...
  • java開發學生信息管理系統 源碼
    開發環境: Windows操作系統開發工具： Eclipse+Jdk+Tomcat+MYSQL資料庫運行效果圖 源碼及原文鏈接：https://javadao.xyz/forum.php?mod=viewthread&tid=53 ...
  • Spring Data Redis
    關註公眾號：CoderBuff，回覆“redis”獲取《Redis5.x入門教程》完整版PDF。 《Redis5.x入門教程》目錄 "第一章 · 準備工作" "第二章 · 數據類型" "第三章 · ​命令" "第四章 ​· 配置" "第五章 · Java客戶端（上）" "第六章 · 事務" "第七章 ...
  • Java自學-多線程 同步synchronized
    Java 多線程同步 synchronized 多線程的同步問題指的是多個線程同時修改一個數據的時候，可能導致的問題 多線程的問題，又叫 Concurrency 問題 步驟 1 : 演示同步問題 假設蓋倫有10000滴血，並且在基地里，同時又被對方多個英雄攻擊 就是有 多個線程在減少蓋倫的hp 同時 ...
  • 初識matlab
    1 matlab概貌 MATLAB是MATrix LABoratory（矩陣實驗室）的縮寫，是一款由美國The MathWorks公司出品的商業數學軟體。matlab是一種用於演算法開發、數據可視化、數據分析以及數值計算的高級技術計算語言和互動式環境。除了矩陣運算、繪製函數/數據圖像等常用功能外，ma ...
  • 【演算法】 藍橋杯 高精度加法
    問題描述 輸入兩個整數a和b，輸出這兩個整數的和。a和b都不超過100位。 演算法描述 由於a和b都比較大，所以不能直接使用語言中的標準數據類型來存儲。對於這種問題，一般使用數組來處理。定義一個數組A，A[0]用於存儲a的個位，A[1]用於存儲a的十位，依此類推。同樣可以用一個數組B來存儲b。計算c  ...
  • python基礎入門之四 —— 列表
    1、格式 [數據1,數據2,數據3,...] 列表可以一次性存多個數據，可以為不同的數據類型 2、下標 從0開始循序向下分配 3、常用函數 查找 index():返回指定數據所在位置下標,不存在就報錯 count():返回某個字串在字元串中出現的次數 len():返回列表列表中的數據個數 name= ...
一周排行
    -Advertisement-
    Play Games
  • 移動開發（一）：使用.NET MAUI開發第一個安卓APP
    移動開發（一）：使用.NET MAUI開發第一個安卓APP 對於工作多年的C#程式員來說，近來想嘗試開發一款安卓APP，考慮了很久最終選擇使用.NET MAUI這個微軟官方的框架來嘗試體驗開發安卓APP，畢竟是使用Visual Studio開發工具，使用起來也比較的順手，結合微軟官方的教程進行了安卓 ...
  • wpf ToggleButton選中效果和一個登錄界面
    前言 QuestPDF 是一個開源 .NET 庫，用於生成 PDF 文檔。使用了C# Fluent API方式可簡化開發、減少錯誤並提高工作效率。利用它可以輕鬆生成 PDF 報告、發票、導出文件等。 項目介紹 QuestPDF 是一個革命性的開源 .NET 庫，它徹底改變了我們生成 PDF 文檔的方 ...
  • 彈幕樹洞項目功能新增篇
    項目地址 項目後端地址： https://github.com/ZyPLJ/ZYTteeHole 項目前端頁面地址： ZyPLJ/TreeHoleVue (github.com) https://github.com/ZyPLJ/TreeHoleVue 目前項目測試訪問地址： http://tree ...
  • 第27篇 sqlserver2022詳細安裝步驟
    話不多說，直接開乾 一.下載 1.官方鏈接下載： https://www.microsoft.com/zh-cn/sql-server/sql-server-downloads 2.在下載目錄中找到下麵這個小的安裝包 SQL2022-SSEI-Dev.exe，運行開始下載SQL server； 二. ...
  • .NET 開源高性能 MQTT 類庫
    前言 隨著物聯網（IoT）技術的迅猛發展，MQTT（消息隊列遙測傳輸）協議憑藉其輕量級和高效性，已成為眾多物聯網應用的首選通信標準。 MQTTnet 作為一個高性能的 .NET 開源庫，為 .NET 平臺上的 MQTT 客戶端與伺服器開發提供了強大的支持。 本文將全面介紹 MQTTnet 的核心功能 ...
  • Serilog文檔翻譯系列（六） - 可用的接收器、增強器、格式化輸出
    Serilog支持多種接收器用於日誌存儲，增強器用於添加屬性，LogContext管理動態屬性，支持多種輸出格式包括純文本、JSON及ExpressionTemplate。還提供了自定義格式化選項，適用於不同需求。 ...
  • 警惕 Visual Studio 屬性求值副作用導致邏輯不符合預期
    目錄簡介獲取 HTML 文檔解析 HTML 文檔測試參考文章 簡介 動態內容網站使用 JavaScript 腳本動態檢索和渲染數據，爬取信息時需要模擬瀏覽器行為，否則獲取到的源碼基本是空的。 本文使用的爬取步驟如下： 使用 Selenium 獲取渲染後的 HTML 文檔 使用 HtmlAgility ...
  • [使用目前最新版]HybridCLR6.9.0+YooAsset2.2.4實現純C# Unity熱更新方案 (一)
    1.前言 什麼是熱更新 游戲或者軟體更新時，無需重新下載客戶端進行安裝，而是在應用程式啟動的情況下，在內部進行資源或者代碼更新 Unity目前常用熱更新解決方案 HybridCLR，Xlua，ILRuntime等 Unity目前常用資源管理解決方案 AssetBundles，Addressable， ...
  • 在 ASP.NET Core Web API 中使用操作篩選器統一處理通用操作
    本文章主要是在C# ASP.NET Core Web API框架實現向手機發送驗證碼簡訊功能。這裡我選擇是一個互億無線簡訊驗證碼平臺，其實像阿裡雲，騰訊雲上面也可以。 首先我們先去 互億無線 https://www.ihuyi.com/api/sms.html 去註冊一個賬號 註冊完成賬號後，它會送 ...
  • 第28篇 如何.net中實現高效可靠數據同步api
    通過以下方式可以高效，並保證數據同步的可靠性 1.API設計 使用RESTful設計，確保API端點明確，並使用適當的HTTP方法（如POST用於創建，PUT用於更新）。 設計清晰的請求和響應模型，以確保客戶端能夠理解預期格式。 2.數據驗證 在伺服器端進行嚴格的數據驗證，確保接收到的數據符合預期格 ...
所有分類