Java五種單例模式實現的深入分析

大家在Java在實現單例時常用的有:餓漢模式、懶漢模式、雙重鎖懶漢模式DCL(Double Check Lock)、靜態內部類模式、枚舉模式,五種模式,

1.餓漢式:

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

INSTANCE是用static修飾的所以它在類的初始化時,就會在內存中創建對象,
餓漢式是線程安全的,但是它是以空間換時間,所以不推薦

2.懶漢模式

public class Singleton {
    private static Singleton INSTANCE = null;
    private Singleton(){}
    public static Singleton getInstance(){
        if (INSTANCE==null){
            INSTANCE = new Singleton();
        }
        return INSTANCE;
    }
}

懶漢模式在方法被調用后才創建對象,以時間換空間,在多線程環境下存在風險

3.雙重鎖懶漢模式DCL(Double Check Lock)

public class Singleton {
    private static Singleton INSTANCE = null;

    private Singleton() {}

    public static Singleton getInstance() {
        //先檢查實例是否存在,如果不存在才進入下面的同步塊,減少加鎖
        if (INSTANCE == null) {
            //同步塊,線程安全的創建實例
            synchronized (Singleton.class) {
                //再次檢查實例是否存在,如果不存在才真正的創建實例
                if (INSTANCE == null) {
                    INSTANCE = new Singleton();
                }
            }
        }
        return INSTANCE;
    }
}

DCL模式的優點就是,只有在對象需要被使用時才創建,第一次判斷 INSTANCE == null為了避免非必要加鎖,當第一次加載時才對實例進行加鎖再實例化。這樣既可以節約內存空間,又可以保證線程安全。
重點來了:DCL真的能安全嗎??
由于jvm存在亂序執行功能,DCL也會出現線程不安全的情況。具體分析如下:
首先我們看一下這行代碼
INSTANCE = new Singleton();
這個步驟,其實在jvm里面的執行分為三步:
1.在堆內存開辟內存空間。
2.在堆內存中實例化SingleTon里面的各個參數。
3.把對象指向堆內存空間。

由于jvm存在亂序執行功能,所以在多核CPU上可能在2還沒執行時就先執行了3,如果此時再被切換到線程B上,由于執行了3,INSTANCE 已經非空了,會被直接拿出來用,這樣的話,就會出現異常。這個就是著名的DCL失效問題。

JDK1.6之后,具體化了volatile,只要定義使用volatile 修飾INSTANCE 就可解決DCL失效問題。volatile確保INSTANCE每次均在主內存中讀取,(但是使用volatile修飾某一個變量并不會使它變得線程)這樣雖然會犧牲一點效率,但是是可以接受的。

public class Singleton {
    private volatile static SingleTon INSTANCE = null;
    private Singleton() {}

    public static Singleton getInstance() {
        //先檢查實例是否存在,如果不存在才進入下面的同步塊,減少加鎖
        if (INSTANCE == null) {
            //同步塊,線程安全的創建實例
            synchronized (Singleton.class) {
                //再次檢查實例是否存在,如果不存在才真正的創建實例
                if (INSTANCE == null) {
                    INSTANCE = new Singleton();
                }
            }
        }
        return INSTANCE;
    }
}

4.靜態內部類模式

public class Singleton {
    private Singleton() {
    }

    public static Singleton getInstance() {
        return SingletonHolder.INSTANCE;
    }

    private static class SingletonHolder{
        private static final Singleton INSTANCE = new Singleton();
    }
}

靜態內部類的優點是:外部類與內部類的加載沒有關聯,外部類加載時并不需要立即加載內部類,內部類不被加載則不去初始化INSTANCE,故而不占內存。即當SingleTon第一次被加載時,并不需要去加載SingleTonHolder,只有當getInstance()方法第一次被調用時,才會去初始化INSTANCE,第一次調用getInstance()方法會導致虛擬機加載SingleTonHolder類,這種方法不僅能確保線程安全,也能保證單例的唯一性,同時也延遲了單例的實例化。

這里我們要說一下類加載時機:JAVA虛擬機只有在5種場景下會對類進行初始化。
1.遇到new、getstatic、setstatic或者invikestatic這4個字節碼指令時,對應的java代碼場景為:new一個關鍵字或者一個實例化對象時、讀取或設置一個靜態字段時(final修飾、已在編譯期把結果放入常量池的除外)、調用一個類的靜態方法時。
2.使用java.lang.reflect包的方法對類進行反射調用的時候,如果類沒進行初始化,需要先調用其初始化方法進行初始化。
3.當初始化一個類時,如果其父類還未進行初始化,會先觸發其父類的初始化。
4.當虛擬機啟動時,用戶需要指定一個要執行的主類(包含main()方法的類),虛擬機會先初始化這個類。
5.當使用JDK 1.7等動態語言支持時,如果一個java.lang.invoke.MethodHandle實例最后的解析結果REF_getStatic、REF_putStatic、REF_invokeStatic的方法句柄,并且這個方法句柄所對應的類沒有進行過初始化,則需要先觸發其初始化。
這5種情況被稱為是類的主動引用,那么,除此之外的所有引用類都不會對類進行初始化,稱為被動引用。靜態內部類就屬于被動引用的行列。

我們再回頭看下getInstance()方法,調用的是SingleTonHoler.INSTANCE,取的是SingleTonHoler里的INSTANCE對象,跟上面那個DCL方法不同的是,getInstance()方法并沒有多次去new對象,故不管多少個線程去調用getInstance()方法,取的都是同一個INSTANCE對象,而不用去重新創建。當getInstance()方法被調用時,SingleTonHoler才在SingleTon的運行時常量池里,把符號引用替換為直接引用,這時靜態對象INSTANCE也真正被創建,然后再被getInstance()方法返回出去,這點同餓漢模式。那么INSTANCE在創建過程中又是如何保證線程安全的呢?

虛擬機會保證一個類的<clinit>()方法在多線程環境中被正確地加鎖、同步,如果多個線程同時去初始化一個類,那么只會有一個線程去執行這個類的<clinit>()方法,其他線程都需要阻塞等待,直到活動線程執行<clinit>()方法完畢。如果在一個類的<clinit>()方法中有耗時很長的操作,就可能造成多個進程阻塞(需要注意的是,其他線程雖然會被阻塞,但如果執行<clinit>()方法后,其他線程喚醒之后不會再次進入<clinit>()方法。同一個加載器下,一個類型只會初始化一次。)。

故而,可以看出INSTANCE在創建過程中是線程安全的,所以說靜態內部類形式的單例可保證線程安全,也能保證單例的唯一性,同時也延遲了單例的實例化。

那么,是不是可以說靜態內部類單例就是最完美的單例模式了呢?其實不然,靜態內部類也有著一個致命的缺點,就是傳參的問題,由于是靜態內部類的形式去創建單例的,故外部無法傳遞參數進去,例如Context這種參數,所以,我們創建單例時,可以在靜態內部類與DCL模式里自己斟酌。

5.枚舉模式

public enum SingleTon{
  INSTANCE;
        public void method(){
        //TODO
     }
}

枚舉在java中與普通類一樣,都能擁有字段與方法,而且枚舉實例創建是線程安全的,在任何情況下,它都是一個單例。我們可直接以SingleTon.INSTANCE的方式調用

最后編輯于
?著作權歸作者所有,轉載或內容合作請聯系作者
平臺聲明:文章內容(如有圖片或視頻亦包括在內)由作者上傳并發布,文章內容僅代表作者本人觀點,簡書系信息發布平臺,僅提供信息存儲服務。
  • 序言:七十年代末,一起剝皮案震驚了整個濱河市,隨后出現的幾起案子,更是在濱河造成了極大的恐慌,老刑警劉巖,帶你破解...
    沈念sama閱讀 228,702評論 6 534
  • 序言:濱河連續發生了三起死亡事件,死亡現場離奇詭異,居然都是意外死亡,警方通過查閱死者的電腦和手機,發現死者居然都...
    沈念sama閱讀 98,615評論 3 419
  • 文/潘曉璐 我一進店門,熙熙樓的掌柜王于貴愁眉苦臉地迎上來,“玉大人,你說我怎么就攤上這事。” “怎么了?”我有些...
    開封第一講書人閱讀 176,606評論 0 376
  • 文/不壞的土叔 我叫張陵,是天一觀的道長。 經常有香客問我,道長,這世上最難降的妖魔是什么? 我笑而不...
    開封第一講書人閱讀 63,044評論 1 314
  • 正文 為了忘掉前任,我火速辦了婚禮,結果婚禮上,老公的妹妹穿的比我還像新娘。我一直安慰自己,他們只是感情好,可當我...
    茶點故事閱讀 71,826評論 6 410
  • 文/花漫 我一把揭開白布。 她就那樣靜靜地躺著,像睡著了一般。 火紅的嫁衣襯著肌膚如雪。 梳的紋絲不亂的頭發上,一...
    開封第一講書人閱讀 55,227評論 1 324
  • 那天,我揣著相機與錄音,去河邊找鬼。 笑死,一個胖子當著我的面吹牛,可吹牛的內容都是我干的。 我是一名探鬼主播,決...
    沈念sama閱讀 43,307評論 3 442
  • 文/蒼蘭香墨 我猛地睜開眼,長吁一口氣:“原來是場噩夢啊……” “哼!你這毒婦竟也來了?” 一聲冷哼從身側響起,我...
    開封第一講書人閱讀 42,447評論 0 289
  • 序言:老撾萬榮一對情侶失蹤,失蹤者是張志新(化名)和其女友劉穎,沒想到半個月后,有當地人在樹林里發現了一具尸體,經...
    沈念sama閱讀 48,992評論 1 335
  • 正文 獨居荒郊野嶺守林人離奇死亡,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內容為張勛視角 年9月15日...
    茶點故事閱讀 40,807評論 3 355
  • 正文 我和宋清朗相戀三年,在試婚紗的時候發現自己被綠了。 大學時的朋友給我發了我未婚夫和他白月光在一起吃飯的照片。...
    茶點故事閱讀 43,001評論 1 370
  • 序言:一個原本活蹦亂跳的男人離奇死亡,死狀恐怖,靈堂內的尸體忽然破棺而出,到底是詐尸還是另有隱情,我是刑警寧澤,帶...
    沈念sama閱讀 38,550評論 5 361
  • 正文 年R本政府宣布,位于F島的核電站,受9級特大地震影響,放射性物質發生泄漏。R本人自食惡果不足惜,卻給世界環境...
    茶點故事閱讀 44,243評論 3 347
  • 文/蒙蒙 一、第九天 我趴在偏房一處隱蔽的房頂上張望。 院中可真熱鬧,春花似錦、人聲如沸。這莊子的主人今日做“春日...
    開封第一講書人閱讀 34,667評論 0 26
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽。三九已至,卻和暖如春,著一層夾襖步出監牢的瞬間,已是汗流浹背。 一陣腳步聲響...
    開封第一講書人閱讀 35,930評論 1 287
  • 我被黑心中介騙來泰國打工, 沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留,地道東北人。 一個月前我還...
    沈念sama閱讀 51,709評論 3 393
  • 正文 我出身青樓,卻偏偏與公主長得像,于是被迫代替她去往敵國和親。 傳聞我的和親對象是個殘疾皇子,可洞房花燭夜當晚...
    茶點故事閱讀 47,996評論 2 374

推薦閱讀更多精彩內容