一、序
单例模式我相信大家应该不会陌生，随手抓一个程序员，让他说说最常用的 3 种设计模式，其中一定包含单例模式。
单例最重要的是，关注唯一性以及线程安全问题。而在 Java 中，单例存在多种实现范式，例如：饿汉式、懒汉式、静态内部类、双重检测等等，甚至还可以利用枚举的特性实现单例，可谓是把单例玩出了花样。
这其中，饿汉式单例实现代码是最简单的，关键代码只需一行 static final 申明对象即可，代码简单且满足需求。
但是饿汉式经常会被我们"嫌弃"，日常 Review Code 时，甚至看到饿汉式单例也会「友善的建议」对方使用双重检测。
饿汉式依赖 JVM 加载类的时机，来完成静态对象的初始化，这个过程本身就是线程安全的。而它最被人诟病的，其实是无法延迟加载，完全依赖 JVM 加载类的时机，这就导致单例类加载时机不可控。也就有可能，有些资源，业务还未使用，单例类就已经准备好了，导致过多的占用了系统资源。
我们再回过头来看看 Kotlin。在 Kotlin 中，实现单例非常简单，只需要将关键字 class 替换为 object 即可。
object SomeSingleton{ fun sayHi(){}}
但 Kotlin 的 object 其实就是饿汉式单例。它难道不怕存在资源占用的问题吗？
二、Kotliin 的 object
2.1 Kotlin 的 object 原理
在开始 Kotlin 的 object 选择饿汉式单例前，我们先来看看 Kotlin object 原理。
Kotlin 和 Java 可以互相调用，Kotlin 代码运行前也会被编译器编译成 Java 字节码。那我们就可以通过工具将其还原为 Java 代码进行分析。
这个转换工具， AS 原生支持。借助 AS 的 Tools → Kotlin → Show Kotlin Bytecode，就可以查看 Kotlin 编译后的 Java 字节码，再点击 Decompile 按钮，就可以将字节码转成 Java 代码。
image
可以看到，INSTANCE 使用 static final 声明，并且在 static 代码块内对其进行初始化，标准的饿汉式单例。
2.2 饿汉式如何保证唯一和线程安全？
前面提到，单例最重要的就是关注其唯一性和线程问题。
需要在任何情况下，都确保一个类只存在一个实例，不会因为多线程的访问，导致创建多个实例。同时也不会因为多线程而引入新的效率问题。
饿汉式单例的原理，其实是基于 JVM 的类加载机制来保证其符合单例的规范的。
简单来说，JVM 在加载类的时候，会经过初始化阶段（即 Class 被加载后，且被线程使用前）。在初始化期间，JVM 会获取一把锁，这个锁可以同步多个线程，对一个类的初始化，确保只有一个线程完成类的加载过程。这个步骤是线程安全的。
image
上图很清晰的描述了类的初始化锁工作流程，这里就不展开细说。
三、所谓的饿汉式问题
前文提到，饿汉式单例最被人诟病的问题，在于无法实现懒加载，完全依赖虚拟机加载类的策略加载。
3.1 懒加载
懒加载的目的，说白了就是为了避免，无必要的资源浪费，在不需要的时候不加载，等什么时候业务真的需要使用到它的时候，再加载资源。
虽然饿汉式依赖虚拟机加载类的策略，但虚拟机本身也会有优化项，那就是「按需加载」的策略。
虚拟机在运行程序时，并不时在启动时，就将所有的类都加载并初始化完成，而是采用「按需加载」的策略，在真正使用时，才会进行初始化。
例如 显式的 new Class()、调用类的静态方法、反射、Class.forName() 等，这些事件首次发生时，都会触发虚拟机加载类。
例如前文中，SomeSingleton 这个单例类，我们放到一个 App 中运行一下，App 先启动，点击按钮执行 SomeSingleton.sayHi() 方法。
15:39:34.539 I/cxmyDev: App running15:39:44.606 I/cxmyDev: SomeSingleton init15:39:44.606 I/cxmyDev: SomeSingleton sayHi
注意 Log 的时间，只有点击按钮执行 SomeSingleton.sayHi() 时，该单例类才被虚拟机加载。
也就是说，通常只有在你真实使用这个类时，它才会真的被虚拟机初始化，我们并不需要担心会被提前加载而导致资源浪费。
当然，不同虚拟机的实现方式不同，这并不是强制的，但是大多数为了性能都会准守此规则。
3.2 软件设计的角度
既然饿汉式的单例，也是在首次使用时初始化，这自然就是一种类懒加载的效果。
那我们再换个角度思考，如果饿汉式单例就是在程序启动时，就初始化好了，有问题吗？
在 Java 中，其实构造一个普通对象的成本很低。那为什么到了单例模式下，就觉得是个问题呢？
主要是单例的生命周期较长，承载了业务和状态，我们不提前构造无非是 2 个问题。
- 单例对象本身，初始化比较复杂或耗时，提前初始化会影响其他业务；
- 单例初始化后，持有的资源太多，导致内存资源的浪费；
问题一：初始化逻辑复杂
如果单例在初始化阶段，存在大量的逻辑，那么也不应该等到需要使用时才初始化它，否者必然会影响到接下来的业务性能。而是应该在此之前，系统较为空闲时初始化。
例如 Android 下就可以借助 IdleHandler 在空闲时提前做一些初始化工作。
问题二：持有资源太多
系统的各项资源，从来就没有够的时候。
任何时候缓存和性能都是要平衡的，单例作为一个生命周期较长的类，更不应该长时间持有大量的资源。否者就算加载时不报错，也必然会埋下 OOM 隐患，是之后内存优化时，重点关注的对象。
在编写代码时，就思考对内存资源的合理利用，而不是等到内存问题严重时，再集中进行内存优化。合理使用弱引用优化持有资源，也是一种不错的优化手段。
另外如果初始化时，就是必须会占用一些资源，那么基于 Fail-fast 原则，有问题也应该尽早的暴露出来。
毕竟 App 崩溃在开发手里，这叫问题，而崩溃在用户手里，这就叫事故。
四、小结时刻
今天我们聊了 Java 的单例，以及 Kotlin object 单例的实现原理，最后我们再小结一下。
- Kotlin object 使用「饿汉式」单例，依赖 JVM 的类加载机制确保唯一和线程安全；
- JVM 加载类采用「按需加载」策略，确保懒加载；
Kotlin 的 object 选择饿汉式单例，在性能和实现上都不存在问题，使用它无需顾虑。
听说给我点赞的人都升职加薪了~
网友评论