细说Singleton模式:创建、多线程与销毁

开发 后端
本文对Singleton模式进行了一番简略的介绍,主要参考了GOF著作中对Singleton的描述。GOF著作中对Singleton模式的描述为:保证一个class只有一个实体(Instance),并为它提供一个全局访问点(global access point)。

GOF著作中对Singleton模式的描述为:保证一个class只有一个实体(Instance),并为它提供一个全局访问点(global access point)。

从其描述来看,是非常简单的,但实现该模式却是复杂的。Singleton设计模式不存在一种所谓的“***”方案。需要根据当时的具体问题进行具体解决,下面将讲述在不同环境下的解决方案。

Singleton的详细解释,请大家看GOF的著作《设计模式》一书。俺比较懒,是不想抄了。

1         Singleton创建

1.1      GOF Singleton

在GOF著作中对Singleton模式的实现方式如下:

  1. /*解一*/   
  2. class Singleton   
  3. {   
  4. public:   
  5. static Singleton *Instance(){                            //1   
  6. if( !m_pInstatnce) //2   
  7. m_pInstance = new Singleton;//3   
  8. return m_pInstance; //4   
  9. }   
  10. private:   
  11. static Singleton *m_pInstatnce;             //5   
  12. private:   
  13. Singleton();                                                         //6   
  14. Singleton(const Singleton&);                             //7   
  15. Singleton& operator=(const Singleton&);            //8   
  16. ~Singleton();                                                       //9   
  17. }   
  18. Singleton *Singleton:m_pInstatnce = NULL; //10   
  19.  

在上面的解决方案中,我们只在需要调用时,才产生一个Singleton的对象。这样带来的好处是,如果该对象产生带来的结果很昂贵,但不经常用到时,是一种非常好的策略。但如果该Instance被频繁调用,那么就有人觉得Instance中的判断降低了效率(虽然只是一个判断语句^_^),那么我们就把第5条语句该为

  1. static Singleton m_Instatnce;  

如此一来,在Instatnce直接返回&m_Instance,而不用做任何判断,效率也高了。(是不是呢?)

这样修改后,我们将带来灾难性的后果:

1:首先有可能编译器这关就没法通过,说m_Instance该外部变量无法解决(visural C++6.0)

  1. error LNK2001: unresolved external symbol "private: static class Singleton  Singleton::m_Instance" (?m_Instance@Singleton@@0V1@A)  

2:如果编译器这关通过了就没问题了么?答案是否定的。

***是不管Instance是否用到,该静态变量对象在编译器编译时就产生了,即资源消耗是不可避免的;

第二是无法确保编译器一定先将m_Instance初始化。所以Instance的调用有可能传回一个尚没构造的Singleton对象。这也意味着你无法保证任何外部对象所使用的m_Instance是一个被正确初始化的对象。

1.2      Meyers Singleton
我们如何解决这个问题呢,实际上很简单。一种非常优雅的做法由Scott Meyers***提出,故也称为Meyers Singleton。它依赖编译器的神奇技巧。即函数内的static对象只在该函数***次执行时才初始化(请注意不是static常量)。

  1. /*解二*/   
  2. class Singleton   
  3. {   
  4. public:   
  5. static Singleton *Instance(){                            //1   
  6. static Singleton sInstance; //2   
  7. return &sInstance; //3   
  8. }   
  9. private:   
  10. Singleton();                                                         //4   
  11. Singleton(const Singleton&);                             //5   
  12. Singleton& operator=(const Singleton&);            //6   
  13. ~Singleton();                                                       //7   
  14. }   
  15.  

解二在Instance中定义了一个Static的Singleton对象,来解决Instance中初始化的问题,也很顺利的解决了定义Static成员对象带来的问题。

请注意,解二在VC6中不能编译通过,将有以下的错误:

  1. error C2248: 'Singleton::~Singleton' : cannot access private member declared in class 'Singleton' e:\work\q\a.h(81) : see declaration of 'Singleton::~Singleton'  

产生该问题的错误原因是什么呢(请仔细思考^_^)

原因在于在产生static Singleton对象后,编译器会自动产生一个销毁函数__DestroySingleton,然后调用atexit()注册,在程序退出时执行__DestroySingleton。但由于Singleton的析构函数是private,所以会产生访问错误。(应该在以后的编译器中修改了该BUG)

1.3      Singleton改进

让Instance传回引用(reference)。如果传回指针,调用端有可能讲它delete调。

1.4      Singleton注意之点

在上面的解法中,请注意对构造函数和析构函数的处理,有何好处(请自己理解,俺懒病又犯了)。

2         多线程

在解一中,如果我们运行在多线程的环境中,该方案是***的么,将会有什么后果呢?

后果就是会造成内存泄漏,并且有可能前后获取的Singleton对象不一样(原因请自己思考,后面有解答)。

为了解决这个问题,将解一的Instance改为如下:

  1. Singleton& Singleton::Instance(){   
  2. Lock(m_mutex);            //含义为获取互斥量            //1   
  3. If( !m_pInstance ){                                          //2   
  4. m_pInstance = new Singleton; //3   
  5. }   
  6. UnLock(m_mutex);                                            //4   
  7. return *m_pInstance;                                     //5   
  8. }   
  9.  

此种方法将解决解一运行在多线程环境下内存泄漏的问题,但带来的结果是,当m_mutex被锁定时,其它试图锁定m_mutex的线程都将必须等等。并且每次执行锁操作其付出的代价极大,亦即是这种方案的解决办法并不吸引人。

那么我们将上面的代码改为如下方式:

  1. Singleton& Singleton::Instance(){   
  2. If( !m_pInstance ){                                                      //1   
  3. Lock(m_mutex); //含义为获取互斥量 //2   
  4. m_pInstance = new Singleton; //3   
  5. UnLock(m_mutex); //4   
  6. }   
  7. return *m_pInstance;                                                 //5   
  8. }   
  9.  

这样修改的结果没有问题了么?NO!!!!该方案带来的结果同解一,原因也一样,都将造成内存泄漏。此时“双检测锁定”模式就粉墨登场了。

由Doug Schmidt和Tim Harrison提出了“双检测锁定”(Double-Checked Locking)模式来解决multithread singletons问题。

  1. Singleton& Singleton::Instance(){   
  2. If( !m_pInstance ){                                                      //1   
  3. Lock(m_mutex); //含义为获取互斥量 //2   
  4. If(!m_pInstance) //3   
  5. m_pInstance = new Singleton; //4   
  6. UnLock(m_mutex); //5   
  7. }   
  8. return *m_pInstance;                                                 //6   
  9. }  

请看上面的第三句,这句话是不是具有化腐朽为神奇的力量啊 ^_^

上面的方案就***了么。回答还是NO!!!(各位看官是否已经郁闷了啊,这不是玩我啊?请耐心点,听我细细到来^_^)

如果在RISC机器上编译器有可能将上面的代码优化,在锁定m_mutex前执行第3句。这是完全有可能的,因为***句和第3句一样,根据代码优化原则是可以这样处理的。这样一来,我们引以为自豪的“双检测锁定”居然没有起作用( L)

怎么办?解决呗。怎么解决?简单,我们在m_pInstance前面加一个修饰符就可以了。什么修饰符呢?……

àvolatile(简单吧)

那么我们完整的解法如下:

  1. /*解三*/   
  2. class Singleton   
  3. {   
  4. public:   
  5. static Singleton &Instance(){                            //1   
  6. if( !m_pInstatnce){ //2   
  7. Lock(m_mutex) //3   
  8. If( !m_pInstance ) //4   
  9. m_pInstance = new Singleton;//5   
  10. UnLock(m_mutex); //6   
  11. }   
  12. return *m_pInstance; //7   
  13. }   
  14. private:   
  15. static volatitle Singleton *m_pInstatnce;            //8   
  16. private:   
  17. Singleton();                                                         //9   
  18. Singleton(const Singleton&);                             //10   
  19. Singleton& operator=(const Singleton&);            //11   
  20. ~Singleton();                                                       //12   
  21. }   
  22. Singleton *Singleton:m_pInstatnce = NULL; //13   
  23.  

3         Singleton销毁

在这里,我们就到了Singleton最简单也最复杂的地方了。

为什么说它简单?我们根本可以不理睬创建的对象m_pInstance的销毁啊。因为虽然我们一直没有将Singleton对象删除,但不会造成内存泄漏。为什么这样说呢?因为只有当你分配了累积行数据并丢失了对他的所有reference是,内存泄漏才发生。而对Singleton并不属于上面的情况,没有累积性的东东,而且直到结束我们还有它的引用。在现代操作系统中,当一个进程结束后,将自动将该进程所有内存空间完全释放。(可以参考《effective C++》条款10,里面讲述了内存泄漏)。

但有时泄漏还是存在的,那是什么呢?就是资源泄漏。比如说如果该Singleton对象管理的是网络连接,OS互斥量,进程通信的handles等等。这时我们就必须考虑到Singleton的销毁了。谈到销毁,那可是一个复杂的课题(两天三夜也说不完^_^  开玩笑的啦,大家轻松一下嘛)。

我们需要在恰当的地点,恰当的时机删除Singleton对象,并且还要在恰当的时机创建或者重新创建Singleton对象。

在我们的“解二”中,在程序结束时会自动调用Singleton的析构函数,那么也将自动释放所获取的资源。在大多数情况下,它都能够有效运作。那特殊情况是什么呢?

我们以KDL(keyboard,display,log)模型为例,其中K,D,L均使用Singleton模式。只要keyboard或者display出现异常,我们就必须调用log将其写入日志中,否则log对象不应该创建。对后面一条,我们的Singleton创建时就可以满足。

在前面我们已经说到,在产生一个对象时(非用new产生的对象),由编译器自动调用了atexit(__DestroyObject)函数来实现该对象的析构操作。而C++对象析构是LIFO进行的,即先产生的对象后摧毁。

如果在一般情况下调用了log对象,然后开始销毁对象。按照“后创建的先销毁”原则:log对象将被销毁,然后display对象开始销毁。此时display在销毁发现出现异常,于是调用log对象进行记录。但事实上,log对象已经被销毁,那么调用log对象将产生不可预期的后果,此问题我们称为Dead Reference。所以前面的解决方案不能解决目前我们遇到的问题。

Andrei Alexandrescu提出了解决方案,称为Phoenix Singleton(取自凤凰涅磐典故)

  1. /*解四*/   
  2. class Singleton   
  3. {   
  4. public:   
  5. static Singleton &Instance(){                              
  6. if( !m_pInstatnce){   
  7. Lock(m_mutex)   
  8. If( !m_pInstance ){   
  9. if(m_destroyed)   
  10. OnDeadReference();   
  11. else   
  12. Create();   
  13. }   
  14. UnLock(m_mutex);   
  15. }   
  16. return *m_pInstance;   
  17. }   
  18. private:   
  19. static volatitle Singleton *m_pInstatnce;   
  20. static bool m_destroyed;   
  21. private:   
  22. Singleton();                                                           
  23. Singleton(const Singleton&);                               
  24. Singleton& operator=(const Singleton&);       
  25. ~Singleton(){   
  26. m_pInstance = 0;   
  27. m_destroyed = true;   
  28. }   
  29. static void Create(){   
  30. static Singleton sInstance;   
  31. m_pInstanace = &sInstance;   
  32. }   
  33. static void OnDeadReference(){   
  34. Create();   
  35. new (m_pInstance) Singleton;   
  36. atexit(KillPhoenixSingleton);   
  37. m_destroyed = false;   
  38. }   
  39. void KillPhoenixSingleton(){   
  40. m_pInstance->~Singleton();   
  41. }   
  42. }   
  43. Singleton *Singleton:m_pInstatnce = NULL;   
  44. bool m_destroyed =false;    
  45.  

请注意此处OnDeadReference()中所使用的new操作符的用法:是所谓的placement new操作,它并不分配内存,而是在某个地址上构造一个新对象。

这是解决Dead Reference方法之一。如果此时keyboard或者display对象也需要处理Dead Reference问题时,那么上面的OnDeadReference将被频繁调用,效率将会很低。即该问题为:需要提供一种解决方案,用于处理对象的建立过程可以不按照“先创建会销毁”的原则,而应该为其指定一个销毁顺序。

聪明的Andrei Alexandrescu提出了一个“带寿命的Singleton”解决方案。该方案的思想是:利用atexit()的特性;在每次创建一个对象后,将该对象放入到一个链表中(该链表是按照销毁顺序排训的),并同时调用atexit()注册一个销毁函数;该销毁函数从链表中获取最需要销毁的对象进行销毁。(懒病又犯了L。该模式的实现请各位看官自行实现,可以参考《C++设计新思维》一书,Andrei Alexandrescu著)。

各位看官,看完本篇后,是否觉得Singleton还简单啦 :)

【编辑推荐】

  1. 有关双检测锁定(DCL)和Singleton模式的问题
  2. 最简单的设计模式学习:Singleton模式
  3. C# Singleton的使用及优缺点探讨
  4. 详解Java Singleton模式的好处
  5. Scala程序中的分号推断和Singleton对象
责任编辑:yangsai 来源: CSDN
相关推荐

2013-05-23 15:59:00

线程池

2023-06-06 08:17:52

多线程编程Thread类

2010-03-15 17:56:23

Java多线程

2010-02-01 17:18:23

Python多线程环境

2009-08-31 16:12:02

C#使用Singlet

2009-06-29 17:54:10

Java多线程Thread类创建线程

2021-02-25 15:58:46

C++线程编程开发技术

2009-06-29 18:00:05

Java多线程Runnable接口创建线程

2010-03-10 08:54:49

Python多线程

2011-11-18 10:50:25

设计模式Java线程

2009-07-09 17:30:59

Singleton模式C++ SingletJava Single

2009-08-25 18:04:30

C#实现Singlet

2009-08-31 15:48:02

C# Singleto

2009-07-08 17:25:05

Java Single

2009-09-02 16:23:27

C# Singleto

2022-05-20 10:20:17

Spring事务MyBatis

2022-05-26 08:31:41

线程Java线程与进程

2012-08-22 10:10:25

单态单态设计设计模式

2011-07-18 16:51:51

Cocoa 单态 模式

2012-01-13 12:57:48

Java
点赞
收藏

51CTO技术栈公众号