當Kotlin完美邂逅設計模式之單例模式(一)

時間 2019-11-06

標籤 kotlin 完美邂逅設計模式简体版

原文原文鏈接

簡述: 從這篇文章開始，我將帶領你們一塊兒來探討一下Kotlin眼中的設計模式。說下爲何想着要開始這麼一個系列文章。主要基於下面幾點緣由:java

一、設計模式一直是開發者看懂Android源碼的一個很大障礙。因此想要理解和運用源碼中一些設計思想和技巧，首先看懂源碼是第一步，而看懂源碼，又得須要設計模式和數據結構算法(個人每週一算法和數據結構文章系列也開始了)做爲基礎，不然看起來雲裏霧裏，只能死記硬背別人總結的結論，最終仍是沒法消化和理解運用。
二、Kotlin中設計模式的實現和Java的實現仍是有很大的差異的，利用Kotlin語言自身的特性實現設計模式比硬生生套用Java中的設計模式實現要更優雅和更高效。固然每一個設計模式我會對比Java與Kotlin實現區別，以便理解更加深入。
三、據瞭解Kotlin有關設計模式實現的文章目前在國內仍是比較少的，因此想系統地去寫一個有關Kotlin邂逅設計模式的系列文章。

說下最終的目標吧，最終目標是有基礎能力在分析的源碼時候可以站在一個全局角度去思考，而不是一頭扎入茫茫源碼中沒法自拔迷失自我。後面也會隨即出一些有關源碼分析的文章。因此請暫時先好好掌握這些基礎的工具。算法

1、介紹

單例模式是開發者最爲常見的一種設計模式，也是23種設計模式中最爲簡單一種設計模式。大部分的開發者都知道它的使用和原理。單例模式顧名思義就是在應用這個模式時，單例對象的類必須是隻有一個對象實例存在。在一些應用場景中咱們只須要一個全局惟一的對象實例去調度總體行爲。還有一些狀況爲了系統資源開銷考慮，避免重複建立多個實例，每每採用單例模式來保證全局只有一個實例對象。數據庫

2、定義

保證某個類只有一個實例對象，該實例對象在內部進行實例化，而且提供了一個獲取該實例對象的全局訪問點。設計模式

3、基本要求

一、構造器私有化，private修飾，主要爲了防止外部私自建立該單例類的對象實例
二、提供一個該實例對象全局訪問點，在Java中通常是以公有的靜態方法或者枚舉返回單例類對象
三、在多線程環境下保證單例類有且只有一個對象實例，以及在多線程環境下獲取單例類對象實例須要保證線程安全。
四、在反序列化時保證單例類有且只有一個對象實例。

4、使用場景

通常用於肯定某個類只須要一個實例對象，從而避免中了頻繁建立多個對象實例所帶來資源和性能開銷。例如常見的數據庫鏈接或IO操做等。數組

5、UML類圖

6、餓漢式單例

餓漢式單例模式是實現單例模式比較簡單的一種方式，它有個特色就是無論需不須要該單例實例，該實例對象都會被實例化。安全

一、Kotlin實現

在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<String>) {
    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中都沒法私自去建立新的單例對象。app

二、Java實現

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簡單得多得多。ide

7、線程安全的懶漢式單例

但是有時候咱們並不想當類加載的時候就去建立這個單例實例，而是想當咱們使用這個實例的時候纔去初始化它。因而乎就有了懶漢式的單例模式

一、Kotlin實現

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<String>) {
    KLazilySingleton.getInstance().doSomething()
}
//在Java中調用
 KLazilySingleton.getInstance().doSomething();
複製代碼

二、Java實現

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;
    }
}
複製代碼

8、DCL(double check lock)改造懶漢式單例

咱們知道線程安全的單例模式直接是使用synchronized同步鎖，鎖住getInstance方法，每一次調用該方法的時候都得獲取鎖，可是若是這個單例已經被初始化了，其實按道理就不須要申請同步鎖了，直接返回這個單例類實例便可。因而就有了DCL實現單例方式。

一、Java中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實現

在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<String>) {
    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();
      }
   }
複製代碼

三、Kotlin的lazy屬性代理內部實現源碼分析

//expect關鍵字標記這個函數是平臺相關，咱們須要找到對應的actual關鍵字實現表示平臺中一個相關實現 
public expect fun <T> lazy(mode: LazyThreadSafetyMode, initializer: () -> T): Lazy<T>

//對應多平臺中一個平臺相關實現lazy函數
public actual fun <T> lazy(mode: LazyThreadSafetyMode, initializer: () -> T): Lazy<T> =
    when (mode) {//根據不一樣mode，返回不一樣的Lazy的實現，咱們重點看下SynchronizedLazyImpl
        LazyThreadSafetyMode.SYNCHRONIZED -> SynchronizedLazyImpl(initializer)
        LazyThreadSafetyMode.PUBLICATION -> SafePublicationLazyImpl(initializer)
        LazyThreadSafetyMode.NONE -> UnsafeLazyImpl(initializer)
    }

private class SynchronizedLazyImpl<out T>(initializer: () -> T, lock: Any? = null) : Lazy<T>, Serializable {
    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存在多線程安全問題，咱們都知道線程安全主要來自主存和工做內存數據不一致以及重排序(指令重排序或編譯器重排序形成的)。那麼DCL存在什麼問題呢？首先，mInstance = new LazySingleton() 不是一個原子操做而是分爲三步進行:

一、給LazySingleton實例分配內存
二、調用LazySingleton的構造函數，初始化成員字段
三、將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;

9、靜態內部類單例

DCL雖然在必定程度上能解決資源消耗、多餘synchronized同步、線程安全等問題，可是某些狀況下還會存在DCL失效問題，儘管在JDK1.5以後經過具體化volatile原語來解決DCL失效問題，可是它始終並非優雅一種解決方式，在多線程環境下通常不推薦DCL的單例模式。因此引出靜態內部類單例實現

一、Kotlin實現

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
    }
}
複製代碼

二、Java實現

//使用靜態內部單例模式
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;
    }
}
複製代碼

10、枚舉單例

其實細心的小夥伴就會觀察到上面例子中我都會去實現Serializable接口，而且會去實現readResolve方法。這是爲了反序列化會從新建立對象而使得原來的單例對象再也不惟一。經過序列化一個單例對象將它寫入到磁盤中，而後再從磁盤中讀取出來，從而能夠得到一個新的實例對象，即便構造器是私有的，反序列化會經過其餘特殊途徑建立單例類的新實例。然而爲了讓開發者可以控制反序列化，提供一個特殊的鉤子方法那就是readResolve方法，這樣一來咱們只須要在readResolve直接返回原來的實例便可，就不會建立新的對象。

枚舉單例實現，就是爲了防止反序列化，由於咱們都知道枚舉類反序列化是不會建立新的對象實例的。 Java的序列化機制對枚舉類型作了特殊處理，通常來講在序列枚舉類型時，只會存儲枚舉類的引用和枚舉常量名稱，反序列化的過程當中，這些信息被用來在運行時環境中查找存在的枚舉類型對象，枚舉類型的序列化機制保證只會查找已經存在的枚舉類型實例，而不是建立新的實例。

一、Kotlin實現

enum class KEnumSingleton {
    INSTANCE;

    fun doSomeThing() {
        println("do some thing")
    }
}
//在Kotlin中調用
fun main(args: Array<String>) {
    KEnumSingleton.INSTANCE.doSomeThing()
}
//在Java中調用
 KEnumSingleton.INSTANCE.doSomeThing();
複製代碼

二、Java實現

public enum EnumSingleton {
    INSTANCE;
    public void doSomeThing() {
        System.out.println("do some thing");
    }
}

//調用方式
EnumSingleton.INSTANCE.doSomeThing();
複製代碼