为什么没有 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<t></t>:默认线程安全,内部使用正确的内存屏障,且支持延迟初始化 + 异常缓存 用静态构造函数:CLR 保证只执行一次且完全线程安全,但不支持懒加载(类型首次被访问即初始化)
推荐写法(懒加载 + 安全 + 简洁):
public sealed class Singleton
{
private static readonly Lazy<Singleton> _lazy =
new Lazy<Singleton>(() => new Singleton());
public static Singleton Instance => _lazy.Value;
private Singleton() { }
}
真正容易被忽略的是:即使加了
volatile,双重检查锁定仍比
Lazy<t></t>更难验证、更易误用(比如漏掉
volatile、改用非引用类型、或在构造函数里暴露
this)。除非你在极老的 .NET 版本上无法用
Lazy<t></t>,否则别碰它。
