Kotlin 静态内部类单例模式的正确实现方式

本篇是对现网上流传的 Kotlin 实现静态内部类单例模式的纠正，为了把原理说清楚，文章前奏可能会有些长，熟悉静态内部类单例模式原理的朋友，可以直接跳转到文章最后，直接看结果即可。

最近在整理基础库的时候，需要一个基础类来存储初始化的数据，例如应用的 Application Context，用户的登录 token 等等信息，这些基本都是应用全局类的信息，在应用的整个生命周期都会用到，因此我将这个基础类设计为单例模式来优化性能。

我知道的单例模式就有6钟，饿汉式、懒汉式、线程安全的懒汉式，volatile + 双重校验锁试，静态内部类式,，枚举式。

我挑哪种来用呢？那肯定是性能最好的呀！

一个单例模式性能的好坏，主要考究其在复杂的生产环境下，还能否保证实例的唯一性。

可能会碰到的生产环境有以下几种，如果在以下情况下不能保证实例的唯一，那么该单例模式就是有瑕疵的。

多线程情况下是否会被多次创建。
反射调用单例类的构造方法时，能否重新创建实例。
如果单例类实现了 Serializable 接口，其反序列化时生成的实例是否与序列化时的实例是同一个。

枚举式据说是最安全，性能最好的单例模式，Java 不允许反射调用枚举类的构造方法，对枚举类的序列化过程也做了特殊处理，同时枚举类利用语言特性保证了多线程安全。

不过枚举式我用的非常少，个人不太习惯，我挑了使用最顺手的静态内部类式，这种单例模式我用的最多。

然而静态内部类单例模式是有瑕疵的，静态内部类利用了类的加载机制保证了多线程安全，但其构造方法仍然可以通过反射的方式被外部调用。如果类实现了 Serializable 接口，那么其默认的反序列化过程生成的对象与序列化时的对象也是不同的。

虽然有瑕疵，但都是有解决办法滴。

解决反射调用构造方式时可能会重新生成对象的问题，我们只需要在类的构造方法里添加一个标志位校验就可以解决：

class Common private constructor(){companion object {private var flag = false}// 防止反射破坏单例init {if (!flag) {flag = true} else {throw Throwable("SingleTon is being attacked.")}}
}

而反序列化的问题，可以通过在类中声明 readResolve()方法，在反序列化返回对象前替换成我们的单例解决。

fun readResolve(): Any {return Common.getInstance()
}

更多解决单例模式瑕疵问题的知识，这里就不展开啦，有兴趣的同学可以自己去网上冲浪一下。

考虑到我的单例类使用场景，不需要实现序列化接口，因此只需要解决反射调用的问题就行了。

瑕疵解决了，那么现在就来给我的单例类实现一个静态内部类的单例模式吧~

静态内部类单例模式，作为一个 Java 老手，用 Java 写我可谓是信手拈来，直接用文档编辑器莽着敲，都不带看的：

// java 实现静态内部类单例
class Common {private static boolean flag = false;// 解决反射调用问题private Common() {if (!flag) {flag = true} else {throw new Throwable("SingleTon is being attachked.")}}public static final Common getInstance() {return CommonSingleTonHolder.sInstance}private static final class CommonSingleTonHolder {private static Common sInstance = new Common();}
}

抬手之间还解决了反射调用的问题~

为什么说静态内部类的单例模式是线程安全的呢？ 这里要简单提一下类的加载机制了

简单的说，类加载过程包括五个过程：加载、校验、准备、解析、初始化。

加载：虚拟机通过类的全限定类名获取类的二进制字节流，通过这个字节流代表的静态存储结构转换为方法区中的运行时数据存储结构，并在堆中生成一个class对象，来作为访问这个运行时数据存储结构的入口。
校验：虚拟机校验类的字节流文件是否符合虚拟机的规范，是否会对虚拟机的安全造成影响。主要包括文件格式校验，元数据校验，字节码校验，符号引用校验。
准备：为类中的静态变量分配堆内存，并将其初始化为默认值
解析：将Class文件中的符号引用转化为指向内存的直接引用。
初始化：执行类构造器的clinit方法，clinit方法里面包含类的静态变量的赋值操作和静态语句块。

类的静态变量会在准备阶段分配内存，并被初始化为默认值。在初始化阶段，会执行类的<clinit>()方法，执行静态变量的赋值操作和静态语句块。

虚拟机会保证一个类的<clinit>()方法在多线程环境中被正确地加锁、同步，如果多个线程同时去初始化一个类，那么只会有一个线程去执行这个类的<clinit>()方法，其他线程都需要阻塞等待，直到活动线程执行<clinit>()方法完毕。因此说静态内部类的单例在多线程访问时也是线程安全的。

静态内部类单例模式也是一种懒汉模式，只有在执行 Common.getInstance()时才会去加载 CommonSingleTonHolder 类，为 sInstance 静态属性初始化。

Kotlin 实现静态内部类单例模式

前文介绍了这么多都是有关于 Java 的实现方式，用 Kotlin 怎么实现呢？

本着伸手就有，决不自己动手的原则，网上搜索一下，有能直接拿来用的，直接 copy copy~

现网上传的 Kotlin 静态内部类单例模式

// google 第一页搜索内容，截止到 2022 年 1 月 14 日
class SingletonDemo private constructor() {companion object {val instance = SingletonHolder.holder}private object SingletonHolder {val holder = SingletonDemo()}
}

搜索完点击第一条，返回了上面的搜索结果。

喔，看着挺简单的，看看有没其他实现，陆续点击第二条第三条搜索内容，发现一整页的静态内部类单例都是返回这样的结果。

大家都一样，得，就你了。ctrl + c，ctrl + v，改个类名，nice，搞定。

class Common private constructor(){// 防止反射破坏单例init {if (!flag) {flag = true} else {throw Throwable("SingleTon is being attacked.")}}companion object {private var flag = false// 单例val instance = CommonSingletonHolder.holder}/*** 静态内部类单例*/private object CommonSingletonHolder {val holder = Common()}}

通过 Common.instance就可以访问我们的单例了。完美完美，对比一下 Kotlin 与 Java 的实现方式，非常像！

把上面的 Kotlin 代码反编译成 Java，再看，我却觉得有些不对劲。

为了让 Kotlin 反编译生成的代码与 Java 原生的调用方式尽量相同，反编译前，我给 instance 属性加了 @JvmField 注解。

companion object {@JvmFieldval instance = CommonSingletonHolder.holder
}

然后再反编译成 Java 代码，省去与分析无关的代码后：

public final class Common {@JvmField@NotNull// 单例public static final Common instance;private Common() {}// 单例的赋值static {instance = Common.CommonSingletonHolder.INSTANCE.getHolder();}// $FF: synthetic methodpublic Common(DefaultConstructorMarker $constructor_marker) {this();}private static final class CommonSingletonHolder {@NotNullprivate static final Common holder;@NotNullpublic static final Common.CommonSingletonHolder INSTANCE;@NotNullpublic final Common getHolder() {return holder;}static {Common.CommonSingletonHolder var0 = new Common.CommonSingletonHolder();INSTANCE = var0;holder = new Common((DefaultConstructorMarker)null);}}...
}

好像不太对喔！仔细看单例的赋值那一块代码，它是在 static 静态代码块里进行初始赋值的喔。

前文说了，静态内部类本质上也是一种懒汉单例模式，如果 instance 在静态代码块被初始化，那么 instance 就会在 Common 类加载的过程中就完成初始化，那本质上，它不就变成一种饿汉单例模式了吗？

写个 test case 验证一下 instance 是在什么时候初始化的：

class Common private constructor(){init {JLog.d("Common", "init Common.")}companion object {private var flag = false@JvmFieldval instance = CommonSingletonHolder.holderfun test() {JLog.d("Common", "Common test called.")}}/*** 静态内部类单例*/private object CommonSingletonHolder {val holder = Common()}}// 执行 test() 方法
Common.test()

调用 Common.test() 跑跑看，如果是懒汉模式，那么只要Common没有执行到 CommonSingletonHolder.holder 就不会触发 CommonSingletonHolder 类的加载，更不会走到 val holder = Common() 完成 instance 的初始化。

2022-01-14 14:29:11.330 3500-3500/com.jamgu.common D/Common: init Common.
2022-01-14 14:29:11.330 3500-3500/com.jamgu.common D/Common: Common test called.

Bingo！日志首先打印了 init Common. Instance 在 Common 类加载的时候就被初始化了！，我们实现的居然是一种静态内部类的饿汉模式。

啊这，饿汉模式和静态内部类模式都沾点的单例模式，应该叫什么模式？？饿静式？听着好像也还说得过去。。

哈哈，开个玩笑，言归正传回来，我们实现的代码既不是静态内部类模式，也不是饿汉模式，那应该怎么修改让它符合一个正宗的静态内部类模式呢？

Easy，类的静态属性和静态代码块，会在类加载的初始化阶段赋值和执行，但类的静态方法不会呀，把单例作为静态方法的返回值就可以完美地让单例懒加载了。

companion object {@JvmStatic// 修改此处fun getInstance() = CommonSingletonHolder.holderfun test() {JLog.d("Common", "Common test called.")}
}

再执行 Common.test()，看看结果：

2022-01-14 14:46:34.914 3862-3862/com.jamgu.common D/Common: Common test called.

没有执行单例的初始化，搞定~

Kotlin 静态内部类单例模式的正确实现方式

最后，一个用 Kotlin 实现的，安全的静态内部类单例模式就崭新出炉了。

class Common private constructor(){// 防止反射破坏单例init {if (!flag) {flag = true} else {throw Throwable("SingleTon is being attacked.")}}companion object {private var flag = false@JvmStaticfun getInstance() = CommonSingletonHolder.holder}/*** 静态内部类单例*/private object CommonSingletonHolder {val holder = Common()}}

现网上传的静态内部类版本不准确噢，仅需要做一些修改，就可以实现真正的静态内部类单例模式了~

@JvmField
val instance = CommonSingletonHolder.holder
// 改成 ----->>>>>
@JvmStatic
fun getInstance() = CommonSingletonHolder.holder

兄dei，如果觉得我写的还不错，麻烦帮个忙呗