8種單例模式寫法助你搞定面試


1. 單例模式常見問題

為什么要有單例模式

單例模式是一種設計模式,它限制了實例化一個對象的行為,始終至多只有一個實例。當只需要一個對象來協調整個系統的操作時,這種模式就非常有用.它描述了如何解決重復出現的設計問題,
比如我們項目中的配置工具類,日志工具類等等。

如何設計單例模式 ?

1.單例類如何控制其實例化

2.如何確保只有一個實例

通過一下措施解決這些問題:

private構造函數,類的實例話不對外開放,由自己內部來完成這個操作,確保永遠不會從類外部實例化類,避免外部隨意new出來新的實例。

該實例通常存儲為私有靜態變量,提供一個靜態方法,返回對實例的引用。如果是在多線程環境下則用鎖或者內部類來解決線程安全性問題。

2. 單例類有哪些特點 ?

私有構造函數
它將阻止從類外部實例化新對象

它應該只有一個實例
這是通過在類中提供實例來方法完成的,阻止外部類或子類來創建實例。這是通過在java中使構造函數私有來完成的,這樣任何類都不能訪問構造函數,因此無法實例化它。

單實例應該是全局可訪問的
單例類的實例應該是全局可訪問的,以便每個類都可以使用它。在Java中,它是通過使實例的訪問說明符為public來完成的。

節省內存,減少GC

因為是全局至多只有一個實例,避免了到處new對象,造成浪費內存,以及GC,有了單例模式可以避免這些問題

3. 單例模式8種寫法

下面由我給大家介紹8種單例模式的寫法,各有千秋,存在即合理,通過自己的使用場景選一款使用即可。我們選擇單例模式時的挑選標准或者說評估一種單例模式寫法的優劣時通常會根據一下兩種因素來衡量:

1.在多線程環境下行為是否線程安全

2.餓漢以及懶漢

3.編碼是否優雅(理解起來是否比較直觀)

1. 餓漢式線程安全的

public class SingleTon{

	private static final SingleTon INSTANCE = new SingleTon();

	private SingleTon(){ }

	public static SingleTon getInstance(){
		return INSTANCE;
	}
	public static void main(String[] args) {
        SingleTon instance1 = SingleTon.getInstance();
        SingleTon instance2 = SingleTon.getInstance();
        System.out.println(instance1 == instance2);
    }

}

這種寫法是非常簡單實用的,值得推薦,唯一缺點就是懶漢式的,也就是說不管是否需要用到這個方法,當類加載的時候都會生成一個對象。
除此之外,這種寫法是線程安全的。類加載到內存后,就實例化一個單例,JVM保證線程安全,

2. 餓漢式線程安全(變種寫法)

public class SingleTon{

	private static final SingleTon INSTANCE ;

	static {
	    INSTANCE = new SingleTon(); 
	}

	private SingleTon(){}

	public static SingleTon getInstance(){
		return INSTANCE;
	}
        public static void main(String[] args) {
        SingleTon instance1 = SingleTon.getInstance();
        SingleTon instance2 = SingleTon.getInstance();
        System.out.println(instance1 == instance2);
    }

}

3. 懶漢式線程不安全

public class SingleTon{

	private static  SingleTon instance ;

	private SingleTon(){}

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

	public static void main(String[] args) {
        SingleTon instance1 = SingleTon.getInstance();
        SingleTon instance2 = SingleTon.getInstance();
        System.out.println(instance1 == instance2);
        
        // 通過開啟100個線程 比較是否是相同對象
        for(int i=0;i<100;i++){
             new Thread(()->
                System.out.println(SingleTon.getInstance().hashCode())
            ).start();
        }
        
    }

}

這種寫法雖然達到了按需初始化的目的,但卻帶來線程不安全的問題,至於為什么在並發情況下上述的例子是不安全的呢 ?

   // 通過開啟100個線程 比較是否是相同對象
        for(int i=0;i<100;i++){
             new Thread(()->
                System.out.println(SingleTon.getInstance().hashCode())
            ).start();
        }

為了使效果更直觀一點我們對getInstance 方法稍做修改,每個線程進入之后休眠一毫秒,這樣做的目的是為了每個線程都盡可能獲得cpu時間片去執行。代碼如下

	public static SingleTon getInstance(){
       if(instance == null){
           try {
               Thread.sleep(1);
           } catch (InterruptedException e) {
               e.printStackTrace();
           }
           instance = new SingleTon();
       }
   	return instance;
   }

執行結果如下

上述的單例寫法,我們是可以創造出多個實例的,至於為什么在這里要稍微解釋一下,這里涉及了同步問題

造成線程不安全的原因:

當並發訪問的時候,第一個調用getInstance方法的線程t1,在判斷完singleton是null的時候,線程A就進入了if塊准備創造實例,但是同時另外一個線程B在線程A還未創造出實例之前,就又進行了singleton是否為null的判斷,這時singleton依然為null,所以線程B也會進入if塊去創造實例,這時問題就出來了,有兩個線程都進入了if塊去創造實例,結果就造成單例模式並非單例。
注:這里通過休眠一毫秒來模擬線程掛起,為初始化完instance

為了解決這個問題,我們可以采取加鎖措施,所以有了下面這種寫法

4. 懶漢式線程安全(粗粒度Synchronized)

public class SingleTon{

	private static  SingleTon instance ;

	private SingleTon(){}

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

	public static void main(String[] args) {
	    SingleTon instance1 = SingleTon.getInstance();
	    SingleTon instance2 = SingleTon.getInstance();
	    System.out.println(instance1 == instance2);
            // 通過開啟100個線程 比較是否是相同對象
            for(int i=0;i<100;i++){
                new Thread(()->
                System.out.println(SingleTon.getInstance().hashCode())
            ).start();
        }
        
    }

}

由於第三種方式出現了線程不安全的問題,所以對getInstance方法加了synchronized來保證多線程環境下的線程安全性問題,這種做法雖解決了多線程問題但是效率比較低。
因為鎖住了整個方法,其他進入的現成都只能阻塞等待了,這樣會造成很多無謂的等待。

於是可能有人會想到可不可以讓鎖的粒度更細一點,只鎖住相關代碼塊可否?所以有了第五種寫法。

5. 懶漢式線程不安全(synchronized代碼塊)

public class SingleTon{

	private static  SingleTon instance ;

	private SingleTon(){}

	public static SingleTon getInstance(){
	    if(insatnce == null){
	        synchronied(SingleTon.class){
                    instance = new SingleTon();
	        }
	    }
	    return instance;
	}

	public static void main(String[] args) {
        SingleTon instance1 = SingleTon.getInstance();
        SingleTon instance2 = SingleTon.getInstance();
        System.out.println(instance1 == instance2);
        
        // 通過開啟100個線程 比較是否是相同對象
        for(int i=0;i<100;i++){
             new Thread(()->
                System.out.println(SingleTon.getInstance().hashCode())
            ).start();
        }
        
    }

}

當並發訪問的時候,第一個調用getInstance方法的線程t1,在判斷完instance是null的時候,線程A就進入了if塊並且持有了synchronized鎖,但是同時另外一個線程t2在線程t1還未創造出實例之前,就又進行了instance是否為null的判斷,這時instance依然為null,所以線程t2也會進入if塊去創造實例,他會在synchronized代碼外面阻塞等待,直到t1釋放鎖,這時問題就出來了,有兩個線程都實例化了新的對象。

造成這個問題的原因就是線程進入了if塊並且在等待synchronized鎖的過程中有可能上一個線程已經創建了實例,所以進入synchronized代碼塊之后還需要在判斷一次,於是有了下面這種雙重檢驗鎖的寫法。

6. 懶漢式線程安全(雙重檢驗加鎖)

public class SingleTon{

	private static  volatile SingleTon instance ;

	private SingleTon(){}

	public static SingleTon getInstance(){
	    if(instance == null){
	        synchronied(SingleTon.class){
                    if(instance == null){
                        instance = new SingleTon();
                    }
	        }
	    }
	    return instance;
	}

	public static void main(String[] args) {
        SingleTon instance1 = SingleTon.getInstance();
        SingleTon instance2 = SingleTon.getInstance();
        System.out.println(instance1 == instance2);
        
        // 通過開啟100個線程 比較是否是相同對象
        for(int i=0;i<100;i++){
             new Thread(()->
                System.out.println(SingleTon.getInstance().hashCode())
            ).start();
        }
        
    }

}

這種寫法基本趨於完美了,但是可能需要對一下幾點需要進行解釋:

  • 第一個判空(外層)的作用 ?
  • 第二個判空(內層)的作用 ?
  • 為什么變量修飾為volatile ?

第一個判空(外層)的作用

首先,思考一下可不可以去掉最外層的判斷? 答案是:可以

其實仔細觀察之后會發現最外層的判斷跟能否線程安全正確生成單例無關!!!

它的作用是避免每次進來都要加鎖或者等待鎖,有了同步代碼塊之外的判斷之后省了很多事,當我們的單例類實例化一個單例之后其他后續的所有請求都沒必要在進入同步代碼塊繼續往下執行了,直接返回我們曾生成的實例即可,也就是實例還未創建時才進行同步,否則就直接返回,這樣就節省了很多無謂的線程等待時間,所以最外的判斷可以認為是對提升性能有幫助。

第二個判空(內層)的作用

假設我們去掉同步塊中的是否為null的判斷,有這樣一種情況,A線程和B線程都在同步塊外面判斷了instance為null,結果t1線程首先獲得了線程鎖,進入了同步塊,然后t1線程會創造一個實例,此時instance已經被賦予了實例,t1線程退出同步塊,直接返回了第一個創造的實例,此時t2線程獲得線程鎖,也進入同步塊,此時t1線程其實已經創造好了實例,t2線程正常情況應該直接返回的,但是因為同步塊里沒有判斷是否為null,直接就是一條創建實例的語句,所以t2線程也會創造一個實例返回,此時就造成創造了多個實例的情況。

為什么變量修飾為volatile

因為虛擬機在執行創建實例的這一步操作的時候,其實是分了好幾步去進行的,也就是說創建一個新的對象並非是原子性操作。在有些JVM中上述做法是沒有問題的,但是有些情況下是會造成莫名的錯誤。

首先要明白在JVM創建新的對象時,主要要經過三步。

1.分配內存

2.初始化構造器

3.將對象指向分配的內存的地址

因為僅僅一個new 新實例的操作就涉及三個子操作,所以生成對象的操作不是原子操作

而實際情況是,JVM會對以上三個指令進行調優,其中有一項就是調整指令的執行順序(該操作由JIT編譯器來完成)。

所以,在指令被排序的情況下可能會出現問題,假如 2和3的步驟是相反的,先將分配好的內存地址指給instance,然后再進行初始化構造器,這時候后面的線程去請求getInstance方法時,會認為instance對象已經實例化了,直接返回一個引用。

如果這時還沒進行構造器初始化並且這個線程使用了instance的話,則會出現線程會指向一個未初始化構造器的對象現象,從而發生錯誤。

7. 靜態內部類的方式(基本完美了)

public class SingleTon{

	public static SingleTon getInstance(){
	    return StaticSingleTon.instance;
	}
	private static class StaticSingleTon{
            private static final SingleTon instance = new SingleTon();
	}
	public static void main(String[] args) {
        SingleTon instance1 = SingleTon.getInstance();
        SingleTon instance2 = SingleTon.getInstance();
        System.out.println(instance1 == instance2);
        
        // 通過開啟100個線程 比較是否是相同對象
        for(int i=0;i<100;i++){
             new Thread(()->
                System.out.println(SingleTon.getInstance().hashCode())
            ).start();
        }
        
    }

}
  • 因為一個類的靜態屬性只會在第一次加載類時初始化,這是JVM幫我們保證的,所以我們無需擔心並發訪問的問題。所以在初始化進行一半的時候,別的線程是無法使用的,因為JVM會幫我們強行同步這個過程。
  • 另外由於靜態變量只初始化一次,所以singleton仍然是單例的。

8. 枚舉類型的單例模式(太完美以至於。。。)

public Enum SingleTon{
    
    INSTANCE;
    public static void main(String[] args) {
         // 通過開啟100個線程 比較是否是相同對象
        for(int i=0;i<100;i++){
            new Thread(()->
                System.out.println(SingleTon.getInstance().hashCode())
            ).start();
        }
        
    }

}

這種寫法從語法上看來是完美的,他解決了上面7種寫法都有的問題,就是我們可以通過反射可以生成新的實例
但是枚舉的這種寫法是無法通過反射來生成新的實例,因為枚舉沒有public構造方法


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM