自拍偷在线精品自拍偷,亚洲欧美中文日韩v在线观看不卡

設(shè)計(jì)模式系列 - 單例模式

開(kāi)發(fā) 前端
我不知道大家工作或者面試時(shí)候遇到過(guò)單例模式?jīng)],面試的話我記得我當(dāng)時(shí)在17年第一次實(shí)習(xí)的時(shí)候,就遇到了單例模式,面試官是我后來(lái)的leader,當(dāng)時(shí)就讓我手寫(xiě)單例,我記得我就寫(xiě)出了餓漢式,懶漢式,但是并沒(méi)說(shuō)出懶漢和惡漢的區(qū)別,當(dāng)時(shí)他給我一通解釋我才知道了其中的奧秘。

[[384482]]

本文轉(zhuǎn)載自微信公眾號(hào)「三太子敖丙」,作者三太子敖丙。轉(zhuǎn)載本文請(qǐng)聯(lián)系三太子敖丙公眾號(hào)。

我不知道大家工作或者面試時(shí)候遇到過(guò)單例模式?jīng)],面試的話我記得我當(dāng)時(shí)在17年第一次實(shí)習(xí)的時(shí)候,就遇到了單例模式,面試官是我后來(lái)的leader,當(dāng)時(shí)就讓我手寫(xiě)單例,我記得我就寫(xiě)出了餓漢式,懶漢式,但是并沒(méi)說(shuō)出懶漢和惡漢的區(qū)別,當(dāng)時(shí)他給我一通解釋我才知道了其中的奧秘。

寫(xiě)這篇文章之前我刻意的在我手上的項(xiàng)目里面去找了找,我發(fā)現(xiàn)單例在每個(gè)項(xiàng)目里面都有運(yùn)用到,而且我后面所說(shuō)的幾種實(shí)現(xiàn)還基本上都涉及了,還挺有意思的。

開(kāi)篇我就給大家一個(gè)思考題:為什么不用靜態(tài)方法而不用單例模式?

問(wèn)題的答案我會(huì)在最后公布,大家可以帶著問(wèn)題看下去,看看大家的思考是不是跟我一樣的。

大家肯定也能經(jīng)常聽(tīng)到身邊的同學(xué)說(shuō)單例很簡(jiǎn)單,自己也會(huì),但是真到自己的時(shí)候你能就一個(gè)知識(shí)點(diǎn)講的很透徹,并且能夠發(fā)散思考引出更多的答案嗎?或者能說(shuō)出他每種模式更適合的場(chǎng)景么?這是值得深思的。

首先給單例下一個(gè)定義:在當(dāng)前進(jìn)程中,通過(guò)單例模式創(chuàng)建的類有且只有一個(gè)實(shí)例。

單例有如下幾個(gè)特點(diǎn):

  • 在Java應(yīng)用中,單例模式能保證在一個(gè)JVM中,該對(duì)象只有一個(gè)實(shí)例存在
  • 構(gòu)造器必須是私有的,外部類無(wú)法通過(guò)調(diào)用構(gòu)造器方法創(chuàng)建該實(shí)例
  • 沒(méi)有公開(kāi)的set方法,外部類無(wú)法調(diào)用set方法創(chuàng)建該實(shí)例
  • 提供一個(gè)公開(kāi)的get方法獲取唯一的這個(gè)實(shí)例

那單例模式有什么好處呢?

  • 某些類創(chuàng)建比較頻繁,對(duì)于一些大型的對(duì)象,這是一筆很大的系統(tǒng)開(kāi)銷(xiāo)
  • 省去了new操作符,降低了系統(tǒng)內(nèi)存的使用頻率,減輕GC壓力
  • 系統(tǒng)中某些類,如spring里的controller,控制著處理流程,如果該類可以創(chuàng)建多個(gè)的話,系統(tǒng)完全亂了
  • 避免了對(duì)資源的重復(fù)占用

好了,單例模式的定義也清楚了,好處也了解了,先看一個(gè)餓漢式的寫(xiě)法

餓漢式

  1. public class Singleton { 
  2.   // 創(chuàng)建一個(gè)實(shí)例對(duì)象 
  3.     private static Singleton instance = new Singleton(); 
  4.     /** 
  5.      * 私有構(gòu)造方法,防止被實(shí)例化 
  6.      */ 
  7.     private Singleton(){} 
  8.     /** 
  9.      * 靜態(tài)get方法 
  10.      */ 
  11.     public static Singleton getInstance(){ 
  12.         return instance; 
  13.     } 

之所以叫餓漢式大家可以理解為他餓,他想提前把對(duì)象new出來(lái),這樣別人哪怕是第一次獲取這個(gè)類對(duì)象的時(shí)候直接就存在這個(gè)類了,省去了創(chuàng)建類這一步的開(kāi)銷(xiāo)。

等我介紹完懶漢之后,對(duì)比一下大家就知道兩者的區(qū)別,以及各自適用在什么場(chǎng)景了。

懶漢式

線程不安全的模式

  1. public class Singleton {   
  2.     private static Singleton instance;   
  3.     private Singleton (){}   
  4.    
  5.     public static Singleton getInstance() {   
  6.     if (instance == null) {   
  7.         instance = new Singleton();   
  8.     }   
  9.     return instance;   
  10.     }   

懶漢式大家可以理解為他懶,別人第一次調(diào)用的時(shí)候他發(fā)現(xiàn)自己的實(shí)例是空的,然后去初始化了,再賦值,后面的調(diào)用就和惡漢沒(méi)區(qū)別了。

懶漢和惡漢的對(duì)比:大家可以發(fā)現(xiàn)兩者的區(qū)別基本上就是第一次創(chuàng)作時(shí)候的開(kāi)銷(xiāo)問(wèn)題,以及線程安全問(wèn)題(線程不安全模式的懶漢)。

那有了這個(gè)對(duì)比,那他們的場(chǎng)景好理解了,在很多電商場(chǎng)景,如果這個(gè)數(shù)據(jù)是經(jīng)常訪問(wèn)的熱點(diǎn)數(shù)據(jù),那我就可以在系統(tǒng)啟動(dòng)的時(shí)候使用惡漢模式提前加載(類似緩存的預(yù)熱)這樣哪怕是第一個(gè)用戶調(diào)用都不會(huì)存在創(chuàng)建開(kāi)銷(xiāo),而且調(diào)用頻繁也不存在內(nèi)存浪費(fèi)了。

而懶漢式呢我們可以用在不怎么熱的地方,比如那個(gè)數(shù)據(jù)你不確定很長(zhǎng)一段時(shí)間是不是有人會(huì)調(diào)用,那就用懶漢,如果你使用了惡漢,但是過(guò)了幾個(gè)月還沒(méi)人調(diào)用,提前加載的類在內(nèi)存中是有資源浪費(fèi)的。

線程安全問(wèn)題

上面的懶漢我是故意沒(méi)加鎖的,大家肯定都知道懶漢的線程安全問(wèn)題的吧?

???忘了?那好吧,暖男帶你回憶一波吧。

 

在運(yùn)行過(guò)程中可能存在這么一種情況:多個(gè)線程去調(diào)用getInstance方法來(lái)獲取Singleton的實(shí)例,那么就有可能發(fā)生這樣一種情況,當(dāng)?shù)谝粋€(gè)線程在執(zhí)行if(instance==null)時(shí),此時(shí)instance是為null的進(jìn)入語(yǔ)句。

在還沒(méi)有執(zhí)行instance=new Singleton()時(shí)(此時(shí)instance是為null的)第二個(gè)線程也進(jìn)入了if(instance==null)這個(gè)語(yǔ)句,因?yàn)橹斑M(jìn)入這個(gè)語(yǔ)句的線程中還沒(méi)有執(zhí)行instance=new Singleton(),所以它會(huì)執(zhí)行instance = new Singleton()來(lái)實(shí)例化Singleton對(duì)象,因?yàn)榈诙€(gè)線程也進(jìn)入了if語(yǔ)句所以它會(huì)實(shí)例化Singleton對(duì)象。

這樣就導(dǎo)致了實(shí)例化了兩個(gè)Singleton對(duì)象,那怎么解決?

簡(jiǎn)單粗暴,加鎖就好了,這是加鎖之后的代碼。

  1. public class Singleton { 
  2.     private static Singleton instance = null
  3.     /** 
  4.      * 私有構(gòu)造方法,防止被實(shí)例化 
  5.      */ 
  6.     private Singleton(){} 
  7.     /** 
  8.      * 靜態(tài)get方法 
  9.      */ 
  10.     public static synchronized Singleton getInstance(){ 
  11.         if(instance == null){ 
  12.             instance = new Singleton(); 
  13.         } 
  14.         return instance; 
  15.     } 

這是一種典型的時(shí)間換空間的寫(xiě)法,不管三七二十一,每次創(chuàng)建實(shí)例時(shí)先鎖起來(lái),再進(jìn)行判斷,嚴(yán)重降低了系統(tǒng)的處理速度。

有沒(méi)有更好的處理方式呢?

有,通過(guò)雙檢鎖做兩次判斷,代碼如下:

  1. public class Singleton { 
  2.     private static Singleton instance = null
  3.     private Singleton(){} 
  4.     public static Singleton getInstance(){ 
  5.         //先檢查實(shí)例是否存在,如果不存在才進(jìn)入下面的同步塊 
  6.         if(instance == null){ 
  7.             //同步塊,線程安全的創(chuàng)建實(shí)例 
  8.             synchronized (Singleton.class) { 
  9.                 //再次檢查實(shí)例是否存在,如果不存在才真正的創(chuàng)建實(shí)例 
  10.                 if(instance == null){ 
  11.                     instance = new Singleton(); 
  12.                 } 
  13.             } 
  14.         } 
  15.         return instance; 
  16.     } 

將synchronized關(guān)鍵字加在了內(nèi)部,也就是說(shuō)當(dāng)調(diào)用的時(shí)候是不需要加鎖的,只有在instance為null,并創(chuàng)建對(duì)象的時(shí)候才需要加鎖,性能有一定的提升。

但是,這樣就沒(méi)有問(wèn)題了嗎?

看下面的情況:在Java指令中創(chuàng)建對(duì)象和賦值操作是分開(kāi)進(jìn)行的,也就是說(shuō)instance = new Singleton();語(yǔ)句是分兩步執(zhí)行的。

但是JVM并不保證這兩個(gè)操作的先后順序,也就是說(shuō)有可能JVM會(huì)為新的Singleton實(shí)例分配空間,然后直接賦值給instance成員,然后再去初始化這個(gè)Singleton實(shí)例。

這樣就可能出錯(cuò)了,我們以A、B兩個(gè)線程為例:

A、B線程同時(shí)進(jìn)入了第一個(gè)if判斷

A首先進(jìn)入synchronized塊,由于instance為null,所以它執(zhí)行instance = new Singleton();

由于JVM內(nèi)部的優(yōu)化機(jī)制,JVM先畫(huà)出了一些分配給Singleton實(shí)例的空白內(nèi)存,并賦值給instance成員(注意此時(shí)JVM沒(méi)有開(kāi)始初始化這個(gè)實(shí)例),然后A離開(kāi)了synchronized塊。

image-20201212010622553

 

B進(jìn)入synchronized塊,由于instance此時(shí)不是null,因此它馬上離開(kāi)了synchronized塊并將結(jié)果返回給調(diào)用該方法的程序。

此時(shí)B線程打算使用Singleton實(shí)例,卻發(fā)現(xiàn)它沒(méi)有被初始化,于是錯(cuò)誤發(fā)生了。

加上volatile修飾Singleton,再做一次優(yōu)化:

  1. public class Singleton { 
  2.     private volatile static Singleton instance = null
  3.     private Singleton(){} 
  4.     public static Singleton getInstance(){ 
  5.         //先檢查實(shí)例是否存在,如果不存在才進(jìn)入下面的同步塊 
  6.         if(instance == null){ 
  7.             //同步塊,線程安全的創(chuàng)建實(shí)例 
  8.             synchronized (Singleton.class) { 
  9.                 //再次檢查實(shí)例是否存在,如果不存在才真正的創(chuàng)建實(shí)例 
  10.                 if(instance == null){ 
  11.                     instance = new Singleton(); 
  12.                 } 
  13.             } 
  14.         } 
  15.         return instance; 
  16.     } 

**通過(guò)volatile修飾的變量,不會(huì)被線程本地緩存,所有線程對(duì)該對(duì)象的讀寫(xiě)都會(huì)第一時(shí)間同步到主內(nèi)存,從而保證多個(gè)線程間該對(duì)象的準(zhǔn)確性 **

volatile的作用

  • 防止指令重排序,因?yàn)閕nstance = new Singleton()不是原子操作
  • 保證內(nèi)存可見(jiàn)

這個(gè)是比較完美的寫(xiě)法了,這種方式能夠安全的創(chuàng)建唯一的一個(gè)實(shí)例,又不會(huì)對(duì)性能有太大的影響。

但是由于volatile關(guān)鍵字可能會(huì)屏蔽掉虛擬機(jī)中一些必要的代碼優(yōu)化,所以運(yùn)行效率并不是很高,還有更優(yōu)的寫(xiě)法嗎?

通過(guò)靜態(tài)內(nèi)部類

  1. public class Singleton {   
  2.    
  3.     /* 私有構(gòu)造方法,防止被實(shí)例化 */   
  4.     private Singleton() {   
  5.     }   
  6.    
  7.     /* 此處使用一個(gè)內(nèi)部類來(lái)維護(hù)單例 */   
  8.     private static class SingletonFactory {   
  9.         private static Singleton instance = new Singleton();   
  10.     }   
  11.    
  12.     /* 獲取實(shí)例 */   
  13.     public static Singleton getInstance() {   
  14.         return SingletonFactory.instance;   
  15.     }   
  16.    
  17.     /* 如果該對(duì)象被用于序列化,可以保證對(duì)象在序列化前后保持一致 */   
  18.     public Object readResolve() {   
  19.         return getInstance();   
  20.     }   
  21. }   

使用內(nèi)部類來(lái)維護(hù)單例的實(shí)現(xiàn),JVM內(nèi)部的機(jī)制能夠保證當(dāng)一個(gè)類被加載的時(shí)候,這個(gè)類的加載過(guò)程是線程互斥的。

這樣當(dāng)我們第一次調(diào)用getInstance的時(shí)候,JVM能夠幫我們保證instance只被創(chuàng)建一次,并且會(huì)保證把賦值給instance的內(nèi)存初始化完畢, 這樣我們就不用擔(dān)心上面的問(wèn)題。

同時(shí)該方法也只會(huì)在第一次調(diào)用的時(shí)候使用互斥機(jī)制,這樣就解決了低性能問(wèn)題。這樣我們暫時(shí)總結(jié)一個(gè)完美的單例模式。

還有更完美的寫(xiě)法嗎,通過(guò)枚舉:

  1. public enum Singleton { 
  2.     /** 
  3.      * 定義一個(gè)枚舉的元素,它就代表了Singleton的一個(gè)實(shí)例。 
  4.      */ 
  5.     Instance; 

使用枚舉來(lái)實(shí)現(xiàn)單實(shí)例控制會(huì)更加簡(jiǎn)潔,而且JVM從根本上提供保障,絕對(duì)防止多次實(shí)例化,是更簡(jiǎn)潔、高效、安全的實(shí)現(xiàn)單例的方式。

最后這種也是我最青睞的一種(代碼少)。

總結(jié)

最后大家應(yīng)該都知道單例模式的寫(xiě)法了,也知道優(yōu)劣勢(shì)和使用場(chǎng)景了,那開(kāi)頭的那個(gè)問(wèn)題大家心里有答案了么?

什么?連問(wèn)題都忘了?問(wèn)題:為什么不用靜態(tài)方法而不用單例模式?

兩者其實(shí)都能實(shí)現(xiàn)我們加載的最終目的,但是他們一個(gè)是基于對(duì)象,一個(gè)是面向?qū)ο蟮?,就像我們不面向?qū)ο笠材芙鉀Q問(wèn)題一樣,面向?qū)ο蟮拇a提供一個(gè)更好的編程思想。

如果一個(gè)方法和他所在類的實(shí)例對(duì)象無(wú)關(guān),那么它就應(yīng)該是靜態(tài)的,反之他就應(yīng)該是非靜態(tài)的。如果我們確實(shí)應(yīng)該使用非靜態(tài)的方法,但是在創(chuàng)建類時(shí)又確實(shí)只需要維護(hù)一份實(shí)例時(shí),就需要用單例模式了。

我們的電商系統(tǒng)中就有很多類,有很多配置和屬性,這些配置和屬性是一定存在了,又是公共的,同時(shí)需要在整個(gè)生命周期中都存在,所以只需要一份就行,這個(gè)時(shí)候如果需要我再需要的時(shí)候new一個(gè),再給他分配值,顯然是浪費(fèi)內(nèi)存并且再賦值沒(méi)什么意義。

所以我們用單例模式或靜態(tài)方法去維持一份這些值有且只有這一份值,但此時(shí)這些配置和屬性又是通過(guò)面向?qū)ο蟮木幋a方式得到的,我們就應(yīng)該使用單例模式,或者不是面向?qū)ο蟮?,但他本身的屬性?yīng)該是面對(duì)對(duì)象的,我們使用靜態(tài)方法雖然能同樣解決問(wèn)題,但是最好的解決方案也應(yīng)該是使用單例模式。

資料參考:《java設(shè)計(jì)模式》、《為什么要用單例模式?》

 

好啦以上就是本期的全部?jī)?nèi)容,我是敖丙,你知道的越多,你不知道的越多,我們下期見(jiàn)。

 

責(zé)任編輯:武曉燕 來(lái)源: 三太子敖丙
相關(guān)推薦

2013-11-26 16:20:26

Android設(shè)計(jì)模式

2022-02-06 22:30:36

前端設(shè)計(jì)模式

2021-02-01 10:01:58

設(shè)計(jì)模式 Java單例模式

2016-03-28 10:23:11

Android設(shè)計(jì)單例

2022-06-07 08:55:04

Golang單例模式語(yǔ)言

2024-02-04 12:04:17

2015-09-06 11:07:52

C++設(shè)計(jì)模式單例模式

2021-08-11 17:22:11

設(shè)計(jì)模式單例

2022-09-29 08:39:37

架構(gòu)

2022-01-12 13:33:25

工廠模式設(shè)計(jì)

2020-10-23 09:40:26

設(shè)計(jì)模式

2020-11-03 13:05:18

命令模式

2020-11-04 08:54:54

狀態(tài)模式

2021-09-07 10:44:35

異步單例模式

2022-03-29 07:52:07

設(shè)計(jì)模式單例設(shè)計(jì)模式java

2024-03-06 13:19:19

工廠模式Python函數(shù)

2021-02-07 23:58:10

單例模式對(duì)象

2011-03-16 10:13:31

java單例模式

2021-06-09 08:53:34

設(shè)計(jì)模式策略模式工廠模式

2020-10-19 09:28:00

抽象工廠模式
點(diǎn)贊
收藏

51CTO技術(shù)棧公眾號(hào)