简介：这是一份面向Android开发者的设计模式学习资料，以单例模式为专题展开实例详解。资源从单例模式的概念、定义与适用场景入手，重点剖析饿汉模式、懒汉模式、DCL双重检查锁定等常见实现方式，并结合Java内存模型说明线程安全、同步开销与DCL失效问题，同时补充静态内部类单例模式及Android源码、开源项目中的典型应用，适合初入设计模式或希望夯实基础的中级Android工程师查阅。压缩包内为1个PDF文档，整包大小仅96KB，方便快速下载与离线阅读。目前已有206人学习，内容结构紧凑、代码示例完整，读者可从中获得单例模式的多种写法对比、各方式的优缺点总结以及实际项目中的选型建议，是一份高性价比的轻量级参考笔记。
1. 单例模式实例详解：为什么它是初级工程师唯一会用的设计模式，却总在面试里翻车
在 Android 开发岗的面试里，单例模式几乎是必考题。问“手写一个单例”，十个候选人里八个能写出双检锁版本，但再追问一句“用反射能破掉你的单例吗”，场面就会安静下来。这份教程把单例模式的五种实现方式逐一拆开——从懒汉、饿汉到 DCL 双重检查锁定、静态内部类、枚举，每一版代码都配了优缺点分析和适用场景。它最适合两类人：一是刚接触设计模式、想搞懂“为什么 Android 系统服务都用单例”的初中级开发者；二是准备面试、想把单例相关的追问点一次备齐的求职者。这不是一篇泛泛讲概念的文档，读完之后你能在真实项目里立刻选型并写出经得起推敲的单例。
2. 单例模式的三要素与适用边界：先搞懂“该不该用”，再谈怎么写
2.1 定义拆解：一个类一个实例、自行实例化、全局提供
单例模式的定义是“确保某一个类只有一个实例，而且自行实例化并向整个系统提供这个实例”。听着简单，但拆开来看有三个约束：
- 只有一个实例：整个进程生命周期里，这个类只能被 new 一次。
- 自行实例化：外部不能直接 new——构造器必须私有化。
- 全局提供访问点：通过一个静态方法统一拿到这个实例。
在 Android 项目里，很多全局的“管理者”角色天然满足这三条。比如负责全局网络请求的 OkHttpClient，负责图片加载的 ImageLoader，负责音频焦点管理的 AudioManager。它们的特点是：被大量组件依赖，状态或资源需要被所有人共享，重复创建会白白消耗内存和 IO。
原教程里有个很形象的描述：创建一个对访问 IO 和数据库的对象消耗资源过多，单例能让这个对象只存在一份。所以判断一个类要不要写成单例，核心标准不是“这个工具类很常用”，而是“多份实例是否会造成资源浪费或状态错乱”。
2.2 使用场景清单：数据库、IO、系统服务与资源管理
具体到 Android 开发，我一般会按下面四类场景判断是否使用单例：
| 场景 | 典型对象 | 用单例的理由 |
|---|---|---|
| 数据库与文件 IO | SQLiteOpenHelper、数据库访问层（DAO） | 打开和关闭连接是重操作，多实例会让连接池失控 |
| 系统服务封装 | AudioManager、AccessibilityManager、InputMethodManager | 系统服务本身就是进程级的单例，封装类也应是单例 |
| 网络与缓存 | OkHttpClient、磁盘缓存管理器 | 线程池、连接池、缓存目录是全 App 共享的 |
| 配置与状态中心 | 用户登录态、主题管理器 | 所有页面必须读到同一份状态，出现第两份就会数据不一致 |
反过来，下面几种场景“看着像单例，其实不该用”：
- 纯静态工具类：比如字符串格式化工具，所有方法都是静态的，不需要持有任何状态，那直接写静态方法即可，没必要套单例。
- 小对象高频创建：比如列表 Item 的 ViewHolder，它生命周期短，创建成本低，单例反而会让对象常驻内存。
- 有明确生命周期依赖的对象：比如需要随页面销毁而释放的对象，硬做成单例会引发内存泄漏。
2.3 从“全局”到“唯一”：一个反直觉的判断标准
很多初级开发者会把“全局需要”和“必须唯一”混为一谈。我见过有人把 SharedPreferences 的封装类做成单例——这没问题，因为 SP 实例本来就应该是全局的。但也有人把手势识别器做成单例——这就翻车了，因为手势状态是要跟随页面变化的，单份实例会让页面 A 的滑动状态串到页面 B。
所以我在代码评审时通常会用一句很直接的话问：“这个类如果被创建两次，第二次会带来什么问题？”如果答案是“浪费一点内存但没别的”，那它不需要单例；如果答案是“会有两条数据库连接、两份缓存状态、两个全局配置”，那它该是单例。这个判断标准比背适用场景列表要可靠得多——它直接把你引到资源冲突的本质上去。
3. 五种实现方式的实测对比：从线程不安全到完美防反射
3.1 先纠正一份原型的命名：教程里的“饿汉”其实是懒汉
这份讲解在开头给了两段代码，第一段名字叫“饿汉模式”，但看代码逻辑：
public class Singleton { private static Singleton instance; private Singleton() { } public static Singleton getInstance() { if (instance == null) { instance = new Singleton(); } return instance; } }这段代码是“延迟加载”的，也就是用到才创建，但没有加任何线程同步。按主流设计模式教材的分类标准，这其实是“懒汉模式”的线程不安全版本。经典的“饿汉模式”是类加载时就立即初始化，像饥饿的人看到饭就扑上去。原教程在命名上把饿汉和懒汉颠倒了，这是很多人在读这份资料时最容易踩的坑，我在第 4 章会展开说。这里先保留原文档的结构，按它的章节顺序往下走。
3.2 线程不安全的“懒汉版”：延迟加载与多线程冲突
上面这段代码健壮的地方在于：instance 是静态的，构造器是私有的，外部无法直接 new。但问题也致命——if (instance == null)在并发环境下不具备原子性。假设线程 A 和线程 B 同时走到这个判断，A 看到 null 开始 new，B 同时看到 null 也开始 new，创建出来的就是两个对象。
这个 bug 在单线程场景或并发量极低的 App 启动阶段几乎不会暴露，但在 Runnable 和 Handler 满天飞的 Android 工程里，一旦出现，表现形式就是偶发的状态丢失、数据错乱，而且很难复现。修复方式很简单，加个同步即可。所以：
- 延迟加载：支持，挺灵活；
- 线程安全：不支持，不建议在真实项目直接用；
- 适合场景：单线程模型或者你确定并发不会触发，但我不建议赌。
3.3 线程安全的“方法同步版”：同步开销到底有多大
原教程第二段代码在 getInstance() 方法上加了synchronized关键字：
public class Singleton { private static Singleton instance; private Singleton() { } public static synchronized Singleton getInstance() { if (instance == null) { instance = new Singleton(); } return instance; } }synchronized加在静态方法上，锁住的是Singleton.class对象。这样一来，多个线程同时调 getInstance() 时只能排队进入，instance 只会被初始化一次。线程安全的问题算是解决了。
但代价也很明显：每次调用都要过一遍锁。即使 instance 已经被初始化，即使你只是想在某个界面拿一下单例对象，也要排队走一遍同步逻辑。在低并发场景下感觉不出来，但在主线程频繁调用的路径上，这种无谓的锁竞争会被工具检测成“锁竞争严重”。
原教程提了一个重要的补充信息：在 Android 源码中，InputMethodManager 和 AccessibilityManager 使用的正是这种同步方法的单例方式。如果你翻过 AOSP 源码会在 InputMethodManager.getInstance() 里看到一模一样的写法。这也说明一个问题：官方在某些低频系统服务上，宁可牺牲一点同步开销也要保证绝对安全。
3.4 DCL 双重检查锁定：指令重排坎与 volatile 补救
我最常写的版本是 DCL（Double Check Lock）。原教程里给了这段代码：
public class Singleton { private static volatile Singleton instance; private Singleton() { } public static Singleton getInstance() { if (instance == null) { synchronized (Singleton.class) { if (instance == null) { instance = new Singleton(); } } } return instance; } }重点看volatile这个关键字——教程里有一段非常重要的原理剖析：instance = new Singleton()这一行看起来是一句原子操作，实际编译成汇编后是三步：
- 给 Singleton 实例分配内存；
- 调用构造函数，初始化成员字段；
- 将 instance 引用指向这块内存。
在没有 volatile 的旧 JDK 下，处理器乱序执行时可能出现 1→3→2 的顺序。意思是第 3 步先把引用暴露出去，但对象还没初始化完成。此时如果线程 B 第一次判空，看到 instance 已经不是 null，直接把对象取走用，打开就是“半个对象”——字段是默认值，方法可能抛 NPE。
volatile 做了什么？它在 JDK 1.5 之后的 Java 内存模型里保证了：写操作在构造器初始化完成之前，不允许引用被发布出去。并且在多线程访问时，volatile 保证读操作拿到的是主内存里最新的值，而不是当前线程工作内存的旧缓存。
所以：
- 第一层判空：避免进入同步代码块，提高性能；
- 第二层判空：真正决定要不要 new 一次；
- volatile：禁止指令重排，让“半个对象”的场景彻底消失。
原教程还提到一个很久远的历史：在 JDK 1.5 之前 JMM 并没有完整支持 volatile 的语义，所以早期的 DCL 是失效的。《Java并发编程实践》这本书公开批评过 DCL，说这种“优化”并不优雅，不建议使用。但从工程角度讲，现在的 Android minSdk 普遍在 API 21 以上，对应 JDK 7 甚至 JDK 8，DCL + volatile 是完全合法的。很多第三方开源库内部也这么写，比如某个用得很广的 Android 图片加载框架，其核心配置类的单例就是 DCL。
3.5 静态内部类方案：靠类加载机制实现线程安全与延迟兼得
如果你不想深究 volatile 和指令重排，还有更优雅的写法——静态内部类。原教程对它评价很高，直接推荐：
public class Singleton { private Singleton() { } public static Singleton getInstance() { return SingletonHolder.instance; } /** * 静态内部类，由 JVM 类加载机制保证线程安全 */ private static class SingletonHolder { private static final Singleton instance = new Singleton(); } }原理是 JVM 的类加载机制：外部类 Singleton 被加载时，并不会主动加载 SingletonHolder。只有当 getInstance() 被第一次调用，代码真正引用到 SingletonHolder 时，JVM 才会把内部类加载并进行初始化。而类加载过程本身是有锁保护的，同一个类加载器下，一个类的<clinit>方法只会执行一次。换句话说，线程安全不是靠你写代码保证的，而是底层 JVM 在类加载时天然互斥。
对比 DCL：
| 维度 | DCL | 静态内部类 |
|---|---|---|
| 延迟加载 | 第一次 getInstance | 第一次 getInstance（内部类加载时） |
| 线程安全 | volatile + synchronized | JVM 类加载机制保证 |
| 代码复杂度 | 略高 | 极低，几乎不会写错 |
| 额外开销 | 有锁 + volatile 屏障 | 无 |
我在项目里的惯例是：新代码优先用静态内部类。理由很简单——它不会像 DCL 那样有 JDK 版本语义风险，也不会像方法同步版那样有锁开销，而且代码结构一眼就能看懂，团队里最年轻的同事也不会改错。
3.6 枚举单例：防反射、防序列化的最终防线
最后一种实现是官方推荐级别最高的：
public enum Singleton { instance; private String others; Singleton() { } public String getOthers() { return others; } public void setOthers(String others) { this.others = others; } }原教程说它是“绝对防止多次实例化”，这话在 Java 语义下是真的。原因有两层：
- 序列化：普通单例类实现 Serializable 后，反序列化时会通过反射新创建一个实例，绕过私有构造器。而枚举类型的序列化是 JVM 特殊处理的，反序列化不会新建实例，拿到的依然是那个唯一的枚举常量。
- 反射：通过
Constructor.newInstance()去调用私有构造器？Java 明确规定：不能用反射创建枚举实例，会直接抛 IllegalArgumentException。
所以枚举单例几乎是无懈可击的。它的缺点也不是技术上而是代码风格上的——很多 Android 工程规范里，枚举的引入会被人用 lint 规则拦下来，理由是“枚举生成的类文件更大、会更占用内存”。这个说法本身没毛病，但放在单例场景里，一个枚举类就一个常量，额外的内存开销非常有限。如果你的类需要序列化，或者你所在的项目安全要求高，枚举单例值得用。
五种写法选型对照表：
| 实现方式 | 延迟加载 | 线程安全 | 防反射 | 防序列化 | 性能表现 |
|---|---|---|---|---|---|
| 懒汉（方法同步） | 支持 | 支持 | 不支持 | 需额外处理 | 每次调用需同步，开销大 |
| DCL + volatile | 支持 | 支持 | 不支持 | 需额外处理 | 首次同步，后续无锁 |
| 静态内部类 | 支持 | 支持 | 不支持 | 需额外处理 | 无锁，推荐 |
| 枚举 | 支持 | 支持 | 天然防护 | 天然防护 | 最优 |
4. 单例模式避坑笔记：五个真实踩过的坑与背后的原因
4.1 坑一：教程里“饿汉”和“懒汉”的命名被写反了
现象：照着资料上的“饿汉模式”代码敲，发现它其实是判空后再 new 的延迟加载；另一个资料里写的饿汉模式又是类加载时直接初始化。两个资料对不上，看代码还都“能跑”。
原因：单例模式在中文社区流传时命名并不统一。部分作者把“先判空再创建”这段代码叫饿汉，把“直接初始化”的叫懒汉，和经典教材（如《设计模式：可复用面向对象软件的基础》的语境）刚好相反。原教程第一段代码明显是懒汉式未同步版却被标记为“饿汉”，是因为作者把“写代码的人很饥饿地急着创建”和“类加载时立刻创建”混在一起了。
解决：以后记住一个死标准——饿汉 = 类加载时立即 new，构造时机早；懒汉 = 第一次调用 getInstance 时才 new，构造时机晚。两者和“有没有 synchronized”无关，只与初始化时机有关。凡是private static Singleton instance = new Singleton()这种写法，都应该归类为饿汉模式，它天然线程安全，只是不支持延迟加载。
4.2 坑二：DCL 忘写 volatile，偶发且极难复现的诡异 NullPointerException
现象：DCL 写好了、测试也过了，但上线后线上统计里偶尔有几条NullPointerException，报错位置指向单例对象的成员变量访问。复现不了，日志量越大，越心慌。
原因：这就是经典的 DCL 失效。没有 volatile 时，Java 编译器与处理器允许指令乱序。创建对象的第二步（初始化字段）和第三步（引用赋值）被换序，线程 B 在线程 A 还没完成构造时就拿到了一个“非 null 但未初始化完毕”的 instance。
解决：private static volatile Singleton instance，加上 volatile 在 JDK 1.5+ 里面就是标准解法。从那以后我每次写带 DCL 的单例，一定会先检查 instance 有没有 volatile，没有就退回去改。另外多说一句：如果你发现团队里有同事在 Android 平台看到了 DCL 的 bug，先让他检查 JDK 版本，再检查是否用了静态内部类之外的多线程边界。
4.3 坑三：反射强行创建第二个实例，单例被“撕裂”
现象：一个单例类明明构造器是 private 的，但某个测试框架或开发工具通过反射调用构造器，还是成功创建了一个新实例。两个实例并存，全局状态变得不可预测。
原因：私有构造器只挡得住直接 new，挡不住反射。Constructor.setAccessible(true)之后，反射机制可以调用任意私有构造器创建新对象。普通类单例在这个攻击面下是裸奔的。
解决：在私有构造器里手动拦截：
public class Singleton { private static Singleton instance = new Singleton(); private Singleton() { if (instance != null) { throw new RuntimeException("单例构造器被禁止调用"); } } }原理是：第二次 new 时，instance 已经存在，进入构造器抛异常。这种方式简单直接，可以在一定程度上阻碍恶意反射调用，让单例在代码层不至于那么容易被破。但如果你把防反射当成强需求，直接用枚举单例，让 JVM 在框架层替你把这条路彻底堵死死。
4.4 坑四：序列化导致反序列化返回一个新对象
现象：单例对象被持久化到磁盘，App 重启后读回来，==比较发现不是同一个对象，全局变量的状态丢失，崩溃日志指向空指针。
原因：常规单例类如果实现了 Serializable，反序列化时会走 ObjectInputStream 的特殊路径，不经过构造器直接创建新对象。即使是私有构造器也拦不住。
解决：在类里加上 readResolve 钩子，并返回已有的单例实例：
private Object readResolve() throws ObjectStreamException { return instance; }这个方法会在反序列化之后被调用，返回值会替换掉反序列化创建的新对象。凡是写过单例且需要持久化的，我强烈建议把 readResolve 做成常规动作，别等到线上出了诡异问题再补。
4.5 坑五：单例持有 Activity 的 Context，页面无法回收
现象：LeakCanary 检测到 MainActivity 泄漏，分析堆栈发现引用链是“单例 → Context → Activity”。用户反复进出页面后 OOM。
原因：单例的生命周期和进程一样长。如果单例保存了 Activity 或 Service 等绑定上下文，就相当于用进程级的引用把一个只会短暂存在的页面给常驻住了。GC 永远不会回收一个被静态引用指向的对象。
解决：单例里保存的 Context 一律用 Application 级别的。具体做法是getApplicationContext()或者自定义 Application 里持有一个全局 context 再传给单例。写数据库封装、网络库封装、SharedPreferences 封装时，入口处接收的 context 参数必须强制转成 application context，否则后续维护的人很容易把 Activity 传进来。这个坑在 Android 的众多内存泄漏问题里能排进前三，每次代码评审我都要提醒一遍。
5. 单例选型与验证技巧：一页纸决定用哪种，三行代码测试有没有写破
很多人学完五种单例后反而不知道怎么选了，这里给一条实用的决策线：
- 项目里没有序列化需求、没有反射攻击顾虑、团队对 Java 并发不是很熟悉 →直接静态内部类，这是综合风险最小的写法；
- 类要参与序列化、或者需要过安全评测 →枚举单例，一句话的代价换来两道防护；
- 项目要求绝对延迟加载、单例创建前有大量静态配置需要提前完成 →饿汉模式；
- 在老旧代码里维护、或者多人协作且代码路径云里雾里 →DCL + volatile，兼容性和维护成本都能接受。
选完写法之后，你做一个小测试就能验证单例是否真的成立了。写一个五行的验证用例：
// 模拟高并发下获取单例 public class SingletonTest { public static void main(String[] args) throws Exception { final Set<Singleton> instanceSet = new ConcurrentHashMap<Singleton, Boolean>().newKeySet(); for (int i = 0; i < 1000; i++) { new Thread(new Runnable() { @Override public void run() { instanceSet.add(Singleton.getInstance()); } }).start(); } // 等所有线程跑完 Thread.sleep(2000); System.out.println("实例数量：" + instanceSet.size()); } }exampleSet.size()如果是 1，说明单例在 1000 个线程的竞争下仍然只有一个实例。如果是 2 或更多，说明同步逻辑失效了，请立刻复查 instance 前面有没有 volatile、有没有加 synchronized。
再补一个反射测试：
try { Constructor<Singleton> constructor = Singleton.class.getDeclaredConstructor(); constructor.setAccessible(true); Singleton second = constructor.newInstance(); System.out.println("反射创建成功：" + second); } catch (Exception e) { System.out.println("反射创建被拦截：" + e.getMessage()); }普通单例类若是没有在构造器里加判断，第二条会输出“反射创建成功”。看到这句话时你该意识到，你的单例在反射面前是纸糊的。至于枚举单例，上面的测试会直接抛 IllegalArgumentException，因为 JVM 不允许反射创建枚举实例。
教程的作用是帮你理解问题，五选一之后落到生产代码里才是真的攻坚。我从那次被线上 DCL 的 NPE 教育过之后，现在每写完一个 getInstance 都会强制走一遍三问：构造器是私有的吗？instance 是 volatile 的吗？Context 泄漏的问题排除了吗？建议你下次写单例前，把它们也过一遍。希望这份拆解和踩坑记录帮到你。
本文还有配套的精品资源，点击获取
