聊设计模式很多人第一反应就是策略、工厂这些带“套路感”的模式但在实际面试和编码里出场率最高的往往是看起来最简单的单例模式Singleton Pattern。它代码量极小任何一个初学者都能在五分钟内写出来可一旦往深处问就能问出线程安全、指令重排、序列化、反射攻击、类加载器隔离一长串问题。可以说单例模式是设计模式里“入门容易、精通难”的典型代表。这篇文章我想用从业者的视角把单例模式完整拆一遍从“它到底在解决什么问题”开始到 Java、C 里的各种实现方式与取舍再到框架源码和真实业务里它藏在哪里、怎么落地最后是一些我踩过的坑和多线程排查实录。无论你是正在准备设计模式考试的学生还是写业务代码时被全局状态坑过的开发这篇文章应该都能给你点不一样的收获。1. 单例模式的定义与它真正解决的问题1.1 单例模式的核心定义先给出一个准确的说法单例模式保证一个类在整个进程生命周期中只存在一个实例并提供一个全局访问点。这里有两个关键动作一个是控制实例数量一个是提供统一入口。两者缺一不可。很多新手容易把单例模式理解为“写一个静态变量存着就行”这是把结果当成了定义。真正的单例模式核心是拦截外部创建实例的路径。在 Java 里最直接的做法是把构造函数设为 private让外部无法 new在 C 里同样是私有化构造函数并删除拷贝构造和赋值操作从编译期就阻止复制单例对象。为什么需要这种限制因为有些对象在系统里天然就应该只有一份。比如线程池、数据库连接池、全局配置管理器、日志写入器如果每个模块都各自 new 一个自己的副本轻则浪费资源重则出现连接耗尽、配置不一致、日志错乱这些连锁问题。1.2 什么样的类适合做成单例判断一个类要不要用单例我总结了一个很朴素的“三问法”这个类是否需要维护一组跨模块共享的状态如果有多个实例是否会出现资源竞争或数据不一致这个类的实例是否会被频繁创建而创建成本很高如果三个问题的回答基本都是“是”那单例模式大概率是合适的。举例来说一个游戏引擎里管理音频播放的 AudioManager如果每个界面都创建一个新实例那么你切个场景可能就会听到两段 BGM 叠在一起。反过来如果一个类只承担纯函数式的计算工作没有内部状态那它完全可以通过静态方法实现不需要强行套单例。同时也要提醒单例并非万能药。它的最大副作用是引入全局状态而全局状态会让模块之间的隐式耦合加强也让单元测试变得麻烦。很多架构水平不错的团队会在设计规范里明确“单例仅用于基础设施类不用于业务类”这个度需要在实际项目里慢慢体会。2. Java 与 C 里最常用的几种实现单例模式的实现方式五花八门但核心差异集中在三个问题上何时创建实例、如何保证线程安全、如何防止外部破坏唯一性。下面以 Java 和 C 两条主线展开。2.1 Java 饿汉式简单但不要太自信饿汉式是所有方案里最容易理解的public class ConfigManager { private static final ConfigManager INSTANCE new ConfigManager(); private ConfigManager() { // 加载配置文件 } public static ConfigManager getInstance() { return INSTANCE; } }它的思路是类加载到 JVM 时静态字段的初始化阶段就完成实例创建。因为 JVM 的类加载过程有锁保护所以饿汉式的线程安全是天然的不需要额外写 synchronized。代码简单、性能最好getInstance() 里没有任何同步开销。但它有个很现实的问题容易造成启动变慢或资源浪费。如果一个单例类初始化时需要读取大文件、建立网络连接而应用启动后可能根本走不到使用它的逻辑这个实例就被白白创建了。我在之前一个项目里见过有人在启动阶段加载了十几个饿汉式单例每个都要创建数据库连接池结果应用启动时间肉眼可见地变慢。后来改成懒加载方案才解决。所以饿汉式的定位是实例创建成本低、初始化过程中不依赖其他配置项的类用它最省心。2.2 C 里的 Meyers Singleton在 C 里最被推荐的实现是 Scott Meyers 提出的静态局部变量方案class ConfigManager { public: static ConfigManager getInstance() { static ConfigManager instance; return instance; } ConfigManager(const ConfigManager) delete; ConfigManager operator(const ConfigManager) delete; private: ConfigManager() default; ~ConfigManager() default; };C11 标准之后函数内的静态局部变量初始化由编译器保证线程安全多个线程首次调用 getInstance() 时不会出现重复构造。这个方案没有显式加锁性能很好代码也极其简洁。但 C 版单例需要注意两点一是拷贝控制必须删除否则外部可以通过拷贝构造得到第二份对象二是析构顺序是反注册顺序可能引发崩溃。如果两个单例互相引用比如 A 的析构函数里调用了 B 的接口而 B 已经被析构程序会直接崩溃。C 里处理这种问题通常建议在析构函数里尽量少依赖其他单例或者引入引用计数的管理方式。2.3 懒汉式与同步方法的取舍懒汉式是“按需创建”的思路public class ConfigManager { private static ConfigManager instance; private ConfigManager() { } public static synchronized ConfigManager getInstance() { if (instance null) { instance new ConfigManager(); } return instance; } }给 getInstance() 加 synchronized 可以保证线程安全但问题在于一旦实例已经创建成功后续每次调用依然要进入同步方法这在高并发场景下会产生不必要的锁竞争。我见过有人用这种写法写日志管理类日志一多线程阻塞率肉眼可见地上升。因此同步方法只适合并发度极低的场景或者作为学习阶段的过渡方案。真要兼顾懒加载和性能还得看 DCL 或静态内部类。2.4 DCL 双重检查锁为什么必须配合 volatile双重检查锁Double-Checked Locking是懒汉式的进化版public class ConfigManager { private static volatile ConfigManager instance; private ConfigManager() { } public static ConfigManager getInstance() { if (instance null) { synchronized (ConfigManager.class) { if (instance null) { instance new ConfigManager(); } } } return instance; } }外层判断是为了避免无谓加锁内层判断是为了防止多个线程同时通过外层检查后重复创建。这里的 instance 字段必须加 volatile原因涉及JMM 的指令重排。new ConfigManager()这行代码在 JVM 视角其实分三步分配内存、调用构造器初始化字段、将引用指向内存。如果不禁止指令重排第二步和第三步可能被调换顺序也就是说线程 A 先让 instance 指向了一块尚未完成初始化的内存。此时线程 B 进来发现 instance 不为 null直接拿去使用就会读到一个半初始化的对象。volatile 在 JDK 5 之后提供了建立 happens-before 关系的语义能禁止这种重排保证安全发布。这个点几乎是 Java 面试必考务必理解到能复述的程度。C 里写 DCL 同样需要关注内存序问题但既然 C11 后已经有了更干净的静态局部变量方案我还是建议 C 开发者优先用 Meyers Singleton而不是手写 DCL 去跟编译器较劲。3. 实现细节对比官方推荐与常见误区3.1 Java 静态内部类的巧妙之处在 Java 世界里我平时最常用的其实是静态内部类实现public class ConfigManager { private ConfigManager() { } private static class Holder { private static final ConfigManager INSTANCE new ConfigManager(); } public static ConfigManager getInstance() { return Holder.INSTANCE; } }它的原理是静态内部类 Holder 只有在 getInstance() 第一次被调用时才会被 JVM 加载而类加载的时机天然是线程安全的所以这里既实现了懒加载又避免了 synchronized 同步开销。这算是兼顾了饿汉式的简洁与懒汉式的按需加载代码可读性也很好。对比饿汉式静态内部类的优势是加载时机可控对比懒汉式它没有锁竞争。缺点也很小第一次调用 getInstance() 时会触发类加载略有延迟这在实际应用中几乎感受不到。3.2 Java 枚举单例最干净但容易被忽略Joshua Bloch 在《Effective Java》里明确提出过枚举是实现单例模式的最佳方式public enum ConfigManager { INSTANCE; private String configValue; public void load() { // 加载逻辑 } public String getConfigValue() { return configValue; } }枚举单例的好处是从 JVM 层面保证了实例唯一性天然抵御反射和序列化破坏。写起来极短也不需要关心 volatile、synchronized 这些细节。但它有一个项目中的现实障碍很多团队不习惯把单例写成枚举尤其是需要继承某个基类或复杂初始化逻辑时枚举的灵活性会受限。我的看法是如果团队没有历史包袱新项目里优先用枚举如果老代码里全是传统写法也不必为了统一而全量重写保持风格一致更重要。3.3 各实现方案对比速查表实现方式懒加载线程安全代码复杂度防御反射/序列化适用场景饿汉式否是低一般初始化成本低启动时可加载懒汉式同步方法是是低一般低并发、教学演示DCL 双重检查锁是是中一般高并发 Java 项目静态内部类是是低一般Java 常规推荐枚举否是极低强Java 最佳实践C 静态局部变量是是低不涉及反射C 常规推荐这张表可以帮你快速做取舍。但在真实项目里代码简洁和线程安全往往比“懒加载”这个点更重要。一个类的实例创建即使有点耗时通常也就是毫秒级别为了省这一点点启动时间引入复杂的并发控制性价比并不高。3.4 线程安全不是评价单例的唯一标准很多文章会把线程安全当作单例实现好坏的核心指标但实际上“唯一性”和“可见性”才是更值得关注的点。唯一性指任何时刻进程里确实只有一个实例。这在 Java 里可以靠枚举或静态字段保证但在分布式环境下进程与进程之间天生就是多个实例并存单例模式管不了跨进程的问题这是设计边界。可见性指一个线程对实例内部字段的修改能否被其他线程及时看到。如果单例内部维护了可变状态比如缓存的 Map、计数器等仍然需要额外用锁或者 volatile 来保证可见性而不是说“因为是单例就天然线程安全了”。我在排查线上问题时不止一次见到这种误解有人把共享数据放在单例里却没有做并发控制最后数据错乱得一塌糊涂。4. 实战落地从需求判断到代码重构4.1 一个普通类变成单例的判断路径日常开发中我经常看到有人为了用单例而用单例把一个承载业务计算的无状态 Service 类也做成单例。这本身问题不大但长远看不一定是好设计。我判断是否重构为单例时有个习惯先观察这个类被 new 了多少次以及这些实例之间是否共享状态。如果每个调用方 new 出来都是同一个内部数据源且它们之间会产生数据重叠那么这些实例本质上就是“假单例”——它们虽然是多个对象但指向同一个底层资源这种场景反而容易让代码困惑。真正应该做的是明确到底谁拥有那个资源而不是让每个人都拿到一份指向资源的对象。反过来如果这个类包含大量状态且状态之间需要保持全局一致比如一个全局缓存管理器那就很适合单例。核心标准一句话实例唯一性是否直接决定了数据正确性和资源效率。4.2 重构步骤把普通类改成标准单例以 Java 为例从普通类到标准单例我一般分四步走私有化构造函数把所有 public 构造函数修改为 private并确认所有调用方不再直接 new。如果外部代码很多可以先保留一个包内可见的构造器用于兼容测试。添加静态字段与静态方法定义一个 private static volatile 字段并提供 public static 的 getInstance() 方法。序列化防御如果类实现了 Serializable 接口需要添加 readResolve() 方法防止反序列化时生成新实例。检查反射场景在构造函数里加保护逻辑如果 instance 不为 null 则抛出异常或者直接改用枚举方案。这四步做完一个普通类就完成了单例化。过程中最容易被遗漏的是第三步和第四步因为平时序列化和反射在业务代码里用得不多但在框架容器环境下这两个都是真实的破坏通道。4.3 关于类加载器、反射与序列化的边界问题Java 里类加载器是一个容易踩坑的点。同一个类如果被两个不同的类加载器加载它们在 JVM 里就被视为两个不同的类型各自的静态字段互相独立于是单例就会变成多例。典型场景是 Web 容器里多个应用共享同一个类库或者使用了自定义类加载器实现热部署。解决方案是让单例类的加载器相对固定或者在全局注册表中以类加载器作为 key 做一次映射。但说实话大多数单体应用不需要考虑这个复杂度了解即可。反射破坏的防线则更近一些。即使构造函数是 private通过setAccessible(true)依然可以绕过访问控制调用它。要防御这一点最彻底的是使用枚举单例因为 JVM 禁止反射创建枚举实例。其次是构造函数里加判断private ConfigManager() { if (instance ! null) { throw new IllegalStateException(Already initialized); } }但注意这种检查在 DCL 写法中需要配合内存可见性处理否则可能出现判断失效。如果不想纠结推荐直接枚举。5. 框架与项目中常见的单例场景5.1 Spring 容器里的单例与“按名获取”Java 开发者几乎每天都在用单例只不过很多时候不自知。Spring 默认的 Bean 作用域就是 singletonSpring 容器会为每个 Bean 定义维护唯一实例并通过依赖注入或getBean()按名称获取。但这里有个细节Spring 的单例是容器级单例而不是 JVM 级单例。如果你同时启动了多个 Spring 容器每个容器里的同一 Bean 是不同实例。这一点在微服务架构里的理解尤其重要。服务进程与进程之间天然隔离你不可能期待一个 JVM 里的单例去“同步”另一个 JVM 的状态。所以做分布式缓存、分布式锁时单例模式解决不了跨进程一致性问题需要引入 Redis、ZooKeeper 等外部存储。这也是很多新人对单例产生误解的根源把单例模式和“全局唯一”画了等号却忘了它作用的边界只在当前类加载器可见范围内。5.2 Android 场景Application、Fragment 与 ViewBindingAndroid 开发里有一个经常被拿来讨论的误用场景把 Fragment 设计成单例。曾有人为了复用 Fragment 实例在 Fragment 里写静态 INSTANCE 获取方法顺便在 onCreateView 里做 ViewBinding 的缓存。表面看似乎能省去重复创建布局的开销但隐患非常明显。Fragment 的生命周期由 FragmentManager 管理系统在配置变更、进程重建后会通过反射重新创建 Fragment 实例如果你的单例缓存了旧的 View就会出现View 已被 detach 却仍被持有的崩溃。而且单例 Fragment 难以携带不同的参数一旦同一个 Fragment 需要在不同界面展示不同数据就不得不暴露静态 setter反而让代码更难维护。Google 官方的建议是通过静态工厂方法newInstance(args)创建 Fragment 实例把参数塞进 Bundle而不是在 Fragment 里实现单例。至于 ViewBinding也强烈建议在onCreateView里绑定、onDestroyView里置空避免内存泄漏。我自己刚接触 Android 时也犯过缓存 ViewBinding 的错误后来连续遇到几个IllegalStateException: binding is null才彻底改掉这个习惯。5.3 游戏开发中常见的单例封装C 写游戏引擎时单例的出场率极高。音频系统、输入系统、资源管理器、UI 管理器几乎都是单例。原因很简单游戏运行时对全局状态的一致性要求极高比如玩家血量这种数据不可能让多个模块各持一份。但游戏引擎里的单例一般不会用裸的 Meyers Singleton 直接扔给全项目用而是会套一层模板封装同时处理创建顺序和销毁顺序templatetypename T class Singleton { public: static T getInstance() { static T instance; return instance; } Singleton(const Singleton) delete; Singleton operator(const Singleton) delete; protected: Singleton() default; virtual ~Singleton() default; };资源管理型单例一般还需要提供init()和shutdown()两个方法让引擎在固定时机进行初始化和资源释放。直接依赖构造和析构的时机很容易在退出时遇到 A 已经销毁但 B 还在调 A 接口的崩溃。别问我为什么知道我在一个联机游戏项目里排查过整整一个下午的静态析构崩溃最后定位到就是一个单例在析构函数里直接调用了另一个单例的方法。6. 常见问题与排查技巧实录6.1 序列化把单例“裂开”了这是我最常遇到的“单例被破坏”案例。如果一个单例类实现了 Serializable 接口那么在反序列化时JVM 会根据序列化数据重新创建一个对象完全不经过构造函数也不管你的静态字段里有没有现成实例。操作结果就是getInstance() 和反序列化得到的对象不是同一个。解决办法是为单例类添加一个readResolve()方法protected Object readResolve() { return INSTANCE; }这样反序列化时并不会真的创建新对象而是直接返回现有的单例实例。如果你用的是枚举单例这一步都省了JVM 对枚举的序列化做了特殊处理反序列化得到的永远是同一个枚举常量。6.2 反射代码不小心“new”出了一个新单例很多单元测试框架会利用反射创建对象一旦被测类是个单例测试可能意外创建出第二份实例。比如使用 Mockito 时对单例类做 mock如果框架通过反射绕过了私有构造函数就可能得到两个实例。如果你是写工具库给别人用建议直接在构造函数里加防护private ConfigManager() { throw new IllegalStateException(Utility class); }这里要区分两种情况一是真正的单例类二是只含静态方法的工具类。如果是工具类把构造函数直接抛异常是标准做法如果是真正的单例类抛异常会导致反射创建也失败但反射攻击者可以通过 Unsafe 等底层手段继续绕过所以最省心的还是枚举。6.3 “为什么我 getInstance 拿到的两个实例不是同一个”这种问题通常和类加载器有关特别是在热部署、插件化、OSGi 环境中。表现是同一个类的全限定名相同但instanceof判断却是 falsegetInstance() 返回的对象身份也不一致。排查方法很简单在代码里打印类的加载器System.out.println(ConfigManager.class.getClassLoader()); System.out.println(instance.getClass().getClassLoader());如果两个输出不一致就说明类被不同加载器分别加载单例自然被“拆分”。对于 Web 应用的常见解决办法是把公共单例类放到容器级别的共享类库中或者使用Class.forName时指定统一的加载器。这个话题比较大不展开但知道现象和排查方向就够了。6.4 单例持有 View 导致的内存泄漏现场Android 里最常见的低水平错误之一就是在单例中持有 Activity 或 View 的引用。比如为了异步回调方便把一个 Activity 存在单例的字段里。Activity 销毁后单例里还留着它的强引用垃圾回收器无法回收就产生了内存泄漏。我在实际项目里看到的泄漏链通常是单例对象 - 接口回调 - Activity。比如静态单例的图片加载器持有一个 ImageListener而 ImageListener 是 Activity 的匿名内部类于是整个 Activity 都被单例拽着不放手。解决办法分为几个层次能用 Application Context 的地方优先用 Application Context用弱引用存储 Activity 或 View在 onDestroy 里主动解除回调引用。排查内存泄漏最常见的手段是用 Android Studio 的 Memory Profiler 抓取 heap dump搜索泄漏的类名查看引用链。这个工具能直接看到谁持有了 Activity效率很高。6.5 面试高频问题速查表问题建议回答思路单例模式的线程安全问题如何解决分实现方式说明饿汉天然安全、DCL 需要 volatile、静态内部类依赖类加载机制、枚举天然安全DCL 为什么两次判断外层判断有什么用外层判断避免每个线程都进同步块提升性能内层判断防止多个线程同时创建为什么 instance 必须加 volatile防止指令重排导致线程拿到未初始化完成的实例单例模式有什么缺点全局状态增加耦合、难以测试、序列化/反射可能破坏唯一性、跨进程不生效有没有不使用单例模式却达到类似效果的方案依赖注入Spring 单例 Bean、静态工具类、ThreadLocal 隔离实例等7. 我的一些实操体会聊了这么多最后分享一点我在真实项目里的体会。设计模式的魅力不在于“模式本身多精巧”而在于它是否真的解决了你的问题。单例模式最理想的使用方式是隐式的框架帮你管理生命周期开发者只需要通过注入或获取接口拿到对象而不需要关心它是不是单例。Spring 里默认的单例 Bean 就是这么用的。如果要在新项目里手写单例我倾向于这么选Java 优先用枚举或者静态内部类C 优先用 Meyers Singleton。这几种写法代码量最小线程安全也有保障不容易自己给自己埋坑。还有一个很实用的建议设计模式大作业如果选单例主题不要只写四种实现。要写清“为什么饿汉式不饿”“DCL 为什么需要 volatile”“枚举为什么能防反射”这三个问题再配一个真实场景的重构前后对比比其他同学高一截。另外如果你是去面试千万别把“单例模式”回答成背定义。面试官想听的不是你能说出几种写法而是你能不能在五分钟内讲清楚“进程里只有一个对象”这句话背后的内存语义、并发语义和架构边界。这就是我在单例模式这个“小”模式里看到的大世界。希望这些内容对你有用。 
长河君 · 2026/10/10 14:52:02 · 阅读 1.2k 单例模式深度解析：从基础实现到线程安全与实战应用
聊设计模式很多人第一反应就是策略、工厂这些带“套路感”的模式但在实际面试和编码里出场率最高的往往是看起来最简单的单例模式Singleton Pattern。它代码量极小任何一个初学者都能在五分钟内写出来可一旦往深处问就能问出线程安全、指令重排、序列化、反射攻击、类加载器隔离一长串问题。可以说单例模式是设计模式里“入门容易、精通难”的典型代表。这篇文章我想用从业者的视角把单例模式完整拆一遍从“它到底在解决什么问题”开始到 Java、C 里的各种实现方式与取舍再到框架源码和真实业务里它藏在哪里、怎么落地最后是一些我踩过的坑和多线程排查实录。无论你是正在准备设计模式考试的学生还是写业务代码时被全局状态坑过的开发这篇文章应该都能给你点不一样的收获。1. 单例模式的定义与它真正解决的问题1.1 单例模式的核心定义先给出一个准确的说法单例模式保证一个类在整个进程生命周期中只存在一个实例并提供一个全局访问点。这里有两个关键动作一个是控制实例数量一个是提供统一入口。两者缺一不可。很多新手容易把单例模式理解为“写一个静态变量存着就行”这是把结果当成了定义。真正的单例模式核心是拦截外部创建实例的路径。在 Java 里最直接的做法是把构造函数设为 private让外部无法 new在 C 里同样是私有化构造函数并删除拷贝构造和赋值操作从编译期就阻止复制单例对象。为什么需要这种限制因为有些对象在系统里天然就应该只有一份。比如线程池、数据库连接池、全局配置管理器、日志写入器如果每个模块都各自 new 一个自己的副本轻则浪费资源重则出现连接耗尽、配置不一致、日志错乱这些连锁问题。1.2 什么样的类适合做成单例判断一个类要不要用单例我总结了一个很朴素的“三问法”这个类是否需要维护一组跨模块共享的状态如果有多个实例是否会出现资源竞争或数据不一致这个类的实例是否会被频繁创建而创建成本很高如果三个问题的回答基本都是“是”那单例模式大概率是合适的。举例来说一个游戏引擎里管理音频播放的 AudioManager如果每个界面都创建一个新实例那么你切个场景可能就会听到两段 BGM 叠在一起。反过来如果一个类只承担纯函数式的计算工作没有内部状态那它完全可以通过静态方法实现不需要强行套单例。同时也要提醒单例并非万能药。它的最大副作用是引入全局状态而全局状态会让模块之间的隐式耦合加强也让单元测试变得麻烦。很多架构水平不错的团队会在设计规范里明确“单例仅用于基础设施类不用于业务类”这个度需要在实际项目里慢慢体会。2. Java 与 C 里最常用的几种实现单例模式的实现方式五花八门但核心差异集中在三个问题上何时创建实例、如何保证线程安全、如何防止外部破坏唯一性。下面以 Java 和 C 两条主线展开。2.1 Java 饿汉式简单但不要太自信饿汉式是所有方案里最容易理解的public class ConfigManager { private static final ConfigManager INSTANCE new ConfigManager(); private ConfigManager() { // 加载配置文件 } public static ConfigManager getInstance() { return INSTANCE; } }它的思路是类加载到 JVM 时静态字段的初始化阶段就完成实例创建。因为 JVM 的类加载过程有锁保护所以饿汉式的线程安全是天然的不需要额外写 synchronized。代码简单、性能最好getInstance() 里没有任何同步开销。但它有个很现实的问题容易造成启动变慢或资源浪费。如果一个单例类初始化时需要读取大文件、建立网络连接而应用启动后可能根本走不到使用它的逻辑这个实例就被白白创建了。我在之前一个项目里见过有人在启动阶段加载了十几个饿汉式单例每个都要创建数据库连接池结果应用启动时间肉眼可见地变慢。后来改成懒加载方案才解决。所以饿汉式的定位是实例创建成本低、初始化过程中不依赖其他配置项的类用它最省心。2.2 C 里的 Meyers Singleton在 C 里最被推荐的实现是 Scott Meyers 提出的静态局部变量方案class ConfigManager { public: static ConfigManager getInstance() { static ConfigManager instance; return instance; } ConfigManager(const ConfigManager) delete; ConfigManager operator(const ConfigManager) delete; private: ConfigManager() default; ~ConfigManager() default; };C11 标准之后函数内的静态局部变量初始化由编译器保证线程安全多个线程首次调用 getInstance() 时不会出现重复构造。这个方案没有显式加锁性能很好代码也极其简洁。但 C 版单例需要注意两点一是拷贝控制必须删除否则外部可以通过拷贝构造得到第二份对象二是析构顺序是反注册顺序可能引发崩溃。如果两个单例互相引用比如 A 的析构函数里调用了 B 的接口而 B 已经被析构程序会直接崩溃。C 里处理这种问题通常建议在析构函数里尽量少依赖其他单例或者引入引用计数的管理方式。2.3 懒汉式与同步方法的取舍懒汉式是“按需创建”的思路public class ConfigManager { private static ConfigManager instance; private ConfigManager() { } public static synchronized ConfigManager getInstance() { if (instance null) { instance new ConfigManager(); } return instance; } }给 getInstance() 加 synchronized 可以保证线程安全但问题在于一旦实例已经创建成功后续每次调用依然要进入同步方法这在高并发场景下会产生不必要的锁竞争。我见过有人用这种写法写日志管理类日志一多线程阻塞率肉眼可见地上升。因此同步方法只适合并发度极低的场景或者作为学习阶段的过渡方案。真要兼顾懒加载和性能还得看 DCL 或静态内部类。2.4 DCL 双重检查锁为什么必须配合 volatile双重检查锁Double-Checked Locking是懒汉式的进化版public class ConfigManager { private static volatile ConfigManager instance; private ConfigManager() { } public static ConfigManager getInstance() { if (instance null) { synchronized (ConfigManager.class) { if (instance null) { instance new ConfigManager(); } } } return instance; } }外层判断是为了避免无谓加锁内层判断是为了防止多个线程同时通过外层检查后重复创建。这里的 instance 字段必须加 volatile原因涉及JMM 的指令重排。new ConfigManager()这行代码在 JVM 视角其实分三步分配内存、调用构造器初始化字段、将引用指向内存。如果不禁止指令重排第二步和第三步可能被调换顺序也就是说线程 A 先让 instance 指向了一块尚未完成初始化的内存。此时线程 B 进来发现 instance 不为 null直接拿去使用就会读到一个半初始化的对象。volatile 在 JDK 5 之后提供了建立 happens-before 关系的语义能禁止这种重排保证安全发布。这个点几乎是 Java 面试必考务必理解到能复述的程度。C 里写 DCL 同样需要关注内存序问题但既然 C11 后已经有了更干净的静态局部变量方案我还是建议 C 开发者优先用 Meyers Singleton而不是手写 DCL 去跟编译器较劲。3. 实现细节对比官方推荐与常见误区3.1 Java 静态内部类的巧妙之处在 Java 世界里我平时最常用的其实是静态内部类实现public class ConfigManager { private ConfigManager() { } private static class Holder { private static final ConfigManager INSTANCE new ConfigManager(); } public static ConfigManager getInstance() { return Holder.INSTANCE; } }它的原理是静态内部类 Holder 只有在 getInstance() 第一次被调用时才会被 JVM 加载而类加载的时机天然是线程安全的所以这里既实现了懒加载又避免了 synchronized 同步开销。这算是兼顾了饿汉式的简洁与懒汉式的按需加载代码可读性也很好。对比饿汉式静态内部类的优势是加载时机可控对比懒汉式它没有锁竞争。缺点也很小第一次调用 getInstance() 时会触发类加载略有延迟这在实际应用中几乎感受不到。3.2 Java 枚举单例最干净但容易被忽略Joshua Bloch 在《Effective Java》里明确提出过枚举是实现单例模式的最佳方式public enum ConfigManager { INSTANCE; private String configValue; public void load() { // 加载逻辑 } public String getConfigValue() { return configValue; } }枚举单例的好处是从 JVM 层面保证了实例唯一性天然抵御反射和序列化破坏。写起来极短也不需要关心 volatile、synchronized 这些细节。但它有一个项目中的现实障碍很多团队不习惯把单例写成枚举尤其是需要继承某个基类或复杂初始化逻辑时枚举的灵活性会受限。我的看法是如果团队没有历史包袱新项目里优先用枚举如果老代码里全是传统写法也不必为了统一而全量重写保持风格一致更重要。3.3 各实现方案对比速查表实现方式懒加载线程安全代码复杂度防御反射/序列化适用场景饿汉式否是低一般初始化成本低启动时可加载懒汉式同步方法是是低一般低并发、教学演示DCL 双重检查锁是是中一般高并发 Java 项目静态内部类是是低一般Java 常规推荐枚举否是极低强Java 最佳实践C 静态局部变量是是低不涉及反射C 常规推荐这张表可以帮你快速做取舍。但在真实项目里代码简洁和线程安全往往比“懒加载”这个点更重要。一个类的实例创建即使有点耗时通常也就是毫秒级别为了省这一点点启动时间引入复杂的并发控制性价比并不高。3.4 线程安全不是评价单例的唯一标准很多文章会把线程安全当作单例实现好坏的核心指标但实际上“唯一性”和“可见性”才是更值得关注的点。唯一性指任何时刻进程里确实只有一个实例。这在 Java 里可以靠枚举或静态字段保证但在分布式环境下进程与进程之间天生就是多个实例并存单例模式管不了跨进程的问题这是设计边界。可见性指一个线程对实例内部字段的修改能否被其他线程及时看到。如果单例内部维护了可变状态比如缓存的 Map、计数器等仍然需要额外用锁或者 volatile 来保证可见性而不是说“因为是单例就天然线程安全了”。我在排查线上问题时不止一次见到这种误解有人把共享数据放在单例里却没有做并发控制最后数据错乱得一塌糊涂。4. 实战落地从需求判断到代码重构4.1 一个普通类变成单例的判断路径日常开发中我经常看到有人为了用单例而用单例把一个承载业务计算的无状态 Service 类也做成单例。这本身问题不大但长远看不一定是好设计。我判断是否重构为单例时有个习惯先观察这个类被 new 了多少次以及这些实例之间是否共享状态。如果每个调用方 new 出来都是同一个内部数据源且它们之间会产生数据重叠那么这些实例本质上就是“假单例”——它们虽然是多个对象但指向同一个底层资源这种场景反而容易让代码困惑。真正应该做的是明确到底谁拥有那个资源而不是让每个人都拿到一份指向资源的对象。反过来如果这个类包含大量状态且状态之间需要保持全局一致比如一个全局缓存管理器那就很适合单例。核心标准一句话实例唯一性是否直接决定了数据正确性和资源效率。4.2 重构步骤把普通类改成标准单例以 Java 为例从普通类到标准单例我一般分四步走私有化构造函数把所有 public 构造函数修改为 private并确认所有调用方不再直接 new。如果外部代码很多可以先保留一个包内可见的构造器用于兼容测试。添加静态字段与静态方法定义一个 private static volatile 字段并提供 public static 的 getInstance() 方法。序列化防御如果类实现了 Serializable 接口需要添加 readResolve() 方法防止反序列化时生成新实例。检查反射场景在构造函数里加保护逻辑如果 instance 不为 null 则抛出异常或者直接改用枚举方案。这四步做完一个普通类就完成了单例化。过程中最容易被遗漏的是第三步和第四步因为平时序列化和反射在业务代码里用得不多但在框架容器环境下这两个都是真实的破坏通道。4.3 关于类加载器、反射与序列化的边界问题Java 里类加载器是一个容易踩坑的点。同一个类如果被两个不同的类加载器加载它们在 JVM 里就被视为两个不同的类型各自的静态字段互相独立于是单例就会变成多例。典型场景是 Web 容器里多个应用共享同一个类库或者使用了自定义类加载器实现热部署。解决方案是让单例类的加载器相对固定或者在全局注册表中以类加载器作为 key 做一次映射。但说实话大多数单体应用不需要考虑这个复杂度了解即可。反射破坏的防线则更近一些。即使构造函数是 private通过setAccessible(true)依然可以绕过访问控制调用它。要防御这一点最彻底的是使用枚举单例因为 JVM 禁止反射创建枚举实例。其次是构造函数里加判断private ConfigManager() { if (instance ! null) { throw new IllegalStateException(Already initialized); } }但注意这种检查在 DCL 写法中需要配合内存可见性处理否则可能出现判断失效。如果不想纠结推荐直接枚举。5. 框架与项目中常见的单例场景5.1 Spring 容器里的单例与“按名获取”Java 开发者几乎每天都在用单例只不过很多时候不自知。Spring 默认的 Bean 作用域就是 singletonSpring 容器会为每个 Bean 定义维护唯一实例并通过依赖注入或getBean()按名称获取。但这里有个细节Spring 的单例是容器级单例而不是 JVM 级单例。如果你同时启动了多个 Spring 容器每个容器里的同一 Bean 是不同实例。这一点在微服务架构里的理解尤其重要。服务进程与进程之间天然隔离你不可能期待一个 JVM 里的单例去“同步”另一个 JVM 的状态。所以做分布式缓存、分布式锁时单例模式解决不了跨进程一致性问题需要引入 Redis、ZooKeeper 等外部存储。这也是很多新人对单例产生误解的根源把单例模式和“全局唯一”画了等号却忘了它作用的边界只在当前类加载器可见范围内。5.2 Android 场景Application、Fragment 与 ViewBindingAndroid 开发里有一个经常被拿来讨论的误用场景把 Fragment 设计成单例。曾有人为了复用 Fragment 实例在 Fragment 里写静态 INSTANCE 获取方法顺便在 onCreateView 里做 ViewBinding 的缓存。表面看似乎能省去重复创建布局的开销但隐患非常明显。Fragment 的生命周期由 FragmentManager 管理系统在配置变更、进程重建后会通过反射重新创建 Fragment 实例如果你的单例缓存了旧的 View就会出现View 已被 detach 却仍被持有的崩溃。而且单例 Fragment 难以携带不同的参数一旦同一个 Fragment 需要在不同界面展示不同数据就不得不暴露静态 setter反而让代码更难维护。Google 官方的建议是通过静态工厂方法newInstance(args)创建 Fragment 实例把参数塞进 Bundle而不是在 Fragment 里实现单例。至于 ViewBinding也强烈建议在onCreateView里绑定、onDestroyView里置空避免内存泄漏。我自己刚接触 Android 时也犯过缓存 ViewBinding 的错误后来连续遇到几个IllegalStateException: binding is null才彻底改掉这个习惯。5.3 游戏开发中常见的单例封装C 写游戏引擎时单例的出场率极高。音频系统、输入系统、资源管理器、UI 管理器几乎都是单例。原因很简单游戏运行时对全局状态的一致性要求极高比如玩家血量这种数据不可能让多个模块各持一份。但游戏引擎里的单例一般不会用裸的 Meyers Singleton 直接扔给全项目用而是会套一层模板封装同时处理创建顺序和销毁顺序templatetypename T class Singleton { public: static T getInstance() { static T instance; return instance; } Singleton(const Singleton) delete; Singleton operator(const Singleton) delete; protected: Singleton() default; virtual ~Singleton() default; };资源管理型单例一般还需要提供init()和shutdown()两个方法让引擎在固定时机进行初始化和资源释放。直接依赖构造和析构的时机很容易在退出时遇到 A 已经销毁但 B 还在调 A 接口的崩溃。别问我为什么知道我在一个联机游戏项目里排查过整整一个下午的静态析构崩溃最后定位到就是一个单例在析构函数里直接调用了另一个单例的方法。6. 常见问题与排查技巧实录6.1 序列化把单例“裂开”了这是我最常遇到的“单例被破坏”案例。如果一个单例类实现了 Serializable 接口那么在反序列化时JVM 会根据序列化数据重新创建一个对象完全不经过构造函数也不管你的静态字段里有没有现成实例。操作结果就是getInstance() 和反序列化得到的对象不是同一个。解决办法是为单例类添加一个readResolve()方法protected Object readResolve() { return INSTANCE; }这样反序列化时并不会真的创建新对象而是直接返回现有的单例实例。如果你用的是枚举单例这一步都省了JVM 对枚举的序列化做了特殊处理反序列化得到的永远是同一个枚举常量。6.2 反射代码不小心“new”出了一个新单例很多单元测试框架会利用反射创建对象一旦被测类是个单例测试可能意外创建出第二份实例。比如使用 Mockito 时对单例类做 mock如果框架通过反射绕过了私有构造函数就可能得到两个实例。如果你是写工具库给别人用建议直接在构造函数里加防护private ConfigManager() { throw new IllegalStateException(Utility class); }这里要区分两种情况一是真正的单例类二是只含静态方法的工具类。如果是工具类把构造函数直接抛异常是标准做法如果是真正的单例类抛异常会导致反射创建也失败但反射攻击者可以通过 Unsafe 等底层手段继续绕过所以最省心的还是枚举。6.3 “为什么我 getInstance 拿到的两个实例不是同一个”这种问题通常和类加载器有关特别是在热部署、插件化、OSGi 环境中。表现是同一个类的全限定名相同但instanceof判断却是 falsegetInstance() 返回的对象身份也不一致。排查方法很简单在代码里打印类的加载器System.out.println(ConfigManager.class.getClassLoader()); System.out.println(instance.getClass().getClassLoader());如果两个输出不一致就说明类被不同加载器分别加载单例自然被“拆分”。对于 Web 应用的常见解决办法是把公共单例类放到容器级别的共享类库中或者使用Class.forName时指定统一的加载器。这个话题比较大不展开但知道现象和排查方向就够了。6.4 单例持有 View 导致的内存泄漏现场Android 里最常见的低水平错误之一就是在单例中持有 Activity 或 View 的引用。比如为了异步回调方便把一个 Activity 存在单例的字段里。Activity 销毁后单例里还留着它的强引用垃圾回收器无法回收就产生了内存泄漏。我在实际项目里看到的泄漏链通常是单例对象 - 接口回调 - Activity。比如静态单例的图片加载器持有一个 ImageListener而 ImageListener 是 Activity 的匿名内部类于是整个 Activity 都被单例拽着不放手。解决办法分为几个层次能用 Application Context 的地方优先用 Application Context用弱引用存储 Activity 或 View在 onDestroy 里主动解除回调引用。排查内存泄漏最常见的手段是用 Android Studio 的 Memory Profiler 抓取 heap dump搜索泄漏的类名查看引用链。这个工具能直接看到谁持有了 Activity效率很高。6.5 面试高频问题速查表问题建议回答思路单例模式的线程安全问题如何解决分实现方式说明饿汉天然安全、DCL 需要 volatile、静态内部类依赖类加载机制、枚举天然安全DCL 为什么两次判断外层判断有什么用外层判断避免每个线程都进同步块提升性能内层判断防止多个线程同时创建为什么 instance 必须加 volatile防止指令重排导致线程拿到未初始化完成的实例单例模式有什么缺点全局状态增加耦合、难以测试、序列化/反射可能破坏唯一性、跨进程不生效有没有不使用单例模式却达到类似效果的方案依赖注入Spring 单例 Bean、静态工具类、ThreadLocal 隔离实例等7. 我的一些实操体会聊了这么多最后分享一点我在真实项目里的体会。设计模式的魅力不在于“模式本身多精巧”而在于它是否真的解决了你的问题。单例模式最理想的使用方式是隐式的框架帮你管理生命周期开发者只需要通过注入或获取接口拿到对象而不需要关心它是不是单例。Spring 里默认的单例 Bean 就是这么用的。如果要在新项目里手写单例我倾向于这么选Java 优先用枚举或者静态内部类C 优先用 Meyers Singleton。这几种写法代码量最小线程安全也有保障不容易自己给自己埋坑。还有一个很实用的建议设计模式大作业如果选单例主题不要只写四种实现。要写清“为什么饿汉式不饿”“DCL 为什么需要 volatile”“枚举为什么能防反射”这三个问题再配一个真实场景的重构前后对比比其他同学高一截。另外如果你是去面试千万别把“单例模式”回答成背定义。面试官想听的不是你能说出几种写法而是你能不能在五分钟内讲清楚“进程里只有一个对象”这句话背后的内存语义、并发语义和架构边界。这就是我在单例模式这个“小”模式里看到的大世界。希望这些内容对你有用。