C++当中常常需要一个全局唯一的对象实例,这时候,我们就会想到单件模式。如何实现这一模式?全局变量当然是一个简单可行的方法,然而,这太丑陋。嗯,其实,丑陋倒也罢了,最严重的是它将引诱程序员滥用全局变量,这将导致维护的灾难。
既然全局变量是可能有害的,那么,我们我们把它隐藏一下,放到某个类当中去,作为类的静态数据成员。这看上去不错,我也这么认为。当我们只是简单的需要一个全局对象时,这很好,而且足够简单。不过,天空中尚有一朵小小的乌云,让我们来看一看它是什么。
静态成员变量的初始化,和全局对象一样,实际上实在main函数进入后,我们写下的一行代码之前被执行的。而且,我们知道那个著名的初始化顺序是不可靠的问题(跨编译单元)。当我的全局对象是一个复杂对象――这很常见,比如一个环境管理器――它甚至还需要复杂的装配过程,我们需要考虑:构建这个单件的时候,其对象都准备好了吗?如果我们不能确定,那么一个常见的措施是延迟单件对象的构造――把它延迟到全局对象初始化结束以后怎么样?这好像很容易实现:
SomeClass * SomeClass ::instance(){
static SomeClass inst;
return &inst;
}
不错吧?它不但可以延迟到全局对象初始化之后,甚至可以延迟到有人需要它的时候,才被构造出来,随需应变,呵呵,是不是很帅?嗯,还有一点小问题,不仅存在对象初始化顺序问题,析构也同样存在问题。局部静态变量的析构,和全局对象一样,实在main函数退出前进行的,如果也要考虑顺序问题的话...是不是有点麻烦呢?
过度设计是一种罪,我是不是考虑的太复杂了?如果压根就不需要考虑析构顺序,这是不是很完美的解决方案?没那么简单!非但不够完美,而且,这里面仍然存在缺陷:当我们运行在多线程环境的时候,静态变量的初始化来实现单件,是不可靠的――直接的说,静态变量有可能初始化多次!在作实验之前,我们现分析一下静态局部变量的实现方式,下面是前面instance实现的伪码:
if (!initialized){
initialized = true;
new (&inst)SomeClass;
}
return &inst;
每个静态变量都会拥有自己的初始化与否的标志,静态变量初始化并不是一个原子操作,也没有为多线程而设立互斥区(C++语言本身是没有线程概念的),因此,我们要想实现多线程下的单件延迟创建,就不得不解决重复初始化的问题。至于如何实现,实际上这方面的代码很多了。一个显然的方案是设立互斥区,传统的双检测技术可以有效解决这一问题――至少目前的C++是这样,至于最近在csdn看到在Java中双检测失效的文章,我认为应该由Java语言负责。
其实,局部静态变量可能多次初始化,并不难理解,实践上,也很少出严重的问题――出问题的条件还是挺苛刻的:多线程,不可多次初始化,恰好多个线程同时调用,恰好在if之后发生线程调度。很少出问题,不等于不出问题,特别的,对于广泛使用的应用程序来说,出错概率就不是一点点了。写这篇东西的原因,是今天在公司看到的一段代码,作了标识符替换:
SomeClass * SomeClass::GetInstance(){
static CLock g_lock;
if (m_pInstance == NULL){
g_lock.Lock();
if (m_pInstance == NULL){
m_pInstance = new SomeClass;
}
g_lock.Unlock();
}
return m_pInstance;
}
就这段代码,虽然知道用双检测,且不说Lock/Unlock可以更好的处理,static CLock g_lock根本就是错误。锁本身可能被初始化多次,象这种资源类型的对象,多次构造几乎肯定会出错的。而对于单件模式的实现,我认为,一般而言,Loki:: SingletonHolder会是一个好的选择。