在众多的设计模式中,singleton(单件或者单例)绝对是另类的一个。在实现单件的过程中,我深深体会到了“细节是魔鬼”的道理。在看似一览无遗的湖面下,尼斯湖水怪的阴影却屡驱不散。
初识单件是在GoF的设计模式经典著作里面。GoF给出的定义很简单:让一个类只有一个实例,并为实例提供一个全局访问点。而且类图里面只有一个类。太简单了,顿时有种手到擒来的飘飘然。现在回想起来,当时学习设计模式有问题,太注重类图和实现,反倒把应用场景和优缺点忽略了。结果走了不少弯路。
于是,真到要用的时候,赶紧祭出单件(代码如下),还颇引以为傲的介绍为什么Instance要返回引用,而不是指针。引用可以告诫使用者这个对象不应该删除,也不应该保存起来。不过,不应该跟不能还是有区别的,可以把引用转成指针后,删除或者保存。
class Singleton
{
private:
Singleton();
~Singleton();
Singleton(const Singleton & rhs);
Singleton & operator=(const Singleton & rhs);
public:
static Singleton & Instance()
{
if (<span style="font-family: Arial, Helvetica, sans-serif;">m_Instance == NULL</span><span style="font-family: Arial, Helvetica, sans-serif;">)</span>
{
m_Instance = new Singleton();
}
return m_Instance;
}
private:
static Singleton * m_Instance;
public:
void OtherMethod();
};
乍一看,有点被漂亮的OO方法闪花了眼。讨厌的全局变量用OO包裹了起来,变成了一个类的私有静态变量。别人看不到它,只能通过该类的公有静态方法访问。这又一次证明了软件的所有问题都可以用增加中间层解决。但是,没高兴一会儿,尼斯湖水怪就浮出水面了。
首先,多线程下是不安全的,有内存漏泄的风险。当m_Instance还没new时,线程A先调用Singleton::Instance(),正要new时,切换到线程B,线程B发现m_Instance是空的,索性就new了一个。切回到线程A后,线程A又多new了一个。这是典型的竞争条件,闪过脑海的第一个方法就是加锁。
<span style="font-family: Arial, Helvetica, sans-serif;">Singleton</span><span style="font-family: Arial, Helvetica, sans-serif;"> & </span><span style="font-family: Arial, Helvetica, sans-serif;">Singleton::</span><span style="font-family: Arial, Helvetica, sans-serif;">Instance()</span>
{
<span style="white-space:pre"> </span>Lock guard; // Lock类构造时take信号量,析构时give信号量
<span style="white-space:pre"> </span>if (<span style="font-family: Arial, Helvetica, sans-serif;">m_Instance == NULL</span><span style="font-family: Arial, Helvetica, sans-serif;">)</span>
<span style="white-space:pre"> </span>{
<span style="white-space:pre"> </span>m_Instance = new Singleton();
<span style="white-space:pre"> </span>}
<span style="white-space:pre"> </span>return m_Instance;
}
但是这招杀伤力太大,当m_Instance是空的时候,还行。当m_Instance已经new出来了,还加锁就得不偿失了。于是,坊间又流传出双重检测锁定模式(Double Check Locking Pattern):
<span style="font-family: Arial, Helvetica, sans-serif;">Singleton</span><span style="font-family: Arial, Helvetica, sans-serif;"> & </span><span style="font-family: Arial, Helvetica, sans-serif;">Singleton::</span><span style="font-family: Arial, Helvetica, sans-serif;">Instance()</span>
{
if (m_Instance == NULL) // 第一次检测
{
Lock guard;
if (m_Instance == NULL) // 第二次检测
{
m_Instance = new Singleton();
}
}
return m_Instance;
}
第一次检测是粗略的检测,这可以排除掉m_Instance已经new的情况,此时就不用加锁了。第二次检测是精确的检测,这次是发生在m_Instance还是空的情况下,这就要加锁互斥了。不过,
Andrei Alexandrescu在《Modern C++ Design》中指出因为RISC指令重排,这也不一定是线程安全的,所以除了在m_Instance前加上volatile之外,还要加上第三次检测,查阅编译器手册看看怎么消除这种情况。
有些复杂,对吧?再回头想想,Instance()把初始化和运行时查询放在了一起,有点不符合单一职责原则。如果把这两个处理拆分开,就不会有问题了。可以把m_Instance定义成Singleton的静态对象,而不是指针,就不需要new了。但是C++中静态对象有两种:非局部静态变量(全局变量/类静态变量)和局部静态变量,你还得选(知道杨朱为啥泣岐了吧)。两者的实现方式不同:前者在类定义中把m_Instance改成静态对象:
static Singleton m_Instance;
后者则干脆不要成员变量,而把m_Instance放在Instance()函数中:
<span style="font-family: Arial, Helvetica, sans-serif;">Singleton</span><span style="font-family: Arial, Helvetica, sans-serif;"> & </span><span style="font-family: Arial, Helvetica, sans-serif;">Singleton::</span><span style="font-family: Arial, Helvetica, sans-serif;">Instance()</span>
{
static Singleton s_Instane;
return s_Instance;
}
两者的初始化时机不同:前者是在main()函数执行之前初始化的,由于不同编译单元的非局部静态变量的初始化顺序未定义,如果涉及静态变量之间的依赖,这个方案不可行。
后者是第一次调用Instance()时初始化,伪代码如下:
Singleton & Singleton::Instance()
{
<span style="white-space:pre"> </span>extern void __DestroySingleton();
<span style="white-space:pre"> </span>static bool __is_instance_inited = false;
<span style="white-space:pre"> </span>static char __buffer[sizeof(Singleton)];
<span style="white-space:pre"> </span>if (!__is_instance_inited)
<span style="white-space:pre"> </span>{
<span style="white-space:pre"> </span>new(__buffer) Singleton; // placement new
<span style="white-space:pre"> </span>__is_instance_inited = true;
<span style="white-space:pre"> </span>atexit(__DestroySingleton);
<span style="white-space:pre"> </span>}
<span style="white-space:pre"> </span>return *reinterpret_cast<Singleton *>(__buffer);
}
void __DestroySingleton()
{
<span style="white-space:pre"> </span>reinterpret_cast<Singleton *>(__buffer)->~Singleton();
}
后者相当于把判断s_Instance是否构造的判断留给编译器实现,所以可能会出现多个线程调用多次构造函数的情况,因为用的是placement new,不会new多个对象。
除了把指针改成对象,还可以在成员函数上做文章,比如可以再定义一个全局变量来强制Instance()函数在初始化时调用:
Singleton & force_init = Singleton::Instance();
又比如,专门增加一个初始化接口:
void Singleton::Create()
{
Lock guard;
if (m_Instance == NULL)
{
m_Instance = new Singleton;
}
}
static Singleton & Instance()
{
return m_Instance;
}
初始化一般是在单线程环境下完成的,所以Create()甚至可以把锁去掉。
说了这么多,到底应该用哪个方案呢?答曰:依实际场景而定。如果没有静态变量的依赖,构造开销很小,而且生命周期无限,可以用静态成员对象。
另一个让我头疼的问题是单件代码的复用。
收益能超过成本吗?
单件的优点如下:
1、对类实例化的控制。能确保只有一个实例。这点全局变量做不到,但是,既然有一个全局变量,谁还会去new一个新的对象呢?
2、延迟求值。这需要一点技巧。上面的代码就是一个很好的例子,把实例化推迟到第一次调用Instance()的地方。但并不是所有单件都能延迟实例化,比如,下面这样实现就不能延迟求值。
class Singleton
{
public:
static Singleton & Instance()
{
return m_Singleton;
}
private:
static Singleton m_Singleton;
};
全局变量能不能做到呢?可以,但不是很完美,因为不知道第一次访问全局变量的确切时间,可能出现访问全局变量的时候,全局变量还没有初始化。
3、对类的初始化顺序的控制。毕竟把全局变量的访问点封闭到函数里面了,在函数体内部可以做任何事件,比如把依赖的对象都给初始化了,再初始化自己。全局变量对此爱莫能助。
4、提供优雅的访问接口。至少从形式上,看上去很符合OO的要求。
5、内聚比较高。如果是全局变量,初始化和访问点是分离的。Bob大叔在《Clean Code》里面提到类的内聚性的一个衡量标准:类的成员变量被越多的类方法访问,类的内聚性就越高。从这一点看,单件的内聚性不是很高,因为m_Singleton只被Instance()访问。
单件的缺点:
1、很难抽象化。其它的设计模式,比如观察者模式,只需要定义一个接口类,然后以此为起点,派生出实现类就行了。如果定义一个Singleton的抽象类S,然后把想到单件化的类D继承自S,类D是不是单件呢?显然不是。但是在《Modern C++ Design》一书中,Andrei Alexandrescu介绍了用模板实现单件基类,然后把具体类的类名,构造方法和生命周期管理方法通过模板参数引入模板基类中。他用了整整一章的篇幅详细的介绍单件,说明什么?单件的技巧性很高,有点像拿着杆子走钢丝。模板化的单件有一个限制,代码共享只能基于源代码级别的共享,而不能基于二进制级别。于是模板化的单件更多的是模块内部使用,很少作为DLL的接口。
2、很难继承,Singleton的子类很难也是Singleton。或者说技巧性也很高。首先要把父类的构造函数改为protected,允许子类调用。这样父类其实就不是单件了。而且会产生反向依赖,即父类要看到子类,在C++中,由于protected方法的单向性(父类不能访问子类的protected方法),父类还必须是子类的友元。
3、违反了Single Responsibility原则。有人甚至认为单件是反模式。我觉得单件从某种程度上,违反了基于接口编程。
4、效率问题。在多线程环境中,尽管有double checked技术,但是每次Instance调用还是有至少一次的if判断。
5、析构问题。这个问题跟使用全局变量一样,你永远不知道有谁还抓着Singleton引用不放。当然可以加上引用计数,但是你不觉得太复杂了吗?
说了这么多,到底该不该单件呢?这是菜鸟喜欢问的问题。高手一般这么问:应该在什么场景下使用单件呢?知道差距了吧。没有一个设计模式是放之四海皆准的,不然也不会有这么多的设计模式了。存在即是合理的。单件也有它特定的应用场景。就像辣椒酱一样,你不会所有菜里面都会放吧。
我觉得单件应该受限使用,毕竟单件说白了,也是访问全局变量。如果在代码中大量使用单件,也就是说,大量使用全局变量。这是一种设计的坏味道。这时候,你需要回过头来,想想设计有没有问题?类的职责划分有没有问题?没有吗?真的没有吗?再想想。
那么,单件的替代方案是什么呢?我想有两个:
1、MONOSTATE模式。把类的所有成员变量定义成静态成员变量,不也就是单件了吗?有趣吧。这个模式最有趣的地方是访问者根本不知道MONOSTATE类是单件。
2、依赖倒置,也有人叫依赖注入。比如,A类要访问B类的接口,在A类中定义一个B类的对象指针和一个Set接口,然后由第三方的工厂对象把B类的实例(或者是B的子类的实例)构造出来,再通过A类的Set接口,把B类的实例注入到A类中。