教你java面試時如何聊單例模式

更新時間：2021年06月30日 15:16:21 作者：IT楓斗者

這篇文章主要給大家介紹了關(guān)于Java單例模式推薦的幾種模式，文中通過示例代碼介紹的非常詳細，對大家學(xué)習(xí)或者使用Java具有一定的參考學(xué)習(xí)價值，需要的朋友們下面來一起學(xué)習(xí)學(xué)習(xí)吧

NO.1 單例模式的應(yīng)用場景

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

NO.2 餓漢式單例

先來看單例模式的類結(jié)構(gòu)圖：

餓漢式單例是在類加載的時候就立即初始化，并且創(chuàng)建單例對象。絕對線程安全，在線程還沒出現(xiàn)以前就是實例化了，不可能存在訪問安全問題。

優(yōu)點：沒有加任何的鎖、執(zhí)行效率比較高，在用戶體驗上來說，比懶漢式更好。

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

Spring 中 IOC 容器 ApplicationContext 本身就是典型的餓漢式單例。接下來看一段代碼：

public class HungrySingleton {
     //先靜態(tài)、后動態(tài)
     //先屬性、后方法
     //先上后下
     private static final HungrySingleton hungrySingleton = new HungrySingleton();
     private HungrySingleton(){}
     public static HungrySingleton getInstance(){
         return hungrySingleton;
     }
}

還有另外一種寫法，利用靜態(tài)代碼塊的機制：

//餓漢式靜態(tài)塊單例
public class HungryStaticSingleton {
    private static final HungryStaticSingleton hungrySingleton;
    static {
        hungrySingleton = new HungryStaticSingleton();
    }
    private HungryStaticSingleton(){}
    public static HungryStaticSingleton getInstance(){
        return hungrySingleton;
    }
}

這兩種寫法都非常的簡單，也非常好理解，餓漢式適用在單例對象較少的情況。下面我們來看性能更優(yōu)的寫法。

NO.3 懶漢式單例

懶漢式單例的特點是：被外部類調(diào)用的時候內(nèi)部類才會加載，下面看懶漢式單例的簡單實現(xiàn) LazySimpleSingleton：

//懶漢式單例
//在外部需要使用的時候才進行實例化
public class LazySimpleSingleton {
    private LazySimpleSingleton(){}
    //靜態(tài)塊，公共內(nèi)存區(qū)域
    private static LazySimpleSingleton lazy = null;
    public static LazySimpleSingleton getInstance(){
        if(lazy == null){
        lazy = new LazySimpleSingleton();
         }
        return lazy;
    }
}

然后寫一個線程類 ExectorThread 類：

public class ExectorThread implements Runnable{
    @Override
    public void run() {
        LazySimpleSingleton singleton = LazySimpleSingleton.getInstance();
        System.out.println(Thread.currentThread().getName() + ":" + singleton);
    }
}

客戶端測試代碼：

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");
    }
}

運行結(jié)果：

一定幾率出現(xiàn)創(chuàng)建兩個不同結(jié)果的情況，意味著上面的單例存在線程安全隱患?，F(xiàn)在我們用調(diào)試運行再具體看一下，教給大家一個新技能，用線程模式調(diào)試，手動控制線程的執(zhí)行順序來跟蹤內(nèi)存的變化狀態(tài)。先給 ExectorThread 類打上斷點：

右鍵點擊斷點，切換為 Thread 模式，如下圖：

然后，給 LazySimpleSingleton 類打上斷點，同樣標記為 Thread 模式：

切回到客戶端測試代碼，同樣也打上斷點，同時改為 Thread 模式，如下圖:

開始 debug 之后，會看到 debug 控制臺可以自由切換 Thread 的運行狀態(tài)：

通過不斷切換線程，并觀測其內(nèi)存狀態(tài)，我們發(fā)現(xiàn)在線程環(huán)境下 LazySimpleSingleton被實例化了兩次。有時，我們得到的運行結(jié)果可能是相同的兩個對象，實際上是被后面執(zhí)行的線程覆蓋了，我們看到了一個假象，線程安全隱患依舊存在。那么，我們?nèi)绾蝸韮?yōu)化代碼，使得懶漢式單例在線程環(huán)境下安全呢？來看下面的代碼，給 getInstance()加上 synchronized 關(guān)鍵字，是這個方法變成線程同步方法：

public class LazySimpleSingleton {
  private LazySimpleSingleton(){}
  //靜態(tài)塊，公共內(nèi)存區(qū)域
  private static LazySimpleSingleton lazy = null;
  public synchronized static LazySimpleSingleton getInstance(){
    if(lazy == null){
    lazy = new LazySimpleSingleton();
    }
    return lazy;
  }
}

這時候，我們再來調(diào)試。當我們將其中一個線程執(zhí)行并調(diào)用 getInstance()方法時，另一個線程在調(diào)用 getInstance()方法，線程的狀態(tài)由 RUNNING 變成了 MONITOR,出現(xiàn)阻塞。直到第一個線程執(zhí)行完，第二個線程才恢復(fù) RUNNING 狀態(tài)繼續(xù)調(diào)用 getInstance()方法。如下圖所示：

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

public class LazyDoubleCheckSingleton {
    private volatile static LazyDoubleCheckSingleton lazy = null;
    private LazyDoubleCheckSingleton(){}
      public static LazyDoubleCheckSingleton getInstance(){            
if(lazy == null){
               synchronized (LazyDoubleCheckSingleton.class){
                if(lazy == null){
                    lazy = new LazyDoubleCheckSingleton();                    
                    //1.分配內(nèi)存給這個對象
                    //2.初始化對象
                    //3.設(shè)置 lazy 指向剛分配的內(nèi)存地址                }
            }
      }
      return lazy;
    }
}

現(xiàn)在，我們來斷點調(diào)試：

當?shù)谝粋€線程調(diào)用 getInstance()方法時，第二個線程也可以調(diào)用 getInstance()。當?shù)谝粋€線程執(zhí)行到 synchronized 時會上鎖，第二個線程就會變成 MONITOR 狀態(tài)，出現(xiàn)阻

塞。此時，阻塞并不是基于整個 LazySimpleSingleton 類的阻塞，而是在 getInstance()方法內(nèi)部阻塞，只要邏輯不是太復(fù)雜，對于調(diào)用者而言感知不到。但是，用到 synchronized 關(guān)鍵字，總歸是要上鎖，對程序性能還是存在一定影響的。難道就真的沒有更好的方案嗎？當然是有的。我們可以從類初始化角度來考慮，看下面的代碼，采用靜態(tài)內(nèi)部類的方式：

//這種形式兼顧餓漢式的內(nèi)存浪費，也兼顧synchronized性能問題
//完美地屏蔽了這兩個缺點
public class LazyInnerClassSingleton {
 //默認使用LazyInnerClassGeneral的時候，會先初始化內(nèi)部類
 //如果沒使用的話，內(nèi)部類是不加載的
    private LazyInnerClassSingleton(){}
 //每一個關(guān)鍵字都不是多余的
 //static 是為了使單例的空間共享
 //保證這個方法不會被重寫，重載
 public static final LazyInnerClassSingleton getInstance(){
 //在返回結(jié)果以前，一定會先加載內(nèi)部類
 return LazyHolder.LAZY;
 }

 //默認不加載
 private static class LazyHolder{
 private static final LazyInnerClassSingleton LAZY = new LazyInnerClassSingleton();
 }
}

這種形式兼顧餓漢式的內(nèi)存浪費，也兼顧 synchronized 性能問題。內(nèi)部類一定是要在方

法調(diào)用之前初始化，巧妙地避免了線程安全問題。由于這種方式比較簡單，我們就不帶

大家一步一步調(diào)試了。

NO.4 反射破壞單例

大家有沒有發(fā)現(xiàn)，上面介紹的單例模式的構(gòu)造方法除了加上 private 以外，沒有做任何處理。如果我們使用反射來調(diào)用其構(gòu)造方法，然后，再調(diào)用 getInstance()方法，應(yīng)該就會兩個不同的實例?，F(xiàn)在來看一段測試代碼，以 LazyInnerClassSingleton 為例：

public class LazyInnerClassSingletonTest {

    public static void main(String[] args) {
        try{
            //很無聊的情況下，進行破壞
            Class<?> clazz = LazyInnerClassSingleton.class;

            //通過反射拿到私有的構(gòu)造方法
            Constructor c = clazz.getDeclaredConstructor(null);
            //強制訪問，強吻，不愿意也要吻
            c.setAccessible(true);

            //暴力初始化
            Object o1 = c.newInstance();

            //調(diào)用了兩次構(gòu)造方法，相當于new了兩次
            //犯了原則性問題，
            Object o2 = c.newInstance();

            System.out.println(o1 == o2);
//            Object o2 = c.newInstance();
        }catch (Exception e){
            e.printStackTrace();
        }
    }
}

運行結(jié)果如下：

顯然，是創(chuàng)建了兩個不同的實例?，F(xiàn)在，我們在其構(gòu)造方法中做一些限制，一旦出現(xiàn)多次重復(fù)創(chuàng)建，則直接拋出異常。來看優(yōu)化后的代碼：

碼：
//這種形式兼顧餓漢式的內(nèi)存浪費，也兼顧synchronized性能問題
//完美地屏蔽了這兩個缺點
//史上最牛B的單例模式的實現(xiàn)方式
public class LazyInnerClassSingleton {
    //默認使用LazyInnerClassGeneral的時候，會先初始化內(nèi)部類
    //如果沒使用的話，內(nèi)部類是不加載的
    private LazyInnerClassSingleton(){
        if(LazyHolder.LAZY != null){
            throw new RuntimeException("不允許創(chuàng)建多個實例");
        }
    }
    //每一個關(guān)鍵字都不是多余的
    //static 是為了使單例的空間共享
    //保證這個方法不會被重寫，重載
    public static final LazyInnerClassSingleton getInstance(){
        //在返回結(jié)果以前，一定會先加載內(nèi)部類
        return LazyHolder.LAZY;
    }
    //默認不加載
    private static class LazyHolder{
        private static final LazyInnerClassSingleton LAZY = new LazyInnerClassSingleton();
    }
}

再運行測試代碼，會得到以下結(jié)果：

至此，史上最牛 B 的單例寫法便大功告成。

NO.5 序列化破壞單例

當我們將一個單例對象創(chuàng)建好，有時候需要將對象序列化然后寫入到磁盤，下次使用時再從磁盤中讀取到對象，反序列化轉(zhuǎn)化為內(nèi)存對象。反序列化后的對象會重新分配內(nèi)存，即重新創(chuàng)建。那如果序列化的目標的對象為單例對象，就違背了單例模式的初衷，相當于破壞了單例，來看一段代碼：

//反序列化時導(dǎo)致單例破壞
public class SeriableSingleton implements Serializable {
     //序列化就是說把內(nèi)存中的狀態(tài)通過轉(zhuǎn)換成字節(jié)碼的形式
     //從而轉(zhuǎn)換一個 IO 流，寫入到其他地方(可以是磁盤、網(wǎng)絡(luò) IO)
     //內(nèi)存中狀態(tài)給永久保存下來了
     //反序列化
     //講已經(jīng)持久化的字節(jié)碼內(nèi)容，轉(zhuǎn)換為 IO 流
     //通過 IO 流的讀取，進而將讀取的內(nèi)容轉(zhuǎn)換為 Java 對象
     //在轉(zhuǎn)換過程中會重新創(chuàng)建對象 new
     public final static SeriableSingleton INSTANCE = new SeriableSingleton();
     private SeriableSingleton(){}
     public static SeriableSingleton getInstance(){
     return INSTANCE;
 }
}

運行結(jié)果：

運行結(jié)果中，可以看出，反序列化后的對象和手動創(chuàng)建的對象是不一致的，實例化了兩次，違背了單例的設(shè)計初衷。那么，我們?nèi)绾伪ＷC序列化的情況下也能夠?qū)崿F(xiàn)單例？其實很簡單，只需要增加 readResolve()方法即可。來看優(yōu)化代碼：

public class SeriableSingleton implements Serializable {

    //序列化就是說把內(nèi)存中的狀態(tài)通過轉(zhuǎn)換成字節(jié)碼的形式
    //從而轉(zhuǎn)換一個IO流，寫入到其他地方(可以是磁盤、網(wǎng)絡(luò)IO)
    //內(nèi)存中狀態(tài)給永久保存下來了
    //反序列化
    //講已經(jīng)持久化的字節(jié)碼內(nèi)容，轉(zhuǎn)換為IO流
    //通過IO流的讀取，進而將讀取的內(nèi)容轉(zhuǎn)換為Java對象
    //在轉(zhuǎn)換過程中會重新創(chuàng)建對象new
    public  final static SeriableSingleton INSTANCE = new SeriableSingleton();
    private SeriableSingleton(){}
    public static SeriableSingleton getInstance(){
        return INSTANCE;
    }
    private  Object readResolve(){
        return  INSTANCE;
    }
}

再看運行結(jié)果：

大家一定會關(guān)心這是什么原因呢？為什么要這樣寫？看上去很神奇的樣子，也讓人有些費解。不如，我們一起來看看 JDK 的源碼實現(xiàn) 以一清二楚了。我們進入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();
        }
    }
}

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

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

我們看到 TC_OBJECTD 中判斷，調(diào)用了 ObjectInputStream 的 readOrdinaryObject()方法，我們繼續(xù)進入看源碼：

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;
}

發(fā)現(xiàn)調(diào)用了 ObjectStreamClass 的 isInstantiable()方法，而 isInstantiable()里面的代碼如下：

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

代碼非常簡單，就是判斷一下構(gòu)造方法是否為空，構(gòu)造方法不為空就返回 true。意味著，只要有無參構(gòu)造方法就會實例化。這時候，其實還沒有找到為什么加上 readResolve()方法就避免了單例被破壞的真正原因。我再回到ObjectInputStream 的 readOrdinaryObject()方法繼續(xù)往下看：

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;
}

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

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

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

readResolveMethod = getInheritableMethod(
    cl, "readResolve", null, Object.class);

上面的邏輯其實就是通過反射找到一個無參的 readResolve()方法，并且保存下來?，F(xiàn)在

再回到 ObjectInputStream的 readOrdinaryObject() 方法繼續(xù) 往下看，如果

readResolve()存在則調(diào)用 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()方法中用反射調(diào)用了readResolveMethod方法。通過 JDK 源碼分析我們可以看出，雖然，增加 readResolve()方法返回實例，解決了單例被破壞的問題。但是，我們通過分析源碼以及調(diào)試，我們可以看到實際上實例化了兩次，只不過新創(chuàng)建的對象沒有被返回而已。那如果，創(chuàng)建對象的動作發(fā)生頻率增大，就意味著內(nèi)存分配開銷也就隨之增大，難道真的就沒辦法從根本上解決問題嗎？下面我們來注冊式單例也許能幫助到你

NO.6 注冊式單例

注冊式單例又稱為登記式單例，就是將每一個實例都登記到某一個地方，使用唯一的標識獲取實例。注冊式單例有兩種寫法：一種為容器緩存，一種為枚舉登記。先來看枚舉式單例的寫法，來看代碼，創(chuàng)建 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();
         }
      }
}

運行結(jié)果：

沒有做任何處理，我們發(fā)現(xiàn)運行結(jié)果和我們預(yù)期的一樣。那么枚舉式單例如此神奇，的神秘之處在哪里體現(xiàn)呢？下面我們通過分析源碼來揭開它的神秘面紗。下載一個非常好用的 Java 反編譯工具 Jad（下載地址：https://varaneckas.com/jad/），解壓后配置好環(huán)境變量（這里不做詳細介紹），就可以使用命令行調(diào)用了。找到工程所在的 class 目錄，復(fù)制 EnumSingleton.class 所在的路徑，如下圖：

然后切回到命令行，切換到工程所在的 Class 目錄，輸入命令 jad 后面輸入復(fù)制好的路徑，我們會在 Class 目錄下會多一個 EnumSingleton.jad 文件。打開 EnumSingleton.jad文件我們驚奇又巧妙地發(fā)現(xiàn)有如下代碼：

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

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

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

我們看到在 readObject0()中調(diào)用了 readEnum()方法，來看 readEnum()中代碼實現(xiàn)：

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;
}

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

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

運行結(jié)果：

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

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();
    }
}

運行結(jié)果：

這時錯誤已經(jīng)非常明顯了，告訴我們 Cannot reflectively create enum objects，不能用反射來創(chuàng)建枚舉類型。還是習(xí)慣性地想來看看 JDK 源碼，進入 Constructor 的newInstance()方法：

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 枚舉類型，直接拋出異常。到這為止，我們是不是已經(jīng)非常清晰明了呢？枚舉式單例也是《EffectiveJava》書中推薦的一種單例實現(xiàn)寫法。在 JDK 枚舉的語法特殊性，以及反射也為枚舉保駕護航，讓枚舉式單例成為一種比較優(yōu)雅的實現(xiàn)。

接下來看注冊式單例還有另一種寫法，容器緩存的寫法，創(chuàng)建 ContainerSingleton 類：

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

容器式寫法適用于創(chuàng)建實例非常多的情況，便于管理。但是，是非線程安全的。到此，注冊式單例介紹完畢。我們還可以來看看 Spring 中的容器式單例的實現(xiàn)代碼：

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

NO.7 ThreadLocal 線程單例

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

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 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");
}

運行結(jié)果：

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

總結(jié)

單例模式可以保證內(nèi)存里只有一個實例，減少了內(nèi)存開銷；可以避免對資源的多重占用。單例模式看起來非常簡單，實現(xiàn)起來其實也非常簡單。但是在面試中卻是一個高頻面試題。希望小伙伴們通過本章的學(xué)習(xí)，可以對您有所幫助，希望您可以多多關(guān)注腳本之家的更多內(nèi)容！

您可能感興趣的文章: