C++设计模式——单例模式

最新推荐文章于 2025-02-09 10:58:50 发布

Oh-Why_not

最新推荐文章于 2025-02-09 10:58:50 发布

阅读量502

点赞数

分类专栏： C++设计模式

C++设计模式专栏收录该内容

1 篇文章

订阅专栏

本文深入探讨了单例模式的设计理念及其实现方法，包括不同场景下的线程安全问题及其解决方案。并通过四种不同的实现方式，展示了如何在C++中正确地应用单例模式，确保全局唯一实例的安全性和效率。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

<span style="font-family: 'Helvetica Neue', Helvetica, Arial, 'Hiragino Sans GB', 'Hiragino Sans GB W3', 'WenQuanYi Micro Hei', 'Microsoft YaHei UI', 'Microsoft YaHei', sans-serif; line-height: 1.8em; background-color: rgb(255, 255, 255);">全局变量在项目中是能不用就不用的，它是一个定时炸弹，是一个不安全隐患，特别是在多线程程序中，会有很多的不可预测性；同时，使用全局变量，也不符合面向对象的封装原则，所以，在纯面向对象的语言Java和C#中，就没有纯粹的全局变量。那么，如何完美的解决这个日志问题，就需要引入设计模式中的单例模式。</span>

单例模式

何为单例模式，在GOF的《设计模式：可复用面向对象软件的基础》中是这样说的：保证一个类只有一个实例，并提供一个访问它的全局访问点。首先，需要保证一个类只有一个实例；在类中，要构造一个实例，就必须调用类的构造函数，如此，为了防止在外部调用类的构造函数而构造实例，需要将构造函数的访问权限标记为protected或private；最后，需要提供要给全局访问点，就需要在类中定义一个static函数，返回在类内部唯一构造的实例。

代码实现

实现一：

#include "stdio.h"
//没有线程安全机制;
class CSingleObj1
{
public:
	static CSingleObj1 *GetInstance()
	{
		if (NULL == m_instance)
			m_instance = new CSingleObj1();
		return m_instance;
	}

	int Test(){return m_test;}

private:
	CSingleObj1(){m_test = 10;}
	~CSingleObj1(){}

	int m_test;
	static CSingleObj1 *m_instance;
};

CSingleObj1 *CSingleObj1::m_instance = NULL;

这是最简单，但是，这种实现方式，有很多问题，比如：没有考虑到多线程的问题，在多线程的情况下，就可能创建多个CSingleObj实例，以下版本是改善的版本。

实现二：

#include <iostream>
using namespace std;

class Singleton
{
public:
	static Singleton *GetInstance()
	{
		if (m_Instance == NULL )
		{
			Lock(); // C++没有直接的Lock操作，请使用其它库的Lock，比如Boost，此处仅为了说明
			if (m_Instance == NULL )
			{
				m_Instance = new Singleton ();
			}
			UnLock(); // C++没有直接的Lock操作，请使用其它库的Lock，比如Boost，此处仅为了说明
		}
		return m_Instance;
	}

	static void DestoryInstance()
	{
		if (m_Instance != NULL )
		{
			delete m_Instance;
			m_Instance = NULL ;
		}
	}

	int GetTest()
	{
		return m_Test;
	}

private:
	Singleton(){ m_Test = 0; }
	static Singleton *m_Instance;
	int m_Test;
};

Singleton *Singleton ::m_Instance = NULL;

int main(int argc , char *argv [])
{
	Singleton *singletonObj = Singleton ::GetInstance();
	cout<<singletonObj->GetTest()<<endl;
	Singleton ::DestoryInstance();

	return 0;
}

此处进行了两次m_Instance == NULL的判断，是借鉴了Java的单例模式实现时，使用的所谓的“双检锁”机制。因为进行一次加锁和解锁是需要付出对应的代价的，而进行两次判断，就可以避免多次加锁与解锁操作，同时也保证了线程安全。但是，这种实现方法在平时的项目开发中用的很好，也没有什么问题？但是，如果进行大数据的操作，加锁操作将成为一个性能的瓶颈；为此，一种新的单例模式的实现也就出现了。

实现三：

#include <iostream>
using namespace std;

class Singleton
{
public:
	static Singleton *GetInstance()
	{
		return const_cast <Singleton *>(m_Instance);
	}

	static void DestoryInstance()
	{
		if (m_Instance != NULL )
		{
			delete m_Instance;
			m_Instance = NULL ;
		}
	}

	int GetTest()
	{
		return m_Test;
	}

private:
	Singleton(){ m_Test = 10; }
	static const Singleton *m_Instance;
	int m_Test;
};

const Singleton *Singleton ::m_Instance = new Singleton();

int main(int argc , char *argv [])
{
	Singleton *singletonObj = Singleton ::GetInstance();
	cout<<singletonObj->GetTest()<<endl;
	Singleton ::DestoryInstance();
}

因为静态初始化在程序开始时，也就是进入主函数之前，由主线程以单线程方式完成了初始化，所以静态初始化实例保证了线程安全性。在性能要求比较高时，就可以使用这种方式，从而避免频繁的加锁和解锁造成的资源浪费。由于上述三种实现，都要考虑到实例的销毁，关于实例的销毁，待会在分析。由此，就出现了第四种实现方式：

实现四：

#include <iostream>
using namespace std;

class Singleton
{
public:
	static Singleton *GetInstance()
	{
		static Singleton m_Instance;
		return &m_Instance;
	}

	int GetTest()
	{
		return m_Test++;
	}

private:
	Singleton(){ m_Test = 10; };
	int m_Test;
};

int main(int argc , char *argv [])
{
	Singleton *singletonObj = Singleton ::GetInstance();
	cout<<singletonObj->GetTest()<<endl;

	singletonObj = Singleton ::GetInstance();
	cout<<singletonObj->GetTest()<<endl;
}

注意：新C++标准才支持线程安全的局部静态变量初始化，原文是这样的“That's true, as I mentioned above. It's worth noting that they won't be safe in Microsoft Visual C++ until the VS2014 release”，也就是说直到vs2014才有可能支持这个标准（C++ 11标准才引入），所以建议大家还是不要这样用比较好

实例销毁

在上述的四种方法中，除了第四种没有使用new操作符实例化对象以外，其余三种都使用了；我们一般的编程观念是，new操作是需要和delete操作进行匹配的；是的，这种观念是正确的。在上述的实现中，是添加了一个DestoryInstance的static函数，这也是最简单，最普通的处理方法了；但是，很多时候，我们是很容易忘记调用DestoryInstance函数，就像你忘记了调用delete操作一样。由于怕忘记delete操作，所以就有了智能指针；那么，在单例模型中，没有“智能单例”，该怎么办？怎么办？

那我先从实际的项目中说起吧，在实际项目中，特别是客户端开发，其实是不在乎这个实例的销毁的。因为，全局就这么一个变量，全局都要用，它的生命周期伴随着软件的生命周期，软件结束了，它也就自然而然的结束了，因为一个程序关闭之后，它会释放它占用的内存资源的，所以，也就没有所谓的内存泄漏了。但是，有以下情况，是必须需要进行实例销毁的：

在类中，有一些文件锁了，文件句柄，数据库连接等等，这些随着程序的关闭而不会立即关闭的资源，必须要在程序关闭前，进行手动释放；
具有强迫症的程序员。

以上，就是我总结的两点。

虽然，在代码实现部分的第四种方法能满足第二个条件，但是无法满足第一个条件。好了，接下来，就介绍一种方法，这种方法也是我从网上学习而来的，代码实现如下：

#include <iostream>
using namespace std;

class Singleton
{
public:
	static Singleton *GetInstance()
	{
		return m_Instance;
	}

	int GetTest()
	{
		return m_Test;
	}

private:
	Singleton(){ m_Test = 10; }
	static Singleton *m_Instance;
	int m_Test;

	// This is important
	class GC
	{
	public :
		~GC()
		{
			// We can destory all the resouce here, eg:db connector, file handle and so on
			if (m_Instance != NULL )
			{
				cout<< "Here is the test" <<endl;
				delete m_Instance;
				m_Instance = NULL ;
			}
		}
	};
	static GC gc;
};

Singleton *Singleton ::m_Instance = new Singleton();
Singleton ::GC Singleton ::gc;

int main(int argc , char *argv [])
{
	Singleton *singletonObj = Singleton ::GetInstance();
	cout<<singletonObj->GetTest()<<endl;

	return 0;
}

在程序运行结束时，系统会调用Singleton的静态成员GC的析构函数，该析构函数会进行资源的释放，而这种资源的释放方式是在程序员“不知道”的情况下进行的，而程序员不用特别的去关心，使用单例模式的代码时，不必关心资源的释放。那么这种实现方式的原理是什么呢？我剖析问题时，喜欢剖析到问题的根上去，绝不糊涂的停留在表面。由于程序在结束的时候，系统会自动析构所有的全局变量，实际上，系统也会析构所有类的静态成员变量，就像这些静态变量是全局变量一样。我们知道，静态变量和全局变量在内存中，都是存储在静态存储区的，所以在析构时，是同等对待的。

由于此处使用了一个内部GC类，而该类的作用就是用来释放资源，而这种使用技巧在C++中是广泛存在的，在后面的博客中，我会总结这一技巧，参见《C++中的RAII机制》。

注意：

Q： Singleton *Singleton ::m_Instance = new Singleton(); 何不改为 Singleton *Singleton ::m_Instance = &Singleton(); 呢？这样在Singleton类析构中释放资源不可以吗？

A：对于你说的Singleton *Singleton ::m_Instance = &Singleton();，你考虑的很周到，但是，Singleton()此处构造的是一个临时变量，会很快就会被销毁的，此处建立对象是没有意义的。你可以亲自实验一下。希望能再次和你进行讨论

Q：我想问下静态变量不是存储于静态存储区吗？它的生命周期和程序周期一样，为什么您说Singleton此处构造的是一个临时变量呢？

A：是的，你的理解没有问题。这里是一个静态变量，但是这个静态变量是一个指针，说明这个静态变量是指向一个内存区域的，如果你使用&Singleton();初始化这个静态变量时，这个静态变量的指针指向了这块内存，而Singleton()这块内存是在栈上开辟的，当出了作用域时，这块内存就被释放了，也就是说，静态的指针变量还是指向这篇内存的，而这篇内存已经无效了，这个静态指针变量已经是一个“野指针”了。这是我的理解。

转自 http://www.jellythink.com/archives/82