如何实现一个线程安全的单例？-Python教程-PHP中文网

答案：双重检查锁定（DCL）通过volatile关键字和同步块确保线程安全，防止指令重排序与内存可见性问题，实现高效懒加载单例。

如何实现一个线程安全的单例？

实现一个线程安全的单例模式，核心在于确保在多线程并发访问时，类的实例只会被创建一次。这通常通过延迟初始化（Lazy Initialization）结合恰当的同步机制来达成，其中“双重检查锁定”（Double-Checked Locking, DCL）是一个非常经典且高效的策略，尤其是在Java这类语言中，配合

volatile

登录后复制

关键字使用，能有效解决并发问题并保证性能。

解决方案

在Java中，实现线程安全的单例，我个人比较倾向于使用双重检查锁定（DCL）模式，因为它在保证线程安全的同时，兼顾了性能，避免了不必要的同步开销。

public class ThreadSafeSingleton {
    // 使用 volatile 关键字确保多线程环境下，对 instance 的修改能立即被其他线程看到
    // 并且防止指令重排序，这是 DCL 模式的关键所在。
    private static volatile ThreadSafeSingleton instance;

    // 私有构造器，阻止外部直接创建实例
    private ThreadSafeSingleton() {
        // 防止通过反射机制创建多个实例，可以抛出异常
        if (instance != null) {
            throw new RuntimeException("请使用 getInstance() 方法获取单例实例。");
        }
        // 这里可以有一些初始化逻辑
        System.out.println("单例实例正在被创建...");
    }

    // 公有静态方法，提供全局访问点
    public static ThreadSafeSingleton getInstance() {
        // 第一次检查：如果实例已经存在，直接返回，避免进入同步块，提高性能
        if (instance == null) {
            // 同步块：确保只有一个线程能进入创建实例
            synchronized (ThreadSafeSingleton.class) {
                // 第二次检查：在同步块内部再次检查，防止多线程下重复创建
                if (instance == null) {
                    instance = new ThreadSafeSingleton();
                }
            }
        }
        return instance;
    }

    public void showMessage() {
        System.out.println("Hello from the Singleton!");
    }
}

登录后复制

这段代码的核心思想是：先进行一次非同步的

null

登录后复制

检查。如果实例已经存在，就直接返回，这样后续的线程就不会进入同步块，大大减少了锁的竞争。只有当实例为

null

登录后复制

时，才进入同步块。进入同步块后，会进行第二次

null

登录后复制

检查，这是为了防止在第一个线程创建实例的过程中，第二个线程也通过了第一次

null

登录后复制

检查并等待进入同步块。当第一个线程释放锁后，第二个线程进入同步块，如果不再检查一次，它就会再次创建一个实例，从而破坏单例。

volatile

登录后复制

关键字在这里的作用至关重要，它确保了

instance

登录后复制

变量的可见性以及禁止了指令重排序，这我们后面会详细聊聊。

为什么普通的单例模式在多线程环境下会失效？

这个问题其实挺有意思的，它揭示了并发编程中一个非常基础但又容易被忽视的“坑”。想象一下，如果我们的单例模式是那种最简单的懒汉式，也就是

getInstance()

登录后复制

方法没有加任何同步措施：

public class SimpleSingleton {
    private static SimpleSingleton instance;

    private SimpleSingleton() {}

    public static SimpleSingleton getInstance() {
        if (instance == null) { // 检查实例是否为null
            instance = new SimpleSingleton(); // 如果是null，就创建
        }
        return instance;
    }
}

登录后复制

在单线程环境下，这当然没问题。但一旦我们引入了多线程，麻烦就来了。假设有两个线程（Thread A 和 Thread B）几乎同时调用了

getInstance()

登录后复制

方法。

Thread A 执行到
```
if (instance == null)
```
登录后复制
，发现
```
instance
```
登录后复制
确实是
```
null
```
登录后复制
。
Thread B 也执行到
```
if (instance == null)
```
登录后复制
，同样发现
```
instance
```
登录后复制
是
```
null
```
登录后复制
（因为 Thread A 还没来得及创建并赋值）。
Thread A 继续执行
```
instance = new SimpleSingleton();
```
登录后复制
，创建了一个实例。
紧接着，Thread B 也执行
```
instance = new SimpleSingleton();
```
登录后复制
，又创建了一个实例。

瞧，原本我们希望只有一个实例，结果却在内存中拥有了两个甚至更多的

SimpleSingleton

登录后复制

对象。这不仅违背了单例模式的初衷，还可能导致一些难以预料的程序行为，比如资源冲突、状态不一致等。这就是所谓的“竞态条件”（Race Condition）问题，多个线程竞争共享资源（这里是

instance

登录后复制

的创建和赋值），导致结果不可预测。所以，对于任何需要在多线程环境中使用的单例，我们都必须认真考虑其线程安全性。

除了双重检查锁定，还有哪些实现线程安全单例的方法？各自的优缺点是什么？

当然有，双重检查锁定虽然高效，但也不是唯一的选择。在不同的场景和对性能、简洁性有不同要求时，我们会有其他考量。这里我列举几种常见的线程安全单例实现方式：

1. 饿汉式（Eager Initialization）

这是最简单直接的一种。在类加载的时候就直接创建实例。

public class EagerSingleton {
    private static EagerSingleton instance = new EagerSingleton(); // 类加载时即创建

    private EagerSingleton() {}

    public static EagerSingleton getInstance() {
        return instance;
    }
}

登录后复制

优点：
- 天生线程安全： 由于实例在类加载时就创建了，JVM会保证这个过程是线程安全的，所以不存在并发问题。
- 实现简单： 代码量少，容易理解。
缺点：
- 非懒加载： 无论这个单例实例是否会被用到，它都会在类加载时被创建。如果单例的初始化比较耗时，或者它占用的资源比较多，而程序运行期间又很少用到它，这就会造成资源的浪费。

2. 懒汉式加锁（Synchronized getInstance() Method）

这是在最简单懒汉式基础上，直接给

getInstance()

登录后复制

方法加上

synchronized

登录后复制

关键字。

public class SynchronizedSingleton {
    private static SynchronizedSingleton instance;

    private SynchronizedSingleton() {}

    public static synchronized SynchronizedSingleton getInstance() { // 整个方法加锁
        if (instance == null) {
            instance = new SynchronizedSingleton();
        }
        return instance;
    }
}

登录后复制

优点：
- 懒加载： 只有在第一次调用
```
getInstance()
```
  登录后复制
  时才会创建实例。
- 线程安全：
```
synchronized
```
  登录后复制
  关键字确保了同一时间只有一个线程能进入
```
getInstance()
```
  登录后复制
  方法，从而保证了实例的唯一性。
缺点：
- 性能开销大： 每次调用
```
getInstance()
```
  登录后复制
  方法时，都需要进行同步，这会带来不小的性能损耗。即使实例已经创建，后续的每次调用依然需要获取和释放锁，这在并发量大的系统中是不可接受的。

3. 静态内部类（Static Inner Class / Initialization-on-demand holder idiom）

一键职达

AI全自动批量代投简历软件，自动浏览招聘网站从海量职位中用AI匹配职位并完成投递的全自动操作，真正实现'一键职达'的便捷体验。

查看详情

这是一种非常优雅且推荐的实现方式，被认为是Java中实现线程安全单例的最佳实践之一。

public class StaticInnerClassSingleton {
    private StaticInnerClassSingleton() {}

    // 静态内部类，只有在第一次使用时才会被加载
    private static class SingletonHolder {
        private static final StaticInnerClassSingleton INSTANCE = new StaticInnerClassSingleton();
    }

    public static StaticInnerClassSingleton getInstance() {
        return SingletonHolder.INSTANCE;
    }
}

登录后复制

优点：
- 懒加载：
```
SingletonHolder
```
  登录后复制
  这个静态内部类只有在
```
getInstance()
```
  登录后复制
  方法被调用时才会被加载，从而实现了实例的延迟初始化。
- 线程安全： JVM在加载类时是线程安全的，它会保证
```
SingletonHolder
```
  登录后复制
  类只会被加载一次，并且在加载过程中创建
```
instance
```
  登录后复制
  实例。
- 性能高：
```
getInstance()
```
  登录后复制
  方法本身没有同步块，所以每次调用都没有额外的性能开销。
缺点：
- 相较于饿汉式，代码稍微多一点点，但其带来的好处是显而易见的。

4. 枚举单例（Enum Singleton）

这是Java语言在JDK 1.5之后提供的一种实现单例的最佳方式，由Effective Java的作者Joshua Bloch推荐。

public enum EnumSingleton {
    INSTANCE; // 唯一的实例

    public void showMessage() {
        System.out.println("Hello from the Enum Singleton!");
    }
}

登录后复制

优点：
- 最简洁： 代码量最少。
- 天生线程安全： 枚举类型在JVM层面就保证了其单例性，没有任何并发问题。
- 防止反射攻击： 枚举没有公共构造器，所以无法通过反射创建多个实例。
- 防止反序列化问题： 枚举实例的序列化和反序列化由JVM特殊处理，不会创建新的实例。
缺点：
- 不适用于所有场景： 如果你的单例需要继承其他类（Java枚举默认继承
```
Enum
```
  登录后复制
  ），或者需要复杂的初始化逻辑，枚举单例可能就不太合适了。

在我看来，如果你使用的是Java，并且对单例的懒加载、线程安全和性能都有要求，那么静态内部类或者枚举单例通常是最好的选择。DCL虽然经典，但理解和正确实现需要更多细节考量（特别是

volatile

登录后复制

），稍有不慎就可能出错。

在使用双重检查锁定（DCL）时，

volatile

登录后复制

关键字到底起到了什么关键作用？

volatile

登录后复制

关键字在DCL中扮演的角色，简直就是整个模式的灵魂，少了它，DCL就可能失效，甚至引发非常隐晦且难以调试的错误。它的关键作用主要体现在两个方面：内存可见性和防止指令重排序。

我们先来理解一下，一个对象创建的过程，在JVM底层通常会分解成几个步骤：

分配内存： 为
```
ThreadSafeSingleton
```
登录后复制
对象分配一块内存空间。
初始化对象： 调用
```
ThreadSafeSingleton
```
登录后复制
的构造函数，执行一些初始化操作，比如设置字段的默认值，或者执行构造函数中的业务逻辑。
设置引用： 将
```
instance
```
登录后复制
变量指向刚刚分配的内存地址。

问题就出在这里。在没有

volatile

登录后复制

关键字修饰

instance

登录后复制

变量的情况下，JVM的编译器和CPU为了优化性能，可能会对这三个步骤进行指令重排序。也就是说，步骤2和步骤3的顺序可能会颠倒，变成1 -> 3 -> 2。

如果发生了这种重排序，我们设想一下这样的场景：

Thread A 进入
```
getInstance()
```
登录后复制
方法，通过了第一次
```
null
```
登录后复制
检查，进入同步块。
Thread A 开始创建实例，但由于指令重排序，它先执行了步骤1（分配内存）和步骤3（设置引用），将
```
instance
```
登录后复制
指向了这块内存地址，但此时步骤2（对象初始化）还没有完成！也就是说，
```
instance
```
登录后复制
已经不为
```
null
```
登录后复制
了，但它指向的却是一个“半成品”对象。
此时，Thread A 暂时被挂起（比如时间片用完）。
Thread B 进入
```
getInstance()
```
登录后复制
方法，执行第一次
```
null
```
登录后复制
检查。它发现
```
instance
```
登录后复制
已经不为
```
null
```
登录后复制
了（因为它已经被Thread A指向了那块内存），于是Thread B直接返回了这个“半成品”的
```
instance
```
登录后复制
。
Thread B 尝试使用这个
```
instance
```
登录后复制
对象，由于对象还没有完全初始化，它可能会访问到未初始化的字段，导致
```
NullPointerException
```
登录后复制
或其他不可预知的错误。