當Kotlin完美邂逅設計模式之單例模式(一)
簡述: 從這篇文章開始，我將帶領大家一起來探討一下Kotlin眼中的設計模式。說下為什么想著要開始這么一個系列文章。主要基于下面幾點原因:
1、設計模式一直是開發者看懂Android源碼的一個很大障礙。所以想要理解和運用源碼中一些設計思想和技巧，首先看懂源碼是第一步，而看懂源碼，又得需要設計模式和數據結構算法(我的每周一算法和數據結構文章系列也開始了)作為基礎，否則看起來云里霧里，只能死記硬背別人總結的結論，最終還是無法消化和理解運用。
簡述: 從這篇文章開始，我將帶領大家一起來探討一下Kotlin眼中的設計模式。說下為什么想著要開始這么一個系列文章。主要基于下面幾點原因:
1、設計模式一直是開發者看懂Android源碼的一個很大障礙。所以想要理解和運用源碼中一些設計思想和技巧，首先看懂源碼是第一步，而看懂源碼，又得需要設計模式和數據結構算法(我的每周一算法和數據結構文章系列也開始了)作為基礎，否則看起來云里霧里，只能死記硬背別人總結的結論，最終還是無法消化和理解運用。
2、Kotlin中設計模式的實現和Java的實現還是有很大的差別的，利用Kotlin語言自身的特性實現設計模式比硬生生套用Java中的設計模式實現要更優雅和更高效。當然每個設計模式我會對比Java與Kotlin實現區別，以便理解更加深刻。
3、據了解Kotlin有關設計模式實現的文章目前在國內還是比較少的，所以想系統地去寫一個有關Kotlin邂逅設計模式的系列文章。
說下最終的目標吧，最終目標是有基礎能力在分析的源碼時候能夠站在一個全局角度去思考，而不是一頭扎入茫茫源碼中無法自拔迷失自我。后面也會隨即出一些有關源碼分析的文章。所以請暫時先好好掌握這些基礎的工具。
一、介紹
單例模式是開發者最為常見的一種設計模式，也是23種設計模式中最為簡單一種設計模式。大部分的開發者都知道它的使用和原理。單例模式顧名思義就是在應用這個模式時，單例對象的類必須是只有一個對象實例存在。在一些應用場景中我們只需要一個全局唯一的對象實例去調度整體行為。還有一些情況為了系統資源開銷考慮，避免重復創建多個實例，往往采用單例模式來保證全局只有一個實例對象。
二、定義
保證某個類只有一個實例對象，該實例對象在內部進行實例化，并且提供了一個獲取該實例對象的全局訪問點。
三、基本要求
1、構造器私有化，private修飾，主要為了防止外部私自創建該單例類的對象實例
2、提供一個該實例對象全局訪問點，在Java中一般是以公有的靜態方法或者枚舉返回單例類對象
3、在多線程環境下保證單例類有且只有一個對象實例，以及在多線程環境下獲取單例類對象實例需要保證線程安全。
4、在反序列化時保證單例類有且只有一個對象實例。
四、使用場景
一般用于確定某個類只需要一個實例對象，從而避免中了頻繁創建多個對象實例所帶來資源和性能開銷。例如常見的數據庫連接或IO操作等。
五、UML類圖
六、餓漢式單例
餓漢式單例模式是實現單例模式比較簡單的一種方式，它有個特點就是不管需不需要該單例實例，該實例對象都會被實例化。
在Kotlin中實現一個餓漢式單例模式可以說是非常非常簡單，只需要定義一個object對象表達式即可，無需手動去設置構造器私有化和提供全局訪問點，這一點Kotlin編譯器全給你做好了。
object?KSingleton?:?Serializable?{//實現Serializable序列化接口，通過私有、被實例化的readResolve方法控制反序列化
fun?doSomething()?{
println("do?some?thing")
}
private?fun?readResolve():?Any?{//防止單例對象在反序列化時重新生成對象
return?KSingleton//由于反序列化時會調用readResolve這個鉤子方法，只需要把當前的KSingleton對象返回而不是去創建一個新的對象
}
}
//在Kotlin中使用KSingleton
fun?main(args:?Array
KSingleton.doSomething()//像調用靜態方法一樣，調用單例類中的方法
}
//在Java中使用KSingleton
public?class?TestMain?{
public?static?void?main(String[]?args)?{
KSingleton.INSTANCE.doSomething();//通過拿到KSingleton的公有單例類靜態實例INSTANCE,?再通過INSTANCE調用單例類中的方法
}
}
KSingleton反編譯成Java代碼
public?final?class?KSingleton?implements?Serializable?{
public?static?final?KSingleton?INSTANCE;
public?final?void?doSomething()?{
String?var1?=?"do?some?thing";
System.out.println(var1);
}
private?final?Object?readResolve()?{
return?INSTANCE;//可以看到readResolve方法直接返回了INSTANCE而不是創建新的實例
}
static?{//靜態代碼塊初始化KSingleton實例，不管有沒有使用，只要KSingleton被加載了，
//靜態代碼塊就會被調用，KSingleton實例就會被創建，并賦值給INSTANCE
KSingleton?var0?=?new?KSingleton();
INSTANCE?=?var0;
}
}
可能會有人疑問: 沒有看到構造器私有化，實際上這一點已經在編譯器層面做了限制，不管你是在Java還是Kotlin中都無法私自去創建新的單例對象。
public?class?Singleton?implements?Serializable?{
private?Singleton()?{//構造器私有化
}
private?static?final?Singleton?mInstance?=?new?Singleton();
public?static?Singleton?getInstance()?{//提供公有獲取單例對象的函數
return?mInstance;
}
//防止單例對象在反序列化時重新生成對象
private?Object?readResolve()?throws?ObjectStreamException?{
return?mInstance;
}
}
對比一下Kotlin和Java的餓漢式的單例實現發現，是不是覺得Kotlin會比Java簡單得多得多。
七、線程安全的懶漢式單例
可是有時候我們并不想當類加載的時候就去創建這個單例實例，而是想當我們使用這個實例的時候才去初始化它。于是乎就有了懶漢式的單例模式
class?KLazilySingleton?private?constructor()?:?Serializable?{
fun?doSomething()?{
println("do?some?thing")
}
companion?object?{
private?var?mInstance:?KLazilySingleton??=?null
get()?{
return?field??:?KLazilySingleton()
}
@JvmStatic
@Synchronized//添加synchronized同步鎖
fun?getInstance():?KLazilySingleton?{
return?requireNotNull(mInstance)
}
}
//防止單例對象在反序列化時重新生成對象
private?fun?readResolve():?Any?{
return?KLazilySingleton.getInstance()
}
}
//在Kotlin中調用
fun?main(args:?Array
KLazilySingleton.getInstance().doSomething()
}
//在Java中調用
KLazilySingleton.getInstance().doSomething();
class?LazilySingleton?implements?Serializable?{
private?static?LazilySingleton?mInstance;
private?LazilySingleton()?{}//構造器私有化
public?static?synchronized?LazilySingleton?getInstance()?{//synchronized同步鎖保證多線程調用getInstance方法線程安全
if?(mInstance?==?null){
mInstance?=?new?LazilySingleton();
}
return?mInstance;
}
private?Object?readResolve()?throws?ObjectStreamException?{//防止反序列化
return?mInstance;
}
}
八、DCL(double check lock)改造懶漢式單例
我們知道線程安全的單例模式直接是使用synchronized同步鎖，鎖住getInstance方法，每一次調用該方法的時候都得獲取鎖，但是如果這個單例已經被初始化了，其實按道理就不需要申請同步鎖了，直接返回這個單例類實例即可。于是就有了DCL實現單例方式。
//DCL實現單例模式
public?class?LazySingleTon?implements?Serializable?{
//靜態成員私有化，注意使用volatile關鍵字，因為會存在DCL失效的問題
private?volatile?static?LazySingleTon?mInstance?=?null;
private?LazySingleTon()?{?//構造器私有化
}
//公有獲取單例對象的函數
//DCL(Double?Check?Lock)?既能在需要的時候初始化單例，又能保證線程安全，且單例對象初始化完后，調用getInstance不需要進行同步鎖
public?static?LazySingleTon?getInstance()?{
if?(mInstance?==?null)?{//為了防止單例對象初始化完后，調用getInstance再次重復進行同步鎖
synchronized?(LazySingleTon.class)?{
if?(mInstance?==?null)?{
mInstance?=?new?LazySingleTon();
}
}
}
return?mInstance;
}
private?Object?readResolve()?throws?ObjectStreamException?{
return?mInstance;
}
}
在Kotlin中有個天然特性可以支持線程安全DCL的單例，可以說也是非常非常簡單，就僅僅3行代碼左右，那就是Companion Object + lazy屬性代理，一起來看下吧。
class?KLazilyDCLSingleton?private?constructor()?:?Serializable?{//private?constructor()構造器私有化
fun?doSomething()?{
println("do?some?thing")
}
private?fun?readResolve():?Any?{//防止單例對象在反序列化時重新生成對象
return?instance
}
companion?object?{
//通過@JvmStatic注解，使得在Java中調用instance直接是像調用靜態函數一樣，
//類似KLazilyDCLSingleton.getInstance(),如果不加注解，在Java中必須這樣調用:?KLazilyDCLSingleton.Companion.getInstance().
@JvmStatic
//使用lazy屬性代理，并指定LazyThreadSafetyMode為SYNCHRONIZED模式保證線程安全
val?instance:?KLazilyDCLSingleton?by?lazy(LazyThreadSafetyMode.SYNCHRONIZED)?{?KLazilyDCLSingleton()?}
}
}
//在Kotlin中調用，直接通過KLazilyDCLSingleton類名調用instance
fun?main(args:?Array
KLazilyDCLSingleton.instance.doSomething()
}
//在Java中調用
public?class?TestMain?{
public?static?void?main(String[]?args)?{
//加了@JvmStatic注解后，可以直接KLazilyDCLSingleton.getInstance()，不會打破Java中調用習慣，和Java調用方式一樣。
KLazilyDCLSingleton.getInstance().doSomething();
//沒有加@JvmStatic注解，只能這樣通過Companion調用
KLazilyDCLSingleton.Companion.getInstance().doSomething();
}
}
注意: 建議上面例子中添加@JvmStatic注解，Kotlin這門語言可謂是操碎了心，做的很小心翼翼，為了不讓Java開發者打破他們的調用習慣，讓調用根本無法感知到是Kotlin編寫，因為外部調用方式和Java方式一樣。如果硬生生把Companion對象暴露給Java開發者他們可能會感到一臉懵逼。
可能大家對lazy和Companion Object功能強大感到一臉懵，讓我們一起瞅瞅反編譯后的Java代碼你就會恍然大悟了:
public?final?class?KLazilyDCLSingleton?implements?Serializable?{
@NotNull
private?static?final?Lazy?instance$delegate;
//Companion提供公有全局訪問點，KLazilyDCLSingleton.Companion實際上一個餓漢式的單例模式
public?static?final?KLazilyDCLSingleton.Companion?Companion?=?new?KLazilyDCLSingleton.Companion((DefaultConstructorMarker)null);
public?final?void?doSomething()?{
String?var1?=?"do?some?thing";
System.out.println(var1);
}
private?final?Object?readResolve()?{
return?Companion.getInstance();
}
private?KLazilyDCLSingleton()?{
}
static?{//注意:?可以看到靜態代碼塊中并不是初始化KLazilyDCLSingleton的instance而是初始化它的Lazy代理對象，說明KLazilyDCLSingleton類被加載了，
//但是KLazilyDCLSingleton的instance并沒有被初始化，符合懶加載規則，那么什么時候初始化instance這就涉及到了屬性代理知識了，下面會做詳細分析
instance$delegate?=?LazyKt.lazy(LazyThreadSafetyMode.SYNCHRONIZED,?(Function0)null.INSTANCE);
}
//?$FF:?synthetic?method
public?KLazilyDCLSingleton(DefaultConstructorMarker?$constructor_marker)?{
this();
}
@NotNull
public?static?final?KLazilyDCLSingleton?getInstance()?{
return?Companion.getInstance();//這里可以看到加了@JvmStatic注解后，getInstance內部把我們省略Companion.getInstance()這一步，這樣一來Java調用者就直接KLazilyDCLSingleton.getInstance()獲取單例實例
}
//Companion靜態內部類實際上也是一個單例模式
public?static?final?class?Companion?{
//?$FF:?synthetic?field
static?final?KProperty[]?$$delegatedProperties?=?new?KProperty[]{(KProperty)Reflection.property1(new?PropertyReference1Impl(Reflection.getOrCreateKotlinClass(KLazilyDCLSingleton.Companion.class),?"instance",?"getInstance()Lcom/mikyou/design_pattern/singleton/kts/KLazilyDCLSingleton;"))};
/**?@deprecated?*/
//?$FF:?synthetic?method
@JvmStatic
public?static?void?instance$annotations()?{
}
@NotNull
//這個方法需要注意，最終instance初始化和獲取將在這里進行
public?final?KLazilyDCLSingleton?getInstance()?{
//拿到代理對象
Lazy?var1?=?KLazilyDCLSingleton.instance$delegate;
KProperty?var3?=?$$delegatedProperties[0];
//代理對象的getValue方法就是初始化instance和獲取instance的入口。內部會判斷instance是否被初始化過沒有就會返回新創建的對象，
//初始化過直接返回上一次初始化的對象。所以只有真正調用getInstance方法需要這個實例的時候instance才會被初始化。
return?(KLazilyDCLSingleton)var1.getValue();
}
private?Companion()?{//Companion構造器私有化
}
//?$FF:?synthetic?method
public?Companion(DefaultConstructorMarker?$constructor_marker)?{
this();
}
}
//expect關鍵字標記這個函數是平臺相關，我們需要找到對應的actual關鍵字實現表示平臺中一個相關實現
public?expect?fun?
//對應多平臺中一個平臺相關實現lazy函數
public?actual?fun?
when?(mode)?{//根據不同mode，返回不同的Lazy的實現，我們重點看下SynchronizedLazyImpl
LazyThreadSafetyMode.SYNCHRONIZED?->?SynchronizedLazyImpl(initializer)
LazyThreadSafetyMode.PUBLICATION?->?SafePublicationLazyImpl(initializer)
LazyThreadSafetyMode.NONE?->?UnsafeLazyImpl(initializer)
}
private?class?SynchronizedLazyImpl
private?var?initializer:?(()?->?T)??=?initializer
@Volatile?private?var?_value:?Any??=?UNINITIALIZED_VALUE//為了解決DCL帶來指令重排序導致主存和工作內存數據不一致的問題，這里使用Volatile原語注解。具體Volatile為什么能解決這樣的問題請接著看后面的分析
private?val?lock?=?lock??:?this
override?val?value:?T
get()?{//當外部調用value值，get訪問器會被調用
val?_v1?=?_value
if?(_v1?!==?UNINITIALIZED_VALUE)?{//進行第一層的Check,?如果這個值已經初始化過了，直接返回_v1，避免走下面synchronized獲取同步鎖帶來不必要資源開銷。
@Suppress("UNCHECKED_CAST")
return?_v1?as?T
}
return?synchronized(lock)?{
val?_v2?=?_value
if?(_v2?!==?UNINITIALIZED_VALUE)?{//進行第二層的Check，主要是為了_v2被初始化直接返回
@Suppress("UNCHECKED_CAST")?(_v2?as?T)
}?else?{
//如果沒有初始化執行initializer!!()?lambda,
//實際上相當于執行外部調用傳入的?by?lazy(LazyThreadSafetyMode.SYNCHRONIZED)?{?KLazilyDCLSingleton()?}?中的KLazilyDCLSingleton()也即是返回KLazilyDCLSingleton實例對象
val?typedValue??initializer!!()
_value?=?typedValue//并把這個實例對象保存在_value中
initializer?=?null
typedValue
}
}
}
override?fun?isInitialized():?Boolean?=?_value?!==?UNINITIALIZED_VALUE
override?fun?toString():?String?=?if?(isInitialized())?value.toString()?else?"Lazy?value?not?initialized?yet."
private?fun?writeReplace():?Any?=?InitializedLazyImpl(value)
}
問題分析:
DCL存在多線程安全問題，我們都知道線程安全主要來自主存和工作內存數據不一致以及重排序(指令重排序或編譯器重排序造成的)。那么DCL存在什么問題呢？
首先，mInstance = new LazySingleton() 不是一個原子操作而是分為三步進行:
1、給LazySingleton實例分配內存
2、調用LazySingleton的構造函數，初始化成員字段
3、將mInstance對象引用指向分配的內存空間(此時mInstance不為null)
在JDK1.5之前版本的Java內存模型中，Cache,寄存器到主存回寫順序規則，無法保證第2和第3執行的順序，可能是1-2-3，也有可能是1-3-2
若A線程先執行了第1步，第3步，此時切換到B線程，由于A線程中已經執行了第3步所以mInstance不為null，那么B線程中直接把mInstance取走，由于并沒有執行第2步使用的時候就會報錯。
解決問題:
為了解決該問題，JDK1.5之后，具體化了volatile關鍵字，能夠確保每次都是從主存獲取最新有效值。所以需要private volatile static LazySingleTon mInstance = null;
九、靜態內部類單例
DCL雖然在一定程度上能解決資源消耗、多余synchronized同步、線程安全等問題，但是某些情況下還會存在DCL失效問題，盡管在JDK1.5之后通過具體化volatile原語來解決DCL失效問題，但是它始終并不是優雅一種解決方式，在多線程環境下一般不推薦DCL的單例模式。所以引出靜態內部類單例實現
class?KOptimizeSingleton?private?constructor():?Serializable?{//private?constructor()構造器私有化
companion?object?{
@JvmStatic
fun?getInstance():?KOptimizeSingleton?{//全局訪問點
return?SingletonHolder.mInstance
}
}
fun?doSomething()?{
println("do?some?thing")
}
private?object?SingletonHolder?{//靜態內部類
val?mInstance:?KOptimizeSingleton?=?KOptimizeSingleton()
}
private?fun?readResolve():?Any?{//防止單例對象在反序列化時重新生成對象
return?SingletonHolder.mInstance
}
}
//使用靜態內部單例模式
public?class?OptimizeSingleton?implements?Serializable?{
//構造器私有化
private?OptimizeSingleton()?{
}
//靜態私有內部類
private?static?class?SingletonHolder?{
private?static?final?OptimizeSingleton?sInstance?=?new?OptimizeSingleton();
}
//公有獲取單例對象的函數
public?static?OptimizeSingleton?getInstance()?{
return?SingletonHolder.sInstance;
}
public?void?doSomeThings()?{
System.out.println("do?some?things");
}
//防止反序列化重新創建對象
private?Object?readResolve()?{
return?SingletonHolder.sInstance;
}
}
十、枚舉單例
其實細心的小伙伴就會觀察到上面例子中我都會去實現Serializable接口，并且會去實現readResolve方法。這是為了反序列化會重新創建對象而使得原來的單例對象不再唯一。通過序列化一個單例對象將它寫入到磁盤中，然后再從磁盤中讀取出來，從而可以獲得一個新的實例對象，即使構造器是私有的，反序列化會通過其他特殊途徑創建單例類的新實例。然而為了讓開發者能夠控制反序列化，提供一個特殊的鉤子方法那就是readResolve方法，這樣一來我們只需要在readResolve直接返回原來的實例即可，就不會創建新的對象。
枚舉單例實現，就是為了防止反序列化，因為我們都知道枚舉類反序列化是不會創建新的對象實例的。 Java的序列化機制對枚舉類型做了特殊處理，一般來說在序列枚舉類型時，只會存儲枚舉類的引用和枚舉常量名稱，反序列化的過程中，這些信息被用來在運行時環境中查找存在的枚舉類型對象，枚舉類型的序列化機制保證只會查找已經存在的枚舉類型實例，而不是創建新的實例。
enum?class?KEnumSingleton?{
INSTANCE;
fun?doSomeThing()?{
println("do?some?thing")
}
}
//在Kotlin中調用
fun?main(args:?Array
KEnumSingleton.INSTANCE.doSomeThing()
}
//在Java中調用
KEnumSingleton.INSTANCE.doSomeThing();
public?enum?EnumSingleton?{
INSTANCE;
public?void?doSomeThing()?{
System.out.println("do?some?thing");
}
}
//調用方式
EnumSingleton.INSTANCE.doSomeThing();
歡迎關注Kotlin開發者聯盟，這里有最新Kotlin技術文章，每周會不定期翻譯一篇Kotlin國外技術文章。如果你也喜歡Kotlin，歡迎加入我們~~~
Kotlin系列文章，歡迎查看:
數據結構與算法系列:
每周一算法之二分查找(Kotlin描述)
Kotlin 原創系列：
教你如何完全解析Kotlin中的類型系統
如何讓你的回調更具Kotlin風味
Jetbrains開發者日見聞(三)之Kotlin1.3新特性(inline class篇)
JetBrains開發者日見聞(二)之Kotlin1.3的新特性(Contract契約與協程篇)
JetBrains開發者日見聞(一)之Kotlin/Native 嘗鮮篇
教你如何攻克Kotlin中泛型型變的難點(實踐篇)
教你如何攻克Kotlin中泛型型變的難點(下篇)
教你如何攻克Kotlin中泛型型變的難點(上篇)
Kotlin的獨門秘籍Reified實化類型參數(下篇)
有關Kotlin屬性代理你需要知道的一切
淺談Kotlin中的Sequences源碼解析
淺談Kotlin中集合和函數式API完全解析-上篇
淺談Kotlin語法篇之lambda編譯成字節碼過程完全解析
淺談Kotlin語法篇之Lambda表達式完全解析
淺談Kotlin語法篇之擴展函數
淺談Kotlin語法篇之頂層函數、中綴調用、解構聲明
淺談Kotlin語法篇之如何讓函數更好地調用
淺談Kotlin語法篇之變量和常量
淺談Kotlin語法篇之基礎語法
Effective Kotlin翻譯系列
[譯]Effective Kotlin系列之考慮使用原始類型的數組優化性能(五)
[譯]Effective Kotlin系列之使用Sequence來優化集合的操作(四)
[譯]Effective Kotlin系列之探索高階函數中inline修飾符(三)
[譯]Effective Kotlin系列之遇到多個構造器參數要考慮使用構建器(二)
[譯]Effective Kotlin系列之考慮使用靜態工廠方法替代構造器(一)
翻譯系列：
[譯]記一次Kotlin官方文檔翻譯的PR(內聯類)
[譯]Kotlin中內聯類的自動裝箱和高性能探索(二)
[譯]Kotlin中內聯類(inline class)完全解析(一)
[譯]Kotlin的獨門秘籍Reified實化類型參數(上篇)
[譯]Kotlin泛型中何時該用類型形參約束?
[譯] 一個簡單方式教你記住Kotlin的形參和實參
[譯]Kotlin中是應該定義函數還是定義屬性?
[譯]如何在你的Kotlin代碼中移除所有的!!(非空斷言)
[譯]掌握Kotlin中的標準庫函數: run、with、let、also和apply
[譯]有關Kotlin類型別名(typealias)你需要知道的一切
[譯]Kotlin中是應該使用序列(Sequences)還是集合(Lists)?
[譯]Kotlin中的龜(List)兔(Sequence)賽跑
實戰系列:
用Kotlin擼一個圖片壓縮插件ImageSlimming-導學篇(一)
用Kotlin擼一個圖片壓縮插件-插件基礎篇(二)
用Kotlin擼一個圖片壓縮插件-實戰篇(三)
淺談Kotlin實戰篇之自定義View圖片圓角簡單應用
Java Kotlin
版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。
相關文章
