2. 程式人生 > >單例模式個人整理

單例模式個人整理

阿新 • • 發佈：2018-11-05

單例模式

本次簡單的講一下單例模式.在講的過程中,筆者會盡量把這個模式講清楚,講詳細,講簡單.同時也會給出目前使用單例模式的例子,並分析這些案例的實現方式.在這個過程中,你會發現,小小的單例模式裡卻有著很大的學問在.

單例模式是為了保證在一個jvm環境下,一個類僅有一個物件.一般來說,每講到單例模式,大家都會想起各種實現方式(比如:懶漢式,餓漢式),這些實現方式,是通過程式碼的設計來強制保證的單例,可以稱為強制性單例模式.當然,通過文件,通過編碼約束,也可以認為是實現了一個類僅有一個物件的效果.

通常,專案中的具有連線功能的類(比如:資料庫連線,網路連線,印表機的連線),具有配置功能的類,工具類,輔助系統類,會需要使用單例模式.這些類大多是建立和銷燬需要消耗大量的系統資源,或者不需要建立多個物件(物件之間無差別).

在Java中,建立單例模式都有兩個必不可少的步驟

  1. 私有化類的所有建構函式,以阻止其他程式碼在該類的外界去建立物件,
  2. 提供獲取該物件的靜態方法,以返回該類唯一的物件引用.

基於以上兩條,可以簡單寫出三種單例模式:

第一種寫法:通過類的靜態變數來持有一個該類的物件的引用,同時使用final關鍵字來阻止其被再次賦值.

public class Singleton1 {
    private static final Singleton1 INSTANCE = new Singleton1();
 private Singleton1(){}
    public static
 
 Singleton1 getInstance(){
        return INSTANCE;
  }
}
複製程式碼

第二種寫法:這種方法和第一種方法大同小異,同樣是使用靜態變數維護該類的引用,但將物件建立的放在了靜態程式碼塊中.

public class Singleton2 {
    private static final Singleton2 INSTANCE ;
    static {
        INSTANCE=new Singleton2();
    }
    private Singleton2(){}
    public static Singleton2 getInstance
 
(){
        return INSTANCE;
    }
}

複製程式碼

第三種寫法:使用靜態變數維持類的物件的引用(這種情況下,由於java語法的限制,將無法使用final關鍵字),在獲取物件的方法裡對物件進行判斷和建立.

public class Singleton3 {
    private static Singleton3 instance;
 private Singleton3(){}

    public static Singleton3 getInstance() {
        if(null==instance){
            instance=new Singleton3();
  }
        return instance;
  }
}
複製程式碼

前兩種,將物件的建立時機放在了類的初始化階段,後面一種,則將物件的建立放在了類的使用階段.前兩種被稱為餓漢式,第三種被稱為懶漢式.餓漢式的優點是簡單易懂,缺點是沒有達到懶載入的效果。如果從始至終從未使用過這個例項,就會比較浪費連線資源和記憶體.

但懶漢式也並不複雜,可以起到懶載入的效果.於是,讀者可能更願意使用懶漢式,或者其變種(比如具有雙重檢查鎖的懶漢式).你的理由是,節省記憶體,懶載入,而且還很酷.

但事實又是如何呢?為了弄清楚這兩種單例方式,需要簡單回憶一下類的生命週期.

  1. 類的載入:將類的位元組碼檔案(.class檔案)從硬碟載入方法區的過程
  2. 類的連線:該過程由三個部分組成:驗證、準備和解析,
  3. 類的初始化:將靜態變數賦值,執行的順序就是： 父類靜態變數->靜態程式碼塊->子類靜態變數->子類靜態程式碼塊,餓漢式的物件建立處於這個階段
  4. 類的使用,如類的例項化,懶漢式的物件建立處於這個階段,new關鍵字可以觸發該生命週期
  5. 類解除安裝

那麼問題來了,什麼時候會對類進行初始化呢?根據類的五個生命週期階段,我們只需要驗證在建立物件之前的那些操作能夠觸發類的初始化就行.筆者使用jdk1.8,預設配置,進行了簡單的實驗.首先在構造方法裡新增列印語句,列印“init”,然後再新增一個靜態方法和一個靜態變數.對Singleton1進行檢驗.

public class Singleton1 {
  private static final Singleton1 INSTANCE = new Singleton1();
  //新增列印語句
  private Singleton1(){
        System.out.println("init");
  }
  public static Singleton1 getInstance(){
        return INSTANCE;
  }
    //靜態方法
  public static final void otherMethod(){
    }
    //靜態變數
  public static final int staticFiled=0; 
 }

複製程式碼

測試1:僅僅進行宣告

//測試1: 
public class Test {
    public static void main(String[] args) {
        System.out.println("-------start-------");
        Singleton1 singleton1 = null;
        if(null==singleton1){
            System.out.println("singleton1 is null");
  }
        System.out.println("-------end-------");
  }

    /* out:
     * -------start------- 
     * singleton1 is null 
     * -------end--------- 
     */ 
}
複製程式碼

從輸出上看,僅僅宣告,不會觸發類的初始化階段. 測試2:呼叫類的靜態變數

//測試2: 
public class Test {
    public static void main(String[] args) {
      System.out.println("-------start-------");
      System.out.println(Singleton1.staticFiled);
      System.out.println("-------end---------");
  }

    /* out:
     *-------start-------
     *0
     *-------end--------- 
     */ }
複製程式碼

從輸出上看,僅僅呼叫類的靜態變數,不會觸發類的初始化階段. 測試3:呼叫類的靜態方法

//測試3 
public class Test {
    public static void main(String[] args) {
        System.out.println("-------start-------");
        Singleton1.otherMethod();
        System.out.println("-------end-------");
  }

    /* out:
     *-------start------- 
     *   init 
     *-------end------- 
     */ 
}
複製程式碼

從輸出上看,僅僅呼叫類的靜態方法,會觸發類的初始化階段.

通過上面的三個例子,可以看出餓漢式,在某種情況下,也是可以表現出懶載入的效果,並且餓漢式簡單,而且不會產生執行緒安全的問題,在某些情況下是可以代替懶漢式的.並且隨著現在硬體的發展,懶漢式的節省記憶體的優點也可以慢慢的忽略不計了.

在設計上,懶漢式要優於餓漢式,在使用上,能夠恰好解決問題的就是好的設計.

在多執行緒的情況下,懶漢式會有一定修改.當兩個執行緒在if(null==instance)語句阻塞的時候,可能由兩個執行緒進入建立例項,從而返回了兩個物件,這是一個概率性的問題,一但出現,排查和定位問題都具有運氣性.對此,我們可以加鎖,以保證每次僅有一個執行緒處於getInstance()方法中,從而保證了執行緒一致性.多執行緒下的單例模式可以為

public class Singleton4 {
    private static Singleton4 instance;
 private Singleton4(){}

    public static synchronized Singleton4  getInstance() {
        if(null==instance){
            instance=new Singleton4();
  }
        return instance;
  }
}

複製程式碼

Singleton4相對於Singleton3,只是在getInstance方法上加了一個鎖(靜態方法以Singleton4.class物件為鎖,非靜態方法鎖以this物件為鎖).從而保證了,每次僅有一個執行緒進入內部的程式碼快.試想,一個專案中若有100處獲取例項,那麼jvm就會有100次進行加鎖,放鎖的操作,但僅有一次實現了對物件的建立,jvm加鎖放鎖的操作都需要對物件頭進行讀寫操作,每一次的操作都比較耗費資源.所以該方式實現的單例的模式的效率並不高.instance不為null的概率非常非常高,但又同時要相容多個執行緒下的安全性,可以在外面再加一層的判斷.可以寫成下面的形式

public class Singleton4 {
    private static Singleton4 instance;
    private Singleton4(){}

    private static synchronized void doGetInstance() {
        if(null==instance){
            instance=new Singleton4();
        }
    }
    public static synchronized Singleton4 getInstance(){
        if(null==instance){
            doGetInstance();
        }
        return instance;
  }
複製程式碼

簡化一下程式碼,可以寫成如下的形式:

public class Singleton5 {

    private static Singleton5 instance;  
    private Singleton5() {
    }

    public static Singleton5 getInstance() {
        if (null == instance) {
            synchronized (Singleton5.class) {
                if (null == instance) {
                    instance = new Singleton5();
  }
            }
        }
        return instance;
  }
}
複製程式碼

上面的這種形式,也就是所謂的雙重檢查的單例模式寫法,如果多個執行緒同時了通過了第一次檢查,並且其中一個執行緒首先通過了第二次檢查並例項化了物件,那麼剩餘通過了第一次檢查的執行緒就不會再去例項化物件.即提升了效率,又可以顯得很牛逼.

但上面的形式還是有些的問題的.還記得上面說的類的生命週期嗎?這裡再詳細展開說明類的連線過程.

類的連線過程又分為 驗證階段,準備階段和解析階段.驗證階段不用多講,在這個階段,jvm對類的合法性進行驗證(很多基於jvm的語言都有自己的工具生成java位元組碼,比如clojure,kotlin等).

準備階段,則是將類裡的靜態變數賦予預設值,解析階段則是將符號引用轉換為直接引用.同時如果一個類被直接引用，就會觸發類的初始化(處於連線過程的下一個過程).總的來說,一個類在碰到new關鍵字的時候,一般經歷以下三個順序:

  1. 開闢空間,
  2. 符號引用改空間,並在空間內對類進行初始化操作,
  3. 將符合引用轉為直接引用(這個時候if(null==instance)返回false).

可在實際的情況中,為了降低cpu的閒置時間,jvm往往對指令進行重新排序以形成指令流水線.也就是說以三個部署可能是亂序的,可能為

  1. 開闢空間,
  2. 轉為直接引用(這個時候if(null=instance)返回false)),
  3. 初始化類.

因此上面的雙重檢查機制就會出現問題:可能返回一個未被完全初始化的類.

volatile的作用

  1. 可見性:可以將執行緒和堆記憶體理解比喻為計算機的cpu的核與主記憶體.cpu的每一個核心都有自己的快取,常用資料首先寫入自己的快取,然後再寫入主記憶體.這樣會導致最新的資料不能及時的在主記憶體中存在,但其卻能極大的提升效率.同樣的jvm中每一個執行緒也有自己的記憶體區域.對變數(不是方法中的臨時變數,臨時變數存在於jvm棧)使用volatile修飾,可以強制將每一次的讀寫都寫入到堆中,實現了各個執行緒都能共享的最新資料的效果.
  2. 禁止指令重排序優化:由上面的討論可指,被volatile修飾的變數，在賦值的結尾會插入一個記憶體屏障(不要被這個名詞嚇到了),從而防止指令重排序. volatile增強了資料的一致性,但降低了速率. 由此可知,上面的寫法需要進行稍微的修改:
public class Singleton5 {

    private static volatile Singleton5 instance;         
    private Singleton5() {}
    public static Singleton5 getInstance() {
        if (null == instance) {
            synchronized (Singleton5.class) {
                if (null == instance) {
                    instance = new Singleton5();
  }
            }
        }
        return instance;
  }
}
複製程式碼

講到這裡,可以再講一下Singleton1(餓漢式)的寫法,上面說過,這種寫法的問題是在於沒有達到懶載入的效果.但其具有清晰的結構,對執行緒友好的特點.如果能夠在其結構上進行簡單的改造,使其具有懶載入的效果,那就完美了!

靜態巢狀類的使用用

  • 靜態巢狀類 : 是一種在類之外宣告的巢狀類,由於是靜態的,所以不經過初始化,就可以通過類名直接呼叫.
  • 內部類 : 即該類作為另一個類的成員,因此只有引用另一個類,才能建立這個類. 通過靜態巢狀類,便可以實現對餓漢式進行懶化的效果.
public class Singleton7 {
    private Singleton7(){}
    private static  class SingletonHolder {
        private static  Singleton7 INSTANCE = new Singleton7();
  }
    public static final Singleton7 getInstance() {
        return SingletonHolder.INSTANCE;
  }
}
複製程式碼

對比Singleton1,這裡做了什麼改變?僅僅是唯一的一個類的物件被靜態巢狀類包裹了一下.要分析這種方式有沒有實現懶載入,就要分析一下語句new Singleton7();是在什麼時候被呼叫了. 當使用javac 進行編譯Singleton7時,會生成三個class檔案:

  1. Singleton7$1.class
  2. Singleton7$SingletonHolder.class
  3. Singleton7.class

第一個檔案可以忽略,是一個空殼檔案(讀者可以通過反編譯外掛檢視原始碼).可以看到靜態巢狀類是單獨作為一個class存在的,而其中建立物件的邏輯位於巢狀類中,jvm讀取巢狀類的位元組碼以後才能建立物件.從硬碟中讀取class檔案,再在記憶體中分配空間,是一件費事費力的工作,所以jvm選擇按需載入,沒有必要載入的就不載入,沒必要分配就不分配.

所以Singleton7從連線和初始化的時候,不會去讀取靜態巢狀類的class檔案,當然也就不能建立Singleton7物件.在呼叫getInstance時,jvm不得不去載入位元組碼檔案,但不一定需要對類進行初始化.所以結論就是:用靜態巢狀類包裹物件的建立過程,可以實現懶載入的同時,又不會讓靜態巢狀類進行初始化!下面開始實驗驗證.首先對Singleton7進行修改,加入日誌:

public class Singleton7 {
    private Singleton7(){
        System.out.println("Singleton7");
  }
    private static final class SingletonHolder {
        SingletonHolder(){
            System.out.println("SingletonHolder");
  }
        private static final Singleton7 INSTANCE = new Singleton7();
  }
    public static Singleton7 getInstance() {
        return SingletonHolder.INSTANCE;
  }
}
複製程式碼

測試類:

public class Test {
    public static void main(String[] args) {
        System.out.println("-------start-------");
        Singleton7.getInstance();
        System.out.println("-------end---------");
  }
    /* out:
     *--------start------     
     *Singleton7 
     *-------end--------- 
     */ 
}
複製程式碼

沒有輸出SingletonHolder!!!,這個說明了什麼? 到這裡似乎就是要大結局了:我們似乎已經嚴格且完美實現了一個類在一個jvm環境下僅有一個物件了!!!但事實真是如此嗎?

利用JAVA反射破壞單例模式

上面的單例,最主要的一步是將構造方法私有化,從而外界無法new物件.但java的反射可以強制訪問private修飾的變數,方法,建構函式!所以:

//測試3 public class Test {
    public static void main(String[] args) throws NoSuchMethodException, IllegalAccessException, InvocationTargetException, InstantiationException {
        Class<Singleton7> singleton7Class = Singleton7.class;
  Constructor<Singleton7> constructor= singleton7Class.getDeclaredConstructor();
  //這裡有個萬惡的方法
  constructor.setAccessible(true);
  Singleton7 singleton1=constructor.newInstance();
  Singleton7 singleton2=constructor.newInstance();
  }
    /**out
     * Singleton7 
     * Singleton7 
     */ 
}
複製程式碼

看來我們的單例並不是安全的.在java中,有四種建立物件的方式

方式 說明
new 需要呼叫建構函式
反射 需要呼叫建構函式,免疫一切訪問許可權的限制(public,private等)
clone 需要實現Cloneable介面,又分深複製,淺複製
序列化 1.將物件儲存在硬碟中 2.通過網路傳輸物件,需要實現Serializable

而上面介紹的各種單例模式,是不能抵抗反射,clone,序列化的破壞的.

現在考慮如何保護單例模式.對於clone和序列化,可以在設計的過程中不直接或者間接的去實現Cloneable和Serializable介面即可.對於反射,通常來說,使用普通類難以避免(可以通過在呼叫第二次建構函式的方式進行避免,但這並不是完全之策,詳情可以自行搜尋相關內容).

列舉類

列舉類是Java 5中新增特性的一部分,它是一種特殊的資料型別,之所以特殊是因為它既是一種類(class)型別卻又比類型別多了些特殊的約束.列舉類能夠實現介面,但不能繼承類,列舉類使用enum定義後在編譯時就預設繼承了java.lang.Enum類，而不是普通的繼承Object類.列舉類會預設實現Serializable和Comparable兩個介面,且採用enum聲明後,該類會被編譯器加上final宣告,故該類是無法繼承的.列舉類的內部定義的列舉值就是該類的例項.除此之外,列舉類和普通類一致.因此可以利用列舉類來實現一個單例模式

public enum Singleton8
{
    INSTANCE;
  //該方法可有可無
  public static Singleton8 getInstance(){
        return INSTANCE;
  }
    //.....other method 
}
複製程式碼

這個就怎麼能夠防止反射破壞類呢?可以看一下下面的程式碼片段

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);
  }
    }
    //反射在通過newInstance建立物件時，會檢查該類是否ENUM修飾，如果是則丟擲異常，反射失敗。
    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; }
複製程式碼

上面擷取的是java.lang.reflect.Constructor類的newInstance,可以看出,噹噹前類是列舉型別時,就會丟擲異常,因此列舉類可以抗得住反射攻擊!

既然列舉類預設實現了Serializable,那麼就能夠對列舉類進行序列化操作

public class Test2 {
    public static void main(String[] args) throws Exception{
        File objectFile =new File("Singleton8.javaObject");
        Singleton8 instance1=Singleton8.INSTANCE;
        Singleton8 instance2=null;    
        //序列化到本地
        ObjectOutputStream objectOutputStream = new ObjectOutputStream(new FileOutputStream(objectFile));
        objectOutputStream.writeObject(instance1);
        objectOutputStream.flush();    
        //反序列化到記憶體
        ObjectInputStream objectInputStream = new ObjectInputStream(new FileInputStream(objectFile));
        instance2= (Singleton8) objectInputStream.readObject();           objectInputStream.close();
        objectOutputStream.close();
        //true,說明兩者引用著同一個物件
        System.out.println(Objects.equals(instance1,instance2));
  }
}
複製程式碼

在複製操作上.列舉類直接繼承java.lang.Enum類,而非Object類,無法實現複製操作.

到這裡,單例模式的設計方式就告一段落了,下面再給出兩個簡單的小案例.

1.實現執行緒內的單例

對於實現執行緒內的單例,直觀的做法是利用一個map<Long,Singleton9>來儲存物件.其中key可以為執行緒的ID,value為每個執行緒下獨有的物件.我們可以做的更好,可以用ThreadLocal來做執行緒的變數隔離! 執行緒級單例設計如下

public class Singleton9 {
    private Singleton9(){}
    private static final ThreadLocal<Singleton9> threadHolder = new ThreadLocal<>(){
        @Override
  protected Singleton9 initialValue() {
            return new Singleton9();
  }
    };
 public static final Singleton9 getInstance(){
        return threadHolder.get();
  }
}
複製程式碼

2.HttpServlet的單例多執行緒模式

Tomcat的Servlet在需要時被建立載入,以後的請求都將利用同一個Servlet物件.是一個典型的單例多執行緒模式,Tomcat裡的StandardWrapper裡的loadServlet可看的出來.對於單例多執行緒,注意以下問題

  1. 使用棧封閉來管理變數,將變數封閉到執行緒棧內,防止變數被其他執行緒汙染(上面的說話過於裝酷,其實就是避免使用例項變數)
  2. 使用要使用ThreadLocal對例項變數進行變數隔離
  3. 實現 SingleThreadModel 介面:實現SingleThreadModel的Servlet中的service方法將不會有兩個執行緒被同時執行.

程式的設計模式,實用性大於理論性.所以,只要能夠恰好的解決問題的設計模式就是好的設計模式.

筆者才疏學淺,上述內容只是個人的整理,請客觀的閱讀,對於錯誤的地方,還請讀者能夠及時給於指出和更正,歡迎一起討論!

email:[email protected]

相關推薦

單例模式個人整理

單例模式 本次簡單的講一下單例模式.在講的過程中,筆者會盡量把這個模式講清楚,講詳細,講簡單.同時也會給出目前使用單例模式的例子,並分析這些案例的實現方式.在這個過程中,你會發現,小小的單例模式裡卻有著很大的學問在. 單例模式是為了保證在一個jvm環境下,一個類僅有一個物件.一般來說,每講到單例模式,

Java 單例模式 總結整理

java 單例模式 分享總結常見的5種單例模式： 第一、單例模式的使用場景 A、Windows的任務管理器、回收站、文件系統如F盤，都是很典型的單例模式 ； B、項目中，讀取配置文件的類，一般也是單例模式，沒有必要每次讀取都重新new一個對象加載 C、數據庫的連接池也是

單例模式整理

single 單例模式 check public 浪費 互斥 nal dcl clas 單例模式的使用場景： 配置文件的讀取。如日誌文件，應用配置。該服務器的配置信息存放在一個文件中，這些配置數據由一個單例對象統一讀取，然後服務進程中的其他對象再通過這個單例對象獲取這些

java的執行緒安全、單例模式、JVM記憶體結構等知識學習和整理

知其然，不知其所以然 ！在技術的海洋裡，前路漫漫，我一直在迷失著自我。 歡迎訪問我的csdn部落格，我們一同成長！ “不管做什麼，只要堅持下去就會看到不一樣！在路上，不卑不亢!” 在下面的題目來自於我要加的一個QQ群，然後要加這個QQ群

關於工廠模式和單例模式的融合用法的個人見解

最近在思考spring程式碼如何降低記憶體消耗，減少物件建立的問題。後來想到使用工廠模式+單例模式來實現。此處就不貼程式碼了。直接介紹原理： 1，提供一個工廠類Factory，來提供一個統一的入口，讓APP統一從入口呼叫，獲取想要的類的物件。 2，為使用者提供的類的物件，

java設計模式之五 —— 單例模式的三種模式優缺點整理

本來一直以為單例很簡單，不打算整理了。不過本著求學需嚴謹的心態，還是去看了一下。確實有所收穫。 單例模式：單例模式的意思就是隻有一個例項。單例模式確保某一個類只有一個例項，而且自行例項化並向整個系統提供這個例項。這個類稱為單例類。 單例模式有三種：懶漢式單例

代理模式，簡單（靜態）工廠模式，單例模式，模板方法模式個人理解

簡言: java中總共有23種設計模式，每個模式的出現都是為了解決某一方面的問題，所以這23種設計模式有他們各自適用的地方（廢話有點多），而設計模式的產生主要是為了降低類與類之間的耦合度。下面我們就簡單的瞭解一下幾種設計模式及使用的地方。 1.單例模式：

java單例模式的個人理解

nbsp java ack ron 懶漢式 靜態 解決方法 復雜 例如 下面是我個人對java單例模式的個人理解 java單例設計模式是先輩們走過很多彎路才寫出來的一些方法模式，總共有二三種模式。單線程：只有這個屬性為null時才能創建，構造函數私有，確

吐血整理全網最全的單例模式

前言 之前文章已經說過了設計模式的七大原則，即介面遮蔽原則，開閉原則，依賴倒轉原則，迪米特原則，里氏替換原則，單一職責原則，合成複用原則，不明白的，可以移至萬字總結之設計模式七大原則（https://www.cnblogs.com/chenchen0618/p/12434603.html）。從今天開始我們就要

單例模式

實現 程序 先來 null effective 如果 ava 不同的 aps 單例模式：確保某一個類只有一個實例，而且自行實例化並向整個系統提供這個實例。 優點： 1、省略創建對象所花費的時間減少系統開銷，尤其是重量級對象。 2、減少對象的創建，減輕GC壓力。 3、設置全局

GOF23—單例模式（2）

應該 一個 img bsp 漏洞 資源 nbsp 創建 就會 本文介紹單例模式（不包含枚舉單例模式）漏洞問題以及如何防止漏洞 　　1.反射可以破解單例模式，例子如下： 　　 　　 此時，我們運行Client類，發現s1和s2是一個對象，但s3和s4是不同的對象。 那麽如何防

溫故而知新(java實現)單例模式的七種寫法

反序 防止 代碼 工作 html 我想 變種 evel 才會 第一種（懶漢，線程不安全）： Java代碼 public class Singleton { private static Singleton instance; private S

單例模式和線程安全

tac 可能 存在 版本 線程不安全 廣東 多線程 一個 單例 前幾天給項目的省市區加了redis。結果上線沒多久就發生了數據錯亂的現象，需要讀取山東省的市可能返回的市廣東的。一開始不明白哪裏有問題，因為測試組的同學有測試過，在測試過程種並沒有發生這樣的情況。由於使用了se

C#單例模式的多種寫法

code if語句 規則 最簡 lock 實現 readonly led 三種 它的主要特點不是根據客戶程序調用生成一個新的實例，而是控制某個類型的實例數量-唯一一個。（《設計模式-基於C#的工程化實現及擴展》，王翔）。也就是說，單例模式就是保證在整個應用程序的生命周期中，

Swift、Objective-C 單例模式 (Singleton)

app 賦值 uil imp ide 效果 func instance 發現 本文的單例模式分為嚴格單例模式和不嚴格單例模式。單例模式要求一個類有一個實例，有公開接口可以訪問這個實例。嚴格單例模式，要求一個類只有一個實例；不嚴格單例模式，可以創建多個實例。 有的類只能有一個

單例模式-Singleton

加載 null 允許 nbsp 訪問 加載類 public tin style 單例模式：保證一個類僅有一個實例，並提一個訪問它的全局訪問點。 　　通常我們可以讓一個全局變量使得一個對象被訪問，但它不能防止你實例化多個對象。一個最好的辦法就是，讓類自身負責保存它的唯一實例。

[轉]設計模式--單例模式（一）懶漢式和餓漢式

打印 是否 調用構造 餓漢 一段 tools 會有 輸出結果 java 單例模式是設計模式中比較簡單的一種。適合於一個類只有一個實例的情況，比如窗口管理器，打印緩沖池和文件系統， 它們都是原型的例子。典型的情況是，那些對象的類型被遍及一個軟件系統的不同對象訪問，因此需要一個

23種設計模式介紹以及單例模式的學習

單例模式 餓漢式 23種設計模式 gof23 1、GOF23 設計模式總共分成創建型模式、結構型模式和行為型模式三種： a、創建型模式： - 單例模式、工廠模式、抽象工廠模式、建造者模式、原型模式 b、構建型模式： - 適配器模式、橋接模式、裝配模式、組合模式、建造者模

c++之單例模式

lsi 但是 desc 模式 單例模式 ron spl 希望 構造函數 1 本篇主要討論下多線程下的單例模式實現： 　　首先是 double check 實現方式： 這種模式可以滿足多線程環境下，只產生一個實例。 template<typename T>

面向對象編程思想-單例模式

構造 turn 什麽 性能 線程池 線程並發 管理器 成員 man 單例模式的定義：只能有一個實例，提供唯一公開、可訪問實例的全局訪問點 單例模式的三種實現方式： 示例1 　　　　 private Singleton() {