单例模式在SDK中的应用与陷阱

单例模式，说白了就是保证一个类只有一个实例。很多SDK的初始化入口、配置管理器、事件总线都喜欢用它。我刚开始做SDK时也觉得这玩意儿简单，没什么好讲的。直到线上出了几个诡异的崩溃……嗯，还是老老实实把坑填平再说。

核心观点：单例模式在SDK中不是“能不能用”，而是“怎么用对”。用错了，轻则初始化时序错乱，重则内存泄漏、死锁。

单例模式的价值在哪里？

SDK通常需要在App启动时完成初始化，之后整个生命周期都只有一份状态。比如网络请求的Session、本地数据库的Dao、推送服务的注册器。如果你每次调用都new一个，那资源开销和状态不一致会搞得你头疼。

我遇到过一个小伙伴，他的SDK每个API都new了一个网络客户端。结果呢？连接数爆了，后台直接封了IP。这就是典型的没用好单例。

经典的写法，但各有各的坑

实现方式 线程安全 延迟加载 序列化安全 我个人的评价
饿汉式（静态常量） ✅ ❌ ❌ 简单粗暴，适合无状态的SDK
懒汉式（synchronized） ✅ ✅ ❌ 性能极差，不推荐
双重检查锁定（DCL） ✅（需volatile） ✅ ❌ 常用，但volatile别漏了
静态内部类 ✅ ✅ ❌ 我的最爱，简洁且安全
枚举单例 ✅ ❌ ✅ 最佳实践，但很多人不习惯
警告：无论哪种写法，在Android多进程场景下，单例模式都会失效。每个进程都会有自己的ClassLoader，你懂的。

陷阱一：构造函数里的“隐形成本”

很多人写单例，把所有初始化逻辑都塞进构造函数里。你想想看，如果构造函数里做了网络请求、数据库建表、文件读写……那第一次调用getInstance()的时候，主线程直接就卡住了。

我建议：构造函数只做最轻量的赋值。真正消耗资源的初始化，交给单独的init()方法，或者交给应用层去触发。像这样：

public class SdkCore {
    private static volatile SdkCore instance;
    
    private SdkCore() {
        // 只做轻量操作
        this.version = BuildConfig.VERSION_NAME;
    }
    
    public static SdkCore getInstance() {
        if (instance == null) {
            synchronized (SdkCore.class) {
                if (instance == null) {
                    instance = new SdkCore();
                }
            }
        }
        return instance;
    }
    
    // 真正的初始化，让调用方异步执行
    public void initialize(Context context, SdkConfig config) {
        this.context = context.getApplicationContext();
        this.config = config;
        // 做真正的heavy work
    }
}
提示：getInstance() 里不要加任何参数。带参的 getInstance() 很容易导致重复注册或状态覆盖。

陷阱二：双重检查锁定里的volatile

我知道很多人写DCL（双重检查锁定）时会把volatile忘了。为什么需要它？因为instance = new SdkCore()在JVM里不是原子操作。它分为三步：

  1. 分配内存空间
  2. 执行构造函数
  3. 将引用指向内存空间

如果CPU发生了指令重排，可能第3步先于第2步执行。这时候别的线程拿到的是一个未初始化的对象。我在项目中遇到过这个问题，崩溃日志奇奇怪怪，排查了整整两天。

记住：DCL + volatile 是铁律。别偷懒。

陷阱三：反序列化破坏单例

你的SDK如果支持序列化（比如通过Intent传递、写入本地文件），那反序列化时会通过反射创建一个新实例。这会把你的单例直接毁掉。

解决方案：实现 readResolve() 方法，直接返回单例实例。

private Object readResolve() throws ObjectStreamException {
    return getInstance();
}

如果是枚举单例，这块天然免疫。我个人更偏爱枚举，但团队里很多人觉得枚举写法“怪怪的”。

陷阱四：类加载器隔离

Android的插件化、组件化，甚至简单的多个Dex，都可能导致同一个类被不同的ClassLoader加载两次。这时你的单例在内存里就变成了“双胞胎”。

我解决的办法是：在初始化时用一个全局的ConcurrentHashMap + Class作为key，来确保真的唯一。虽然有点重，但安全。

特别注意：如果你做的是跨进程SDK，单例模式基本不管用。老老实实走Binder或ContentProvider吧。

一张图理清单例在SDK中的检查清单

单例模式在SDK中的检查清单 单例类加载 检查构造函数轻量 检查volatile关键字 检查序列化安全 检查多进程场景 检查ClassLoader隔离 检查初始化时序 通过所有检查 → 安全单例 常见陷阱总结 ① 构造函数不要做重操作 ② volatile是DCL的命根子 ③ 序列化/多进程/插件化都可能破坏单例 ④ init()与getInstance()分离

最佳实践：我推荐这样写

如果你问我哪种写法最稳，我会选静态内部类。它既保证了延迟加载，又不需要synchronized，代码还简洁。配合一个轻量的构造函数，简直完美。

public class SdkManager {
    
    private SdkManager() {}
    
    private static class Holder {
        private static final SdkManager INSTANCE = new SdkManager();
    }
    
    public static SdkManager getInstance() {
        return Holder.INSTANCE;
    }
    
    // 分离初始化逻辑
    public void init(Context context, SdkConfig config) {
        // 真正的初始化操作
    }
}
一劳永逸的建议：在SDK内部，永远不要假设单例是唯一的。加个检查点，记录一下实例创建次数。线上如果发现创建了两次，立刻报警。我靠这个方式抓出过不少因为混淆、热修复导致的重复注册问题。

嗯，单例模式就是这么回事。看似简单，但每个细节都藏着坑。把握住上面说的几个关键点，你的SDK在初始化这块基本就稳了。

← 上一章 📖 返回目录 下一章 →