关于c ++：Meyers对Singleton模式线程的实现是否安全？

Is Meyers' implementation of the Singleton pattern thread safe?

使用延迟初始化的Singleton线程(meyers'singleton)的以下实现是否安全？

1
2
3
4
5

static Singleton& instance()
{
static Singleton s;
return s;
}

如果不是，为什么和如何使它线程安全？

要回答为什么它不是threadsafe的问题，并不是因为对instance()的第一个调用必须调用Singleton s的构造函数。要实现线程安全，这必须发生在关键部分，但标准中没有要求采用关键部分(迄今为止的标准对线程是完全无所谓的)。编译器通常使用静态布尔值的简单检查和增量来实现这一点——但不是在关键部分。类似于以下伪代码：

1
2
3
4
5
6
7
8
9
10
11
12
13

static Singleton& instance()
{
static bool initialized = false;
static char s[sizeof( Singleton)];

if (!initialized) {
initialized = true;

new( &s) Singleton(); // call placement new on s to construct it
}

return (*(reinterpret_cast<Singleton*>( &s)));
}

所以这里有一个简单的线程安全单例(对于Windows)。它为Windows关键部分对象使用了一个简单的类包装器，这样我们就可以让编译器在调用main()之前自动初始化CRITICAL_SECTION。理想情况下，将使用一个真正的raii critical section类，它可以处理在持有critical section时可能发生的异常，但这超出了此答案的范围。

基本操作是，当请求Singleton的一个实例时，取一个锁，如果需要，则创建singleton，然后释放锁并返回singleton引用。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54

#include <windows.h>

class CritSection : public CRITICAL_SECTION
{
public:
CritSection() {
InitializeCriticalSection( this);
}

~CritSection() {
DeleteCriticalSection( this);
}

private:
// disable copy and assignment of CritSection
CritSection( CritSection const&);
CritSection& operator=( CritSection const&);
};

class Singleton
{
public:
static Singleton& instance();

private:
// don't allow public construct/destruct
Singleton();
~Singleton();
// disable copy & assignment
Singleton( Singleton const&);
Singleton& operator=( Singleton const&);

static CritSection instance_lock;
};

CritSection Singleton::instance_lock; // definition for Singleton's lock
// it's initialized before main() is called

Singleton::Singleton()
{
}

Singleton& Singleton::instance()
{
// check to see if we need to create the Singleton
EnterCriticalSection( &instance_lock);
static Singleton s;
LeaveCriticalSection( &instance_lock);

return s;
}

伙计-那是"让全球变得更好"的一堆废话。

这个实现的主要缺点(如果我不让一些错误溜走的话)是：

如果new Singleton()抛出，锁将不会被释放。这可以通过使用一个真正的raii锁对象而不是我这里的简单对象来解决。如果您使用Boost之类的工具来为锁提供一个独立于平台的包装器，那么这也可以帮助实现可移植性。
当调用main()之后请求单例实例时，这就保证了线程的安全性—如果在此之前调用它(如在静态对象的初始化中)，则由于CRITICAL_SECTION可能未初始化，因此事情可能不起作用。
每次请求实例时都必须使用锁。正如我所说，这是一个简单的线程安全实现。如果你需要一个更好的(或者想知道为什么像双重检查锁技术这样的技术有缺陷)，请参阅格罗的答案中链接到的文件。