设计模式 - 单例模式

原创 已于 2026-05-19 08:11:04 修改 · 658 阅读 · 0 ·
本内容遵循CC 4.0 BY-SA版权协议
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
标签
#设计模式 #单例模式 #静态内部类
于 2011-09-03 10:41:53 首次发布

单例模式

1.定义：保证一个类仅有一个实例，并提供一个访问它的全局访问点。

2.补充：类是无状态的。

              Singleton模式用在单线程应用中

               是否已经实例化由实例自己判断，或由它的管理者判断，而不是使用者的责任。

               私有化实例类的构造函数，使的使用者不可能违规来创建单例类的实例。

3.饿汉式单例类

即静态初始化方式，它在类加载时即实例化对象，要提前占用资源，线程安全。

4.懒汉式单例类

  单检查锁定：懒汉式单例类在第一次被引用时实例化，非线程安全，需要做同步处理。但单检查锁定每次调用时都有都锁定开销，效率低。

 双检查锁定：Double-Checked Locking模式，即第一次检查后再锁定，效率高。在检查到实例为null之后进行同步，在同步代码中再检查一次实例是否为null，确保实例尚未创建。意图是优化掉不必要的锁定，这种同步检查最多在实例创建前进行一次，因此不会成为瓶颈。

双重检查锁定模式不能100%保证实例唯一性，加上volatile易变限定符是必要的补充措施，有两个作用：

  • 保证实例引用变量在多个线程中的可见性，以防止出现多次创建实例。
  • 保证实例引用变量在多个线程中的不可重排序，以防止出现使用未初始化的对象。

双重检查锁定模式

Kotlin实现

  • 实现步骤：
    • 主构造方法私有化
    • 通过伴生对象创建实例
    • 使用lazy委托属性实现延迟初始化
  • 线程安全配置：通过LazyThreadSafetyMode.SYNCHRONIZED参数保证线程安全

使用静态内部类持有单例

在Java中使用静态内部类（也称为静态持有者）是推荐的一种方式，因为它既达到了单例的目的，又避免了在单例类被加载时立即实例化单例对象。

因为外部类加载时并不会立即加载内部类，进而不会立即创建内部类中的实例。只有当第一次显示访问内部类时才会加载内部类。

静态内部类类装载‌方式是更简洁安全的实现，无需 volatile 且天然线程安全。

静态内部类方式

  1. ‌定义一个静态内部类‌，该内部类持有对外部类的唯一实例。
  2. ‌在外部类中提供一个静态方法‌，该方法返回静态内部类中持有并实例化的单例对象。

登记式，也可以叫做“静态内部类”式。 

  • 只有调用内部类的时候，内部类才开始加载（延时加载）
  • 非静态内部类要依附于外部类，必须创建外部类对象才能使用非静态内部类
  • 静态内部类不用外部类创建对象就可以使用

  • 优点：
    • 线程安全：利用类加载机制
    • 延迟加载：外部类加载时不会立即加载内部类
    • 高效：不需要同步锁

‌示例代码‌：

// 单例类
public class Singleton {
    // 私有构造函数
    private Singleton() {
    }

    // 静态内部类，持有静态单例对象
    private static class SingletonHolder {
        private static final Singleton INSTANCE = new Singleton();
    }

    // 静态方法，返回静态单例对象
    public static Singleton getInstance() {
        return SingletonHolder.INSTANCE;
    }
}

Kotlin实现

  • 实现方式：
    • 使用伴生对象(companion object)
    • 创建私有对象声明SingletonProvider，其中声明并初始化单例属性
    • 通过lazy委托实现延迟加载
  • 特性对比：
    • 与Java区别：Kotlin使用对象声明替代静态内部类
    • 线程安全：默认使用LazyThreadSafetyMode.SYNCHRONIZED保证线程安全
    • 语法简洁：通过by lazy简化延迟初始化实现
class Singleton4Kotlin private constructor() {
    private object SingletonProvider {
        val holder = Singleton4Kotlin()
    }
    
    companion object {
        val instance: Singleton4Kotlin by lazy { SingletonProvider.holder }
    }
}

优点：

  • ‌线程安全‌：这种方式是线程安全的，在多线程环境中也能保证单例的唯一性。
  • ‌延迟加载‌：只有在调用getInstance()方法时，才会加载SingletonHolder类，从而创建Singleton的实例。这种方式也被称为“双重校验锁”模式的变种，但不是双重校验锁的实现方式。
  • ‌简单‌：实现简单，易于理解。

总结

静态内部类方式是实现单例模式的一种非常高效且简洁的方式，特别适合在需要确保线程安全同时又希望延迟加载实例的情况下使用。这种方法结合了懒加载和线程安全的优点。

为什么需要 volatile 防止指令重排序

在 Java 多线程编程中，‌静态变量若被多个线程共享且涉及对象初始化（如单例模式），确实建议使用 volatile 修饰，以防止因指令重排序导致未完全初始化的对象被其他线程引用‌。

对象创建过程在 JVM 底层并非原子操作，通常分为以下三步：

  1. ‌分配内存空间‌
  2. ‌初始化对象‌（调用构造方法）
  3. ‌将对象引用赋值给变量‌

若无 volatile 修饰，JVM 或 CPU 可能为优化性能而将步骤 2 和 3 ‌重排序‌为：
‌1 → 3 → 2‌，即：

  • 先分配内存；
  • 立即将引用赋值给变量（此时对象尚未初始化）；
  • 再执行构造函数初始化。

此时，若另一个线程第一次检查变量，会发现它 ‌不为 null‌，于是直接返回一个 ‌未初始化的“半成品”对象‌，可能导致空指针异常、数据错误等难以复现的并发 Bug ‌‌。

volatile 如何解决？

volatile 通过以下机制确保安全：

  • ‌禁止指令重排序‌：在 volatile 变量的写操作前后插入 ‌内存屏障（Memory Barrier）‌，确保初始化操作（步骤 2）必须在引用赋值（步骤 3）之前完成 ‌‌。
  • ‌保证可见性‌：一个线程完成对象初始化并写入 volatile 变量后，其他线程能立即看到最新值，不会读到缓存中的 null 或部分初始化状态 ‌‌。

典型应用场景：双重检查锁定（DCL）单例模式

public class Singleton {
    private static volatile Singleton instance; // 关键：volatile 修饰

    private Singleton() {}

    public static Singleton getInstance() {
        if (instance == null) { // 第一次检查
            synchronized (Singleton.class) {
                if (instance == null) { // 第二次检查
                    instance = new Singleton(); // 若无 volatile，可能重排序
                }
            }
        }
        return instance;
    }
}

✅ ‌加 volatile‌：确保 instance = new Singleton() 按 ‌分配 → 初始化 → 赋值‌ 顺序执行，避免返回未初始化对象。
❌ ‌不加 volatile‌：在高并发下极可能返回半初始化对象，引发不可预测错误 ‌‌。

补充说明

  • volatile ‌不保证原子性‌，因此不能替代锁（如 synchronized 或 ReentrantLock）用于复合操作（如 count++）‌‌。
  • 在单例模式中，若追求更简洁安全的实现，可考虑 ‌静态内部类‌ 方式，无需 volatile 且天然线程安全 ‌‌：
public class Singleton {
    private Singleton() {}

    private static class Holder {
        private static final Singleton INSTANCE = new Singleton();
    }

    public static Singleton getInstance() {
        return Holder.INSTANCE;
    }
}

总结

  • ‌静态变量是否需用 volatile 修饰？‌
    → ‌仅在多线程环境下，该变量涉及对象引用赋值且存在初始化过程时，才需要‌（如 DCL 单例）。
  • ‌核心目的‌：‌禁止指令重排序，防止未初始化对象被引用‌，同时保证可见性 ‌‌。

单例模式

特点：全局唯一，在整个程序中，只有一个对象。

什么样的类适合单例？

单例可以在其它模式中使用。

  • 全局使用的类
  • 创建和销毁会消耗很多系统资源的类
    • 数据库连接池
    • 工厂类
    • 数据源

应用：

  • Spring的Bean默认情况下是单例
  • 项目中，读取配置文件的类，一般也只有一个对象。没有必要每次使用配置文件数据，每次new一个对象去读取。
  • 应用程序的日志应用，一般都何用单例模式实现，这一般是由于共享的日志文件一直处于打开状态，因为只能有一个实例去操作，否则内容不好追加。
  • 数据库连接池的设计一般也是采用单例模式，因为数据库连接是一种数据库资源。
  • 操作系统的文件系统，也是大的单例模式实现的具体例子，一个操作系统只能有一个文件系统。
  • Application 也是单例的典型应用（Servlet编程中会涉及到）
  • 在servlet编程中，每个Servlet也是单例
  • 在spring MVC框架/struts1框架中，控制器对象也是单例

反射和反序列化都可能破坏单例模式的唯一性‌

反射和反序列化都可能破坏单例模式的唯一性‌，导致一个类产生多个实例，违背单例设计初衷。

反射如何破坏单例？

  • 单例模式通常通过将构造函数设为 private 来防止外部直接实例化。
  • 但 Java 的反射机制可以在运行时绕过访问控制，‌强制调用私有构造函数‌，从而创建新实例。
Constructor<Singleton> constructor = Singleton.class.getDeclaredConstructor();
constructor.setAccessible(true);
Singleton evilInstance = constructor.newInstance(); // 破坏单例

反序列化如何破坏单例？

  • 如果单例类实现了 Serializable 接口，序列化后通过 ObjectInputStream.readObject() 反序列化时，‌会重新创建一个新对象‌，而非返回原有实例。
  • 原因：反序列化底层使用反射调用无参构造函数（或特殊机制）重建对象，‌不经过 getInstance()‌ ‌‌。
  • 测试结果：序列化前后的对象引用不同，‌破坏单例‌。

如何防止破坏？

防止反射破坏
  • 在构造函数中添加实例检查： 
    private Singleton() {
    if (instance != null) {
        throw new RuntimeException("不允许通过反射创建多个实例");
    }
}
  • ‌注意‌：此方法对懒汉式单例在多线程下可能失效，因构造函数可能被多次调用 ‌‌。
防止反序列化破坏
  • 在单例类中实现 readResolve() 方法，返回原有实例： 
    private Object readResolve() {
    return getInstance();
}
  • 反序列化时，JVM 会自动调用该方法，‌返回原单例实例‌，而非新建对象 ‌‌。

更优解：使用枚举实现单例

  • ‌枚举是 Java 中最安全的单例实现方式‌，能天然抵御反射和反序列化破坏 ‌‌。
  • 原因：
    • 枚举类继承自 java.lang.Enum，‌没有无参构造器‌，反射调用 getDeclaredConstructor() 失败。
    • 即使强制反射创建，JVM 会抛出 IllegalArgumentException ‌‌。
    • 反序列化时，通过 Enum.valueOf() 返回‌已有枚举常量‌，不会新建对象 ‌‌。

示例：

public enum Singleton {
    INSTANCE;
    // 其他业务方法
}

✅ ‌推荐‌：若无特殊限制，‌优先使用枚举实现单例‌，简洁且安全 ‌‌。

总结

破坏方式是否可行防护措施推荐方案
‌反射‌✅ 是构造函数中抛异常枚举（最安全）
‌反序列化‌✅ 是实现 readResolve() 方法枚举（自动防护）

‌最终建议‌：除非有特殊需求，‌使用枚举实现单例‌，避免手动处理反射和序列化问题

核心优势

  • ‌线程安全‌：JVM 在类加载时保证枚举实例唯一创建，无需额外同步 ‌‌。
  • ‌防止反射攻击‌：java.lang.reflect.Constructor 对枚举类型显式禁止通过 setAccessible(true) 创建新实例，会抛出 IllegalArgumentException ‌‌。
  • ‌防止序列化破坏‌：枚举的序列化机制确保反序列化时始终返回同一个实例（通过 valueOf() 查找，而非新建）‌‌。
  • ‌代码简洁‌：仅需 1–3 行代码即可完成单例定义，无冗余逻辑 ‌‌。
  • java1.5之后出现 目前推荐实现单例的最佳方式 线程安全 立即初始化 自动支持序列化，防止反序列化创建新的对象 防止反射攻击

适用场景

✅ 全局唯一资源管理（如日志、配置、数据库连接池）
✅ 需防范反射或序列化攻击的系统
✅ 不需要延迟初始化（枚举为‌饿汉式‌加载）

❌ 若需‌懒加载‌，可考虑静态内部类方式 ‌‌
❌ 枚举不能继承其他类（但可实现接口）‌‌

ThreadLocal实现线程内单例

优点： 空间换时间 延时加载

缺点： 只能是在同一个线程中获得的两个对象才是单例

public class Singleton {
    private Singleton() {
    }
    private static ThreadLocal<Singleton> threadLocalSingleton = new ThreadLocal<Singleton>() {
        @Override
        protected Singleton initialValue(){ 
            return new Singleton();
        }
    };
    public static Singleton getInstance(){ 
        return threadLocalSingleton.get();
    }
}

通过CAS实现单例

缺点： 可能会产生垃圾对象

上述几种单例模式的比较

  • 饿汉式：线程安全、反射不安全、反序列化不安全、非延时加载。
  • 懒汉式：线程不安全、反射不安全、反序列化不安全、延时加载。
  • 双重检测锁：线程安全、反射不安全、反序列化不安全、延时加载。
  • 登记式：线程安全、反射安全、反序列化不安全、延时加载。
  • 枚举式：线程安全、反射安全、反序列化安全、非延时加载。
  • ThreadLocal：不加锁，以空间换时间，为每个线程提供独立副本，可以保证各自线程是单例的，但是不同线程之间不是单例的。
  • CAS：无锁乐观策略，线程安全。
java设计模式之单例模式——Singleton pattern
ANGEL CITY
01-03 2380
设计模式故事会：https://blog.csdn.net/weixin_40205234/article/details/90664824 单例模式 单例模式（Singleton pattern）是java中最常见的设计模式之一。该模式属于创建型设计模式，它提供了一种创建对象的最佳方式。这种模式涉及到一个单一的类，该类负责创建自己的对象，同时确保只有单个对象被创建。这个类提供了一种访问其唯一...
设计模式-单例模式（Singleton Pattern）
kaven
01-21 5039
单例模式 定义 确保一个类只有一个实例，并为整个系统提供一个全局访问点 (向整个系统提供这个实例)。 类型 创建型。 适用场景 网站访问量计数器。 项目中用于读取配置文件的类。 Spring中，每个Bean默认都是单例的，这样便于Spring容器进行管理。 优点 由于单例模式只生成了一个实例，所以能够节约系统资源、减少性能开销、提高系统效率。 缺点 不适合用于变化频繁的对象；如果实例化的对象长...
23种设计模式中的单例模式（Singleton Pattern）
小威的博客
05-10 2万+
本篇文章将23种设计模式中的单例设计模式，此篇文章为一天学习一个设计模式系列文章，后面会分享其他模式知识。
设计模式之单例模式（Singleton Pattern）
weixin_42294716的博客
01-31 1362
意图：保证一个类仅有一个实例，并提供一个访问它的全局访问点。主要解决：一个全局使用的类频繁地创建与销毁。何时使用：当您想控制实例数目，节省系统资源的时候。如何解决：判断系统是否已经有这个单例，如果有则返回，如果没有则创建。关键代码：构造函数是私有的。
设计模式——单例模式（Singleton Pattern）
qq_42498542的博客
06-16 813
设计模式——单例模式（Singleton Pattern） 单例模式（Singleton Pattern）是 Java 中最简单的设计模式之一。这种类型的设计模式属于创建型模式，它提供了一种创建对象的最佳方式。 在有些场景中，为了节省内存资源、保证数据内容的一致性，对某些类要求只能创建一个实例，且该类能自行创建这个实例，这就是所谓的单例模式 文章目录设计模式——单例模式（Singleton Pattern）单例模式的优缺点优点缺点单例模式的应用场景单例模式与静态类的区别常见的7种实现方式1.饿汉模式2.懒
设计模式 - 装饰模式
热门推荐
05-13 2万+
装饰模式也是面向接口编程，装饰类同时实现和聚集相同的接口，这样装饰对象就包装了接口对象，并且它本身还可以被包装进其它装饰对象，这样就形成了装饰链。
面向对象范型
05-26 3522
1.面向对象范型是为了应对使用标准化结构程序设计遇到的诸多挑战应运而生的。 2.功能分解是处理复杂问题的自然方法。解决小问题比解决整个问题要简单。    功能分解方法通常会让一个主程序控制子程序，但可能出现的问题是：主程序承受的责任太多了，经常会产生复杂的代码。如果让一些子函数负责自己的行为，并且告知主函数执行某些任务，这就是委托。    另一个问题是，它艰难的应对变化。变化到来时，它可能要
Observer模式，delegate(委托)模式
10-06 2175
观察者(Observer)模式 1.定义对象间的一种一对多的依赖关系，当一个对象的状态发生改变时，所有依赖于它的对象都将得到通知并自动更新。 2.观察者(Observer)，是希望得到获得通知的对象。    目标(subject),触发事件的对象.    如果Observer对象需要从subject那里获得更多信息，就需要传给接口函数一个指向调用对象(subject)的引用. 3.Obs
State模式
06-03 1108
一个函数内的方法过长，则出现了坏味道。这往往违背了单一职责原则，并且还将违背开闭原则。 状态模式：当一个对象的内在状态改变时，允许改变其行为，这个对象看起来像是改变了其类。 状态模式 主要解决的是 控制一个对象状态转换的条件表达式过于复杂的问题。把状态的判断逻辑转移到表示不同的状态的一系列类中，简化复杂的判断逻辑。 如果原状态判断很简单，则没必要用状态模式了。 状态模式的好处是将与特定状态
编码规范，objective-c编码规范
12-14 1094
参考了> 1.匈牙利命名 和 不要盲目使用匈牙利命名 命名规范是程序书写规范中最重要也是最富争议的地方，自古乃兵家必争之地。命名规范有何用？四个字：名正言顺。好的舞鞋是让舞者感觉不到其存在的舞鞋，坏的舞鞋是让舞者带着镣铐起舞。 匈牙利命名法的成本:匈法的表现形式为给变量名附加上类型名前缀，例如：nFoo,szFoo,pFoo,cpFoo分别表示整型变量，字符串型变量，指针型变量和常指针型
缓存内存模型
05-29 987
1.Symbian中颜色由TRgb类列表，TRgb是一个32位的值，分别使用8位表示Red,Green,Blue，另有8位备用。　Series60对于不同的制造商有高度的可定制性，可以更改用户界面的颜色方案，所以为了确保颜色与使用的调色板保持一致，需要使用宏AKN_LAF_COLOR()定义颜色，从调色板值列表中找出颜色值传入AKN_LAF_COLOR生成对应的TRgb颜色.2.可用的颜色
设计模式的原则和策略
03-27 924
在局部层次，模式告诉如何解决给定背景下的特定问题；在全局层次，模式提供了一张应用程序各组件的关系图。 1.单一职责原则    类中的职责过多时，一具职责变化可能会削弱或抑制这个类完成其它职责的能力，导致脆弱的设计。    如果能想到多于一个的动机改变这个类，则这个类就具有多于一个的职责，就应该考虑类的职责分离。    这个原则也即是强内聚，松耦合。 2.开闭原则，open
设计模式-Adapter模式
09-15 809
1.定义：将一个类的接口转换成希望的另一个接口。使原来由于接口不兼容而不能一起工作的类可以一起工作。 2.补充：通常用于需要的类必须从抽象类派生，但现有的类不是；               Adapter模式最终提供了具有所需接口的包装类；               Adapter模式最常见的用途就是保持多态性；   3.实现：将原有类包含在另一个类中，让包含类与需要的接口匹配，调用
Bridge模式
09-23 791
Bridge模式将实现看成对象之外的东西，对象所使用的东西，这样使变化隐藏在实现中，与调用程序隔离开了。很多开发人员喜欢对最开始提出的设计方案从一而终，勇于寻找原设计的替代方案，考虑怎么克服原设计中的缺陷的做法是非常提倡，鼓励，推荐的。1.问题：在一个抽象类的不同的派生类中需要使用很多不同的实现，此时容易出现派生类数量爆炸性增长。（这里的实现是指抽象类及其派生类中用来实现自己逻辑的其它对象，而抽象类的派生类被称为具体类）。是一种修改软件系统的过程，改进代码的内部结构，而不增加功能，不改变代码的外在行为。
敏捷编程
02-18 790
1.极限编程的思想是循序渐近的开发，在编程的同时进行验证，大的概念从众多小的概念中演变出来。    为了设计出高质量代码，它与设计模式同样追求一些品质：无冗余，可读，可测试。    敏捷编程是在熟练领悟设计模式思想后才能良好做到的。 2.无冗余    一次规则：一个规则，一个地方。   这通常要求多使用几个方法，增加的开销是非常小的，而好外却很明显。重复的代码实际上也是互相耦合的。
登录验证和通行验证的概念
10-03 779
登录 登录包括身份认证和返回通行证双向过程。 身份认证信息例如有：账号+密码+图片验证码、账号+短信验证码。 通行证例如有Token，token中加密了账户的详细信息。 通行 通行信息例如有：账号+token。服务端要解析验证token有效，并且和账号匹配。 通行证验证和登录验证的区别 通行证相当于替代了密码+验证码，安全不敏感，用在频繁的通行验证中更方便。 ...
阻塞和非阻塞、同步和异步、挂起
06-17 776
异步：指发送方发出数据后，等收到接收方发回的响应，才发下一个数据包的通信方式。阻塞：指调用某函数时，直到该函数完成操作，才返回；否则一直阻塞在该调用上。非阻塞：指调用某操作时，不管操作是否成功都立即返回，而不会挂在该操作上。同步：指的是发送方不等接收方响应，便接着发下个数据包的通信方式；
挂起、阻塞、锁和cpu占用
08-06 762
都能让线程暂停执行，但它们的目的机制和使用场景有本质区别。在 Java 多线程编程中，
设计模式概念
09-26 758
1.设计模式源自建筑学和人类学，模式结合起来可以解决更复杂的问题。    一个模式的描述应该包括4项：模式的名称，模式的目的（即要解决的问题），模式的实现方法，约束因素。    2.设计模式和面向对象是相得益彰的关系。    学习设计模式我们可以：复用解决方案；确立通用术语；提升了观察视角；    设计模式可以帮助团队提高效率，使软件更容易修改和维护，   3.设计常被认为是一种将事
Decorator模式
06-30 746
1.定义：    动态的给一个对象添加一些额外的职责。比生成子类更加灵活。    工作原理是：创建始于Decorator对象，终于原对象的一个对象链。    此模式的核心是让功能对象变为装饰对象链。    Concrete 具体的    Decorator 装饰对象    抽象类Decorator和ConcreteComponent都继承抽象类Component，Decorator
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值