单例多例模式原理与实现解析

珍惜时间，勤奋学习！今天给大家带来《单例与多例模式实现原理详解》，正文内容主要涉及到等等，如果你正在学习文章，或者是对文章有疑问，欢迎大家关注我！后面我会持续更新相关内容的，希望都能帮到正在学习的大家！

单例模式只能有一个实例的关键在于私有化构造方法并由类内部管理唯一实例的创建与返回；常用实现有饿汉式（类加载时初始化，线程安全但可能浪费资源）和懒汉式（延迟初始化，需synchronized或DCL+volatile防重排）；静态内部类方式因JVM类加载机制天然线程安全且延迟加载，更推荐；多例模式通过key映射有限实例池，用ConcurrentHashMap保证线程安全；Spring的@Scope("singleton")是容器级单例，与编码级单例模式无必然关联，二者控制权不同。

单例模式为什么只能有一个实例

关键在于控制类的构造方法访问权限，并在类内部管理唯一实例的创建与返回。Java 中最常用的是「懒汉式（线程安全版）」和「饿汉式」，区别在于实例化时机和并发处理方式。

• private static 字段保存唯一实例，外部无法直接 new
• 构造方法必须是 private，否则任何代码都能绕过单例逻辑
• 饿汉式在类加载时就初始化 instance = new Singleton()，天然线程安全但可能浪费资源
• 懒汉式用 synchronized 修饰 getInstance() 方法或采用双重检查锁（DCL），延迟初始化但需注意 volatile 修饰 instance 防止指令重排

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;
    }
}

多例模式不是“多个单例”，而是有限实例池

多例（Multiton）本质是把“唯一实例”扩展为“固定数量的实例”，通常按键（key）索引，比如按配置名、线程ID 或环境类型返回不同实例。它不保证全局唯一，但保证每个 key 对应的实例只创建一次。

• 核心结构是 private static Map instances = new HashMap<>()
• 构造方法仍为 private，避免外部随意创建
• 通过 get(String key) 获取实例，首次调用才创建，后续复用
• 注意：若 key 不可控（如用户输入），需加白名单或哈希截断，防止内存泄漏
• 和单例一样，多例也需考虑线程安全——ConcurrentHashMap 比 HashMap + synchronized 更轻量

public class Multiton {
    private static final Map instances = new ConcurrentHashMap<>();
    private final String name;
    private Multiton(String name) { this.name = name; }
    public static Multiton get(String key) {
        return instances.computeIfAbsent(key, Multiton::new);
    }
}

Spring 中的 @Scope 注解不是实现模式，而是容器行为契约

很多人混淆「单例模式」和 Spring 的 @Scope("singleton")。前者是编码层面的类设计约束，后者是 Spring IoC 容器对 Bean 生命周期的管理策略。同一个类，既可被写成单例模式，也可在 Spring 中声明为 @Scope("prototype") —— 此时容器每次 getBean() 都新建实例，完全绕过类内部的单例逻辑。

• @Scope("singleton")（默认）：Spring 容器中该 Bean 的定义只有一个共享实例，但和 Java 单例模式无必然关系
• @Scope("prototype")：每次请求都新建 Bean 实例，此时即使类内部用了 DCL 单例写法，只要不被 Spring 管理或被多次注册，就不生效
• 真正冲突点在于：如果一个类自己实现了单例模式，又交给 Spring 管理为 prototype，会导致语义矛盾——开发者以为每次都是新对象，实则内部状态被多个 Bean 实例共享

为什么静态内部类方式比双重检查锁更推荐

因为它是 JVM 层面保障的线程安全 + 延迟加载，无需 synchronized 和 volatile，代码更简洁，且能避免 DCL 在早期 JDK 版本中的潜在问题。

• 静态内部类 Holder 只在首次调用 getInstance() 时才被加载，触发其 static 字段初始化
• JVM 保证类加载过程的线程安全性，天然规避了同步开销
• 相比饿汉式，不浪费资源；相比 DCL，没有指令重排风险，也不依赖 volatile 的语义理解深度

public class Singleton {
    private Singleton() {}
    private static class Holder {
        static final Singleton INSTANCE = new Singleton();
    }
    public static Singleton getInstance() {
        return Holder.INSTANCE;
    }
}

真正容易被忽略的是：单例/多例的边界只在「谁负责控制实例数量」。手写单例控制权在类自身；Spring 控制权在容器；而像数据库连接池、线程池这类“多实例复用”机制，控制权又在独立的工厂或管理者——它们都不是语言层面的模式，而是运行时策略。写代码时得先想清楚：这个“唯一性”到底该由谁来保证。

以上就是本文的全部内容了，是否有顺利帮助你解决问题？若是能给你带来学习上的帮助，请大家多多支持golang学习网！更多关于文章的相关知识，也可关注golang学习网公众号。