C++ 单例模式以及内存管理
引用:
https://zhuanlan.zhihu.com/p/37469260
https://www.cnblogs.com/xiaolincoding/p/11437231.html
https://blog.csdn.net/unonoi/article/details/121138176
单例模式:一个类在全局范围内只有一个实例化的对象
核心:
- 构造函数是私有的,防止外界创建单例类的对象。
- 使用类内的私有静态指针变量指向类的唯一实例。
- 提供一个
public
的静态方法获取该实例。
单例有两种实现方式,区别是创建实例的时间不同:
- 饿汉式(Eager Singleton):在程序运行时就初始化创建实例,直接调用即可。这种方式是天然线程安全的。坏处:提前占用系统资源!
- 懒汉式(Lazy Singleton):在首次调用get_instance()时创建实例化对象。需要考虑线程安全。
如果该类可以被继承,则构造函数应该protected修饰
饿汉式
可以看到,构造函数在main函数之前就已经执行,Singleton* Singleton::g_pSingleton = new (std::nothrow) Singleton;
中已经在编译期new instance完成构造。
class Singleton
{
private:
static Singleton instance;
private:
Singleton(); // 如果该类可以被继承,则构造函数应该protected修饰
~Singleton();
Singleton(const Singleton&);
Singleton& operator=(const Singleton&);
public:
static Singleton& getInstance() {
return instance;
}
}
// initialize defaultly
Singleton* Singleton::instance = new (std::nothrow) Singleton
然而,饿汉式确实有对应的潜在危险:
no-local static对象(函数外的static对象)在不同编译单元中的初始化顺序是未定义的。
也即,static Singleton instance;和static Singleton& getInstance()二者的初始化顺序不确定,如果在初始化完成之前调用 getInstance() 方法会返回一个未定义的实例。
懒汉式
Step1:普通非线程安全
class Singleton
{
private:
static Singleton* instance;
private:
Singleton() {}; // 如果该类可以被继承,则构造函数应该protected修饰
~Singleton() {};
Singleton(const Singleton&); // 拷贝构造
Singleton& operator=(const Singleton&); // 赋值构造
public:
static Singleton* getInstance()
{
if (instance == NULL)
instance = new Singleton();
return instance;
}
};
Singleton* Singleton::instance = NULL;
对于以上代码,显然多个线程对于if(instance == NULL)
判断与修改是非原子的,可能出现冲突。
而在实际的实验中,对于线程不安全的情况(普通懒汉),的确观察到了多个构造函数,且内存地址不同的情况,说明多线程并发的race condition创建了多个对象,与单例不符。
Step2:线程安全
针对以上问题,一个容易想到的解决方案是加锁,保护共享的instance
免受冲突。
这里使用双检锁(DCL: Double-Checked Locking Pattern)来实现。
双检锁的好处在于:由于只有首次初始化才上锁,因此最外层仅用于判断是否获取instance成功。在构造完成后就没有可能再次进入本层循环内部,避免了每一次访问getInstance()都需要加锁。
class Singleton
{
private:
static Singleton* instance;
static std::mutex m_Mutex;
private:
Singleton() {}; // 如果该类可以被继承,则构造函数应该protected修饰
~Singleton() {};
Singleton(const Singleton&);
Singleton& operator=(const Singleton&);
public:
static Singleton* getInstance()
{
if (instance == NULL)
{
std::unique_lock<std::mutex> lock(m_Mutex); // 加锁
if (instance == NULL)
{
instance = new (std::nothrow) Singleton;
}
}
return instance;
}
};
//初始化静态成员变量
SingleInstance *SingleInstance::m_SingleInstance = NULL;
std::mutex SingleInstance::m_Mutex;
Step2.5:强化的线程安全
本篇文章中提出了一个问题,获取到的非空instance对象可能会出现部分构造问题。
因此,提出了使用atomic的原子量操作方案,个人认为依赖于内存模型,由于编译优化,现代CPU的指令流水线重排以及乱序执行,缓存等各种影响因素,不排除有此种可能性。
虽然个人认为这依赖于具体编译器的实现,并且几乎不会出现,但是理论上的确有可能出现这样的问题。
或许也可以加一个volatile关键字来限制一下,但仍然没有完全排除可能性。
代码如下:
atomic<Widget*> Widget::pInstance{ nullptr };
Widget* Widget::Instance() {
if (pInstance == nullptr) {
lock_guard<mutex> lock{ mutW };
if (pInstance == nullptr) {
pInstance = new Widget();
}
}
return pInstance;
}
Step3:优雅的线程安全
C++ 11规定了local static在多线程条件下的初始化行为(g++ 03中已经显式说明),要求编译器保证了内部静态变量的线程安全性。
参见: https://stackoverflow.com/questions/449436/singleton-instance-declared-as-static-variable-of-getinstance-method-is-it-thre
因此,最为优雅的单例写法(Meyers' Singleton):
class Singleton
{
private:
Singleton() { }; // 如果该类可以被继承,则构造函数应该protected修饰
~Singleton() { };
Singleton(const Singleton&);
Singleton& operator=(const Singleton&);
public:
static Singleton& getInstance()
{
static Singleton instance; // 核心改进,首次访问才会被初始化
return instance;
}
};
Singleton* Singleton::instance = NULL;
可能的内存释放问题
手动释放:delete Singleton::get_instance();
自动释放:
引用: https://blog.csdn.net/linuxwuj/article/details/81187564
进程结束时,静态对象的生命周期随之结束,其析构函数会被调用来释放对象。因此,我们可以利用这一特性,在单例类中声明一个内嵌类,该类的析构函数专门用来释放new出来的单例对象,并声明一个该类类型的static对象
class Singleton {
public:
// ...
private:
// ...
static Singleton * instance;
class GarbageCollector {
public:
~GarbageCollector() {
if (Singleton::instance) {
delete Singleton::instance;
Singleton::instance = 0;
}
}
};
static GarbageCollector gc;
};
// 定义
Singleton::GarbargeCollector Singleton::gc;
// ...
注意static GarbageCollector gc;
这一个位置,我们定义了一个内部的嵌套类GarbageCollector,并且使用static
修饰。
此处需要注意:类的静态成员需要在类外部进行初始化,所以一定要在类的最外部初始化Singleton::GarbargeCollector Singleton::gc;
。
否则静态成员GarbageCollector gc
根本就没有在任何位置被调用初始化,其析构函数也就无从谈及被调用。
此外,针对内存管理,智能指针也是一个值得考虑的方案,不如说尽量去使用智能指针。