C++单例模式

面向对象很好地解决了“抽象”的问题,但是为此总是需要付出一些代价,比如说虚函数。对于通常情况来讲,面向对象的成本大都可以忽略不计。但是某些情况,面向对象所带来的成本必须谨慎处理。

动机

在软件系统中,经常有这样一些特殊的雷,必须保证他们在系统中只存在一个实例,才能确保它们的逻辑正确性、以及良好的效率。

比如我们电脑的操作系统的回收站就是一个很好的单例模式应用,电脑上的文件、视频、音乐等被删除后都会进入到回收站中;还有计算机中的打印机也是采用单例模式设计的,一个系统中可以存在多个打印任务,但是只能有一个正在工作的任务;Web页面的计数器也是用单例模式实现的,可以不用把每次刷新都记录到数据库中。

通过回味这些应用场景,我们对单例模式的核心思想也就有了更清晰的认识

简单来说,就是对一个类只可以new一次。

接下来直接上代码

class Singleton {
public:
    static Singleton* getInstance();
    static Singleton *m_instance;

private:
    Singleton();
    Singleton(const Singleton& other);
};

Singleton* Singleton::m_instance = nullptr;

下面来看第一种:

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

这种写法很简单,看起来逻辑也正确,但是会出现线程安全问题。

假设最开始的时候,第一次创建对象,Thread A和Thread B同时进入if判断语句,这时m_instance还是nullptr,那么Thread A和Thread B创建了两个对象,类似的,如果有多个Thread,很有可能会出现多个对象。

这种情况违反了单例模式的初衷,因此不可取。

那么这种情况怎么解决呢

加锁

第二种:

/线程安全版本,但锁的代价过高
Singleton* Singleton::getInstance(){
    Lock lock;
    if(m_instance==nullptr){
        m_instance = new Singleton();
    }
    return m_instance;
}

加锁后,解决了线程安全问题。但是加锁后又出现了一个问题。

假设类已经被实例化,那么在高并发的时候,对于多个线程同时获取对象的时候,只能串行获取,也就是必须等其他线程释放锁后,才可以去竞争获取锁,这会对高性能造成极大影响。

随后,又出现了双检查锁的方式

第三种:

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

这样看起来是不是对于读线程就没有影响了。

有朋友可能会疑惑,为什么要来两层判断呢?

这是因为在开始对象还没有实例化的时候,多个线程同时进入第一个判断,如果没有第二个判断,那么锁就失效了。

看起来逻辑很正确了,对于并发也没有问题,但是其中又隐藏着另一个问题,那就是内存读写reorder会不安全,会导致双检查锁的失效。

关键在于下面这行代码

m_instance = new Singleton();

一段代码都是有一个指令序列的,通常情况下会认为指令序列会按照想象的流程去执行。但是实际情况中,到了汇编层次,CPU的指令层次后,这个指令有可能和我们的假设不一致。

上面那行程序,如果拆分成三个步骤后,假设中应该是

  • 分配内存
  • 调用构造器初始化内存
  • 将分配的内存的地址赋值给m_instance指针

但是这三个步骤只是我们假想的执行流程,实际上,在CPU指令级别,这三个步骤有可能被reorder,reorder之后有可能变成

  • 分配内存
  • 将分配的内存的地址赋值给m_instance指针。
  • 调用构造器初始化内存

这样就会造成一个问题,假设Thread A港执行完2赋值操作,还没有执行3的时候,Thread B调用getInstance()函数,会获得一个对象。双检查锁欺骗了Thread B, Thread B拿到的m_instance只是分配的原生内存,而没有执行构造器。

这就是双检查锁可能会出现的问题

第四种:

为了解决reorder的问题,java和csharp引入了volatile关键字,告诉编译器,volatile声明的语句的赋值过程不可以被优化,不可以reorder,必须按照假设的流程进行。

c++随后引入了volatile关键字,但是不支持跨平台

c++是一种追求跨平台的语言,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);
   //屏蔽编译器的reorder
    std::atomic_thread_fence(std::memory_order_acquire);    //get memory fence
    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);    //release memory fence
            m_instance.store(tmp,std::memory_order_relaxed);
        }
    }
    return tmp;
}
  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 2
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 2
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值