加 volatile 可修复双重检查锁定错误，因其禁止对 _instance 的读写重排序并确保内存可见性；推荐改用 Lazy 或静态构造函数实现线程安全单例。
为什么没有 volatile 的双重检查锁定会出错
因为在 .NET 2.0+ 的 JIT 编译器和 x86/x64 内存模型下，new Singleton() 的执行可能被重排序：分配内存 → 写入字段 → 调用构造函数。如果线程 A 在构造函数尚未完成时，就将已分配但未初始化完毕的 _instance 引用写回主内存（或让其他线程看到），线程 B 就可能拿到一个「半初始化」的对象——调用其方法时抛出 NullReferenceException 或更隐蔽的逻辑错误。
Double-Checked Locking 的典型错误写法长什么样
下面这段代码在 .NET Framework 2.0–4.7（未加 volatile）和早期 .NET Core 版本中是不安全的：
public sealed class Singleton
{
private static Singleton _instance;
private static readonly object _lock = new object();
public static Singleton Instance
{
get
{
if (_instance == null) // 第一次检查
{
lock (_lock)
{
if (_instance == null) // 第二次检查
{
_instance = new Singleton(); // ⚠️ 这里可能被重排序！
}
}
}
return _instance;
}
}
private Singleton() { }
}
问题不在 lock，而在于：lock 只保证临界区的互斥，不保证对 _instance 的写操作对其他线程「立即可见」，也不阻止 JIT 将对象初始化步骤重排。
为什么加 volatile 就能修好
volatile 对 _instance 字段施加了两个关键约束：
- 禁止编译器和 JIT 对该字段的读/写进行重排序（特别是禁止把
_instance = new Singleton()中的引用赋值提前到构造函数执行完之前） - 确保每次读取都从主内存（或最新缓存）获取值，每次写入都立即刷新到主内存，使其他线程能及时看到更新
修正后的安全写法：
public sealed class Singleton
{
private static volatile Singleton _instance; // ✅ 加 volatile
private static readonly object _lock = new object();
public static Singleton Instance
{
get
{
if (_instance == null)
{
lock (_lock)
{
if (_instance == null)
{
_instance = new Singleton();
}
}
}
return _instance;
}
}
private Singleton() { }
}
但其实你根本不需要手写双重检查锁定
.NET 已提供更简洁、更可靠的方式：
- 用
Lazy：默认线程安全，内部使用正确的内存屏障，且支持延迟初始化 + 异常缓存 - 用静态构造函数：CLR 保证只执行一次且完全线程安全，但不支持懒加载（类型首次被访问即初始化）
推荐写法（懒加载 + 安全 + 简洁）：
public sealed class Singleton
{
private static readonly Lazy _lazy =
new Lazy(() => new Singleton());
public static Singleton Instance => _lazy.Value;
private Singleton() { }
}
真正容易被忽略的是：即使加了 volatile，双重检查锁定仍比 Lazy 更难验证、更易误用（比如漏掉 volatile、改用非引用类型、或在构造函数里暴露 this）。除非你在极老的 .NET 版本上无法用 Lazy，否则别碰它。
