当前位置：首页 > article >正文

C++设计模式_12_Singleton 单件模式

article 2024/11/18 23:40:52

在之前的博文C++57个入门知识点_44：单例的实现与理解中，已经详细介绍了单例模式，并且根据其中内容，单例模式已经可以在日常编码中被使用，本文将会再做梳理。
Singleton 单件模式可以说是最简单的设计模式，但由于多线程环境的双检查锁里的内存reorder的问题，实现时的细节并不简单，大家需要注意多线程环境下的安全做法。为了整体的一致性，本篇都称之为单件模式。

文章目录

1. “对象性能”模式
- 1.1 典型模式
2. 动机(Motivation)
3. Singleton 单件模式的实现版本
- 3.1 版本1：线程非安全版本
- 3.2 版本2：线程安全版本，但锁的代价过高
- 3.3 版本3：双检查锁
- 3.4 版本4：C++ 11版本之后的跨平台实现
- 3.5 总结
4. 模式定义
5. 结构
6. 要点总结
7. 其他参考

单件模式属于一个新的类别，将其归结到“对象性能”模式，该模式的简介如下：

1. “对象性能”模式

面向对象很好地解决了“抽象”的问题，但是不可避免地要付出一定的代价（虚函数(内存等代价哒)、继承）。对于通常情况来讲，面向对象的成本大都可以忽略不计。但是某些情况(倍乘效应等)，面向对象所带来的成本必须谨慎处理。

1.1 典型模式

Singleton
Flyweight

2. 动机(Motivation)

在软件系统中，经常有这样一些特殊的类，必须保证它们在系统中只存在一个实例，才能确保它们的逻辑正确性、以及良好的效率
如何绕过常规的构造器，提供一种机制来保证一个类只有一个实例?
这应该是类设计者的责任，而不是使用者的责任

3. Singleton 单件模式的实现版本

首先将构造函数和拷贝构造函数设置为私有，如果不写的话，编译器会默认生成两个公有的，让外界不能使用它们，唯一的做法就是将其设置为私有的。然后再设置静态变量，并进行静态变量的初始化。代码如下

class Singleton{
private:
    Singleton();
    Singleton(const Singleton& other);
public:
    static Singleton* getInstance();
    static Singleton* m_instance;
};

3.1 版本1：线程非安全版本

先来看第一种写法，第一次调用的时候，m_instance == nullptr成立的情况下m_instance = new Singleton();创建对象，返回m_instance，第二次调用的话，m_instance == nullptr不成立，继续返回原先的对象，这样就可以保证永远只返回第一次的对象。

//线程非安全版本
Singleton* Singleton::getInstance() {
    if (m_instance == nullptr) {
        m_instance = new Singleton();
    }
    return m_instance;
}

上述的版本会有其他问题，它在单线程下是OK的，但是多线程环境下就不行了。假设我有2个thread，threadA进到if (m_instance == nullptr)判断第一次调用，还没执行下一行，threadB假如此时得到时间片，开始执行if (m_instance == nullptr)也是成立，就会执行下一行，此时再跳回threadA，此时就会继续执行下一行，这样就会产生2个对象，因此这是线程非安全的。为了实现多线程安全如何去做呢？

3.2 版本2：线程安全版本，但锁的代价过高

第一种常见做法：加锁

//线程安全版本，但锁的代价过高
Singleton* Singleton::getInstance() {
    Lock lock; //锁的局部变量，出作用域之后消失，释放锁
    if (m_instance == nullptr) {
        m_instance = new Singleton();
    }
    return m_instance;
}

TreadA进到Lock lock;开始加锁，往下执行时，另外一个线程threadB进来，但是TreadA已经获取到锁，仍未释放，threadB就需要一直等到TreadA执行完函数释放锁。等threadB进去之后m_instance == nullptr就不成立了。

3.3 版本3：双检查锁

上一种版本实现了锁的安全，但是锁的代价太高。假如对象已经创建，那么有两个线程同时访问，threadA执行到Lock lock;,threadB是无法进入的，threadB是一个读操作，当存在多个线程的情况下，读操作是不需要加锁的。读操作是没有安全问题的，这个时候加锁对于读操作的线程是一种等待时间上的浪费。假如高并发场景下，web服务是典型高并发，10万人同时访问时，锁对于读操作代价也会是十分高的。

所以发展出一种新的实现形式，double check lock 双检查锁，之前的版本是不管什么情况，先锁，现在是if(m_instance==nullptr)先问下变量是否为空值，如果为空才加锁，如果不空就不需要加锁，直接返回即可，加完锁之后再判断是否为空。这样就在读操作时减少了时间代价。

//双检查锁，但由于内存读写reorder不安全
Singleton* Singleton::getInstance() {
    
    if(m_instance==nullptr){
        Lock lock;
        if (m_instance == nullptr) {
            m_instance = new Singleton();
        }
    }
    return m_instance;
}

有人会考虑，第二个判断if (m_instance == nullptr) 是不是可以去掉，我们假设2个线程，threadA经过第一个判断进来，然后在执行Lock lock;之前，threadB也会进来到Lock lock;之前，两个线程即使加锁也就会等一等，都会执行代码m_instance = new Singleton();，这样就会有2个对象。第二个判断就是为了放置这种情况的出现。

上面的版本看起来就是没有问题的了，也相当一段时间内迷惑了计算机领域的专家，大概2000年时才被JAVA领域的专家发现漏洞：内存读写reorder导致双检查锁的失效。

什么是reorder，正常情况下，大家看到的代码会有指令序列，那么大家通常会认为，指令序列会按照你所想象的方式执行，但是实际上整个代码到了CPU的指令层次(线程是在指令层次抢时间片)，指令和我们很多时候的假设很可能不一样。比如： m_instance = new Singleton();一般会有以下的假设，拆分成3个步骤，第一步是先分配内存，第二步是调用构造器(对分配的内存进行初始化)，第三步把内存的地址(指针)给m_instance。但是这三步是我们假想的，但是在指令级别，很可能被编译器优化reorder，在reorder之后可能就会先第一步，第三步，最后再第三步。很多研究者在不同的CPU上做实验发现很多语言都会这种现象，这样一来就有些乱套。按照可能的reorder顺序，先分配内存，直接就赋值，m_instance就不是nullptr了，构造器还没调用，另一个线程做第一次判断时发现m_instance不是nullptr，直接返回一个对象，返回的这个对象还没有经过构造器处理，其状态不对，是不可用的。

3.4 版本4：C++ 11版本之后的跨平台实现

为了解决上面的问题，java和c#语言就加了volatile的关键字来保证按照我们的想法来执行。VC++中自己也加了volatile的关键字。

C++11之后才有了这样的机制，可以帮助可以在语言层面实现跨平台的实现。

//C++ 11版本之后的跨平台实现 (volatile)
std::atomic<Singleton*> Singleton::m_instance; //声明原子对象
std::mutex Singleton::m_mutex;

Singleton* Singleton::getInstance() {
    Singleton* tmp = m_instance.load(std::memory_order_relaxed);//得到tmp指针，帮助实现屏蔽编译器的reorder
    std::atomic_thread_fence(std::memory_order_acquire);//获取内存fence，内存reorder的屏障
    //tmp就不会被reorder，底下为双检查锁的操作
    if (tmp == nullptr) {
        std::lock_guard<std::mutex> lock(m_mutex);
        tmp = m_instance.load(std::memory_order_relaxed);
        if (tmp == nullptr) {
            tmp = new Singleton;
            std::atomic_thread_fence(std::memory_order_release);//释放内存fence
            m_instance.store(tmp, std::memory_order_relaxed);
        }
    }
    return tmp;
}