多线程中局部静态变量初始化的陷阱

最新推荐文章于 2024-02-11 18:48:30 发布

ewigkeit

最新推荐文章于 2024-02-11 18:48:30 发布

阅读量1.8k

点赞数

文章标签：多线程 java null 语言 c

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会是一个好的选择。