目录
使用同步监视器允许2和3重排序,但不允许其他线程“看到”这个重排序
问题根源
public class DoubleCheckedLocking { // 1
private static Instance instance; // 2
public static Instance getInstance() { // 3
if (instance == null) { // 4:第一次检查
synchronized (DoubleCheckedLocking.class) { // 5:加锁
if (instance == null) // 6:第二次检查
instance = new Instance(); // 7:问题的根源出在这里
} // 8
} // 9
return instance; // 10
} // 11
}
new一个对象经历 的过程如下:
memory = allocate(); // 1:分配对象的内存空间
ctorInstance(memory); // 2:初始化对象
instance = memory; // 3:设置instance指向刚分配的内存地址
但是编译器或者cpu处理器会对以上做指令的重排序:
memory = allocate(); // 1:分配对象的内存空间
instance = memory; // 3:设置instance指向刚分配的内存地址
// 注意,此时对象还没有被初始化!
ctorInstance(memory); // 2:初始化对象
现在来考虑A,B 2个线程同时调用getInstance方法,A线程正要执行初始化对象时,B线程做第一次检查,可能会发现instance变量并非为null,B线程拿到了一个未初始化的对象去使用,最终会发生一些未知错误。
解决方案
不允许2和3重排序
public class SafeDoubleCheckedLocking {
private volatile static Instance instance;//volatile被JMM实现为1.保证可见性;2.禁止重排前后指令
public static Instance getInstance() {
if (instance == null) {
synchronized (SafeDoubleCheckedLocking.class) {
if (instance == null)
instance = new Instance(); // instance为volatile,现在没问题了
}
}
return instance;
}
}
说明:以上的2,3重排序,在JSR-133内存模型规范[JDK5]之前,即使用了volatile,也是可以的;但之后加强了volatile变量的语义,也就是有了acquire和release语义(定义了一种Happens-before关系)。在之前的规范中,volatile变量的访问和非volatile变量的访问之间可以自由地重排序,JSR-133出来后就不可以了,也就是JSR-133出来后,1的写(非volatile变量的访问)和3的写(volatile变量的访问)之间不可以重排序。
使用同步监视器允许2和3重排序,但不允许其他线程“看到”这个重排序
public class InstanceFactory {
private static class InstanceHolder {
public static Instance instance = new Instance();
}
public static Instance getInstance() {
return InstanceHolder.instance ; // 这里将导致InstanceHolder类被初始化,进而同步加锁地执行静态代码块、静态字段初始化等操作
}
}
C++的单例
除了使用锁的语义和静态局部变量外:
Singleton* Singleton::getInstance() {
Lock lock; // scope-based lock, released automatically when the function returns
if (m_instance == NULL) {
m_instance = new Singleton;
}
return m_instance;
}
Singleton& Singleton::getInstance() {
static Singleton instance;
return instance;
}
在2004年,Scott Meyers和Andrei Alexandrescu发表了一篇题为《C++ and the Perils of Double-Checked Locking》的文章。
第12页里有一个通用的模板:
Singleton* Singleton::instance () {
Singleton* tmp = pInstance;
... // insert memory barrier
if (tmp == 0) {
Lock lock;
tmp = pInstance;
if (tmp == 0) {
tmp = new Singleton;
... // insert memory barrier
pInstance = tmp;
}
}
return tmp;
}
以下的三种实现,都是利用了acquir-release这对语义,该语义定义了一种Inter-thread happens-before关系,可以让我们放心:“tmp = new Singleton”所对应的的指令一定不会越过“m_instance.store(tmp, std::memory_order_xxx)”。
//atomic_thread_fence的a-r语义
std::atomic<Singleton*> Singleton::m_instance;
std::mutex Singleton::m_mutex;
Singleton* Singleton::getInstance() {
Singleton* tmp = m_instance.load(std::memory_order_relaxed);
std::atomic_thread_fence(std::memory_order_acquire);
if (tmp == nullptr) {
std::lock_guard<std::mutex> lock(m_mutex);
tmp = m_instance.load(std::memory_order_relaxed);
if (tmp == nullptr) {
tmp = new Singleton;
std::atomic_thread_fence(std::memory_order_release);
m_instance.store(tmp, std::memory_order_relaxed);
}
}
return tmp;
}
//a-r语义
std::atomic<Singleton*> Singleton::m_instance;
std::mutex Singleton::m_mutex;
Singleton* Singleton::getInstance() {
Singleton* tmp = m_instance.load(std::memory_order_acquire);
if (tmp == nullptr) {
std::lock_guard<std::mutex> lock(m_mutex);
tmp = m_instance.load(std::memory_order_relaxed);
if (tmp == nullptr) {
tmp = new Singleton;
m_instance.store(tmp, std::memory_order_release);
}
}
return tmp;
}
//原子操作默认内存序:memory_order_acq_rel,它和load,store配合就包含了a-r语义
std::atomic<Singleton*> Singleton::m_instance;
std::mutex Singleton::m_mutex;
Singleton* Singleton::getInstance() {
Singleton* tmp = m_instance.load();
if (tmp == nullptr) {
std::lock_guard<std::mutex> lock(m_mutex);
tmp = m_instance.load();
if (tmp == nullptr) {
tmp = new Singleton;
m_instance.store(tmp);
}
}
return tmp;
}
参考:《并发编程的艺术》
https://en.cppreference.com/w/cpp/atomic/memory_order
https://preshing.com/20130930/double-checked-locking-is-fixed-in-cpp11/