C++设计模式（1）-- 单例模式

news2025/1/10 11:09:39

基本概念

在一个项目中，全局范围内，某个类的实例有且仅有一个，通过这个唯一实例向其他模块提供数据的全局访问，这种模式就叫单例模式，单例模式的典型应用就是任务队列

在这里插入图片描述

涉及一个类多对象操作的函数有以下几个：

构造函数：创建一个新的对象
拷贝构造函数：根据已有对象拷贝出一个新的对象
拷贝赋值操作符重载函数：两个对象之间的赋值

为了把一个类可以实例化多个对象的路堵死，可以做如下处理：

1、构造函数私有化，在类内部只调用一次，这个是可控的。

由于使用者在类外部不能使用构造函数，所以在类内部创建的这个唯一的对象必须是静态的，这样就可以通过类名来访问了，为了不破坏类的封装，我们都会把这个静态对象的访问权限设置为私有的。
在类中只有它的静态成员函数才能访问其静态成员变量，所以可以给这个单例类提供一个静态函数用于得到这个静态的单例对象。

2、拷贝构造函数私有化或者禁用（使用 = delete）

3、拷贝赋值操作符重载函数私有化或者禁用（从单例的语义上讲这个函数已经毫无意义，所以在类中不再提供这样一个函数，故将它也一并处理一下。）

定义一个单例模式的类的示例代码如下：

// 定义一个单例模式的类
class Singleton
{
public:
    // = delete 代表函数禁用, 也可以将其访问权限设置为私有
    Singleton(const Singleton& obj) = delete;
    Singleton& operator=(const Singleton& obj) = delete;
    static Singleton* getInstance();
private:
    Singleton() = default;
    static Singleton* m_obj;
};

在实现一个单例模式的类的时候，有两种处理模式：

  • 饿汉模式
  • 懒汉模式

饿汉模式

饿汉模式就是在类加载的时候立刻进行实例化，这样就得到了一个唯一的可用对象。关于这个饿汉模式的类的定义如下:

// 饿汉模式
class TaskQueue
{
public:
    // = delete 代表函数禁用, 也可以将其访问权限设置为私有
    TaskQueue(const TaskQueue& obj) = delete;
    TaskQueue& operator=(const TaskQueue& obj) = delete;
    static TaskQueue* getInstance()
    {
        return m_taskQ;
    }
private:
    TaskQueue() = default;
    static TaskQueue* m_taskQ;
};
// 静态成员初始化放到类外部处理
TaskQueue* TaskQueue::m_taskQ = new TaskQueue;

int main()
{
    TaskQueue* obj = TaskQueue::getInstance();
}

在第17行，定义这个单例类的时候，就把这个静态的单例对象创建出来了。当使用者通过getInstance()获取这个单例对象的时候，它已经被准备好了

💡 类的静态成员变量在使用之前必须在类的外部进行初始化才能使用

懒汉模式

懒汉模式是在类加载的时候不去创建这个唯一的实例，而是在需要使用的时候再进行实例化

懒汉模式类的定义

// 懒汉模式
class TaskQueue
{
public:
    // = delete 代表函数禁用, 也可以将其访问权限设置为私有
    TaskQueue(const TaskQueue& obj) = delete;
    TaskQueue& operator=(const TaskQueue& obj) = delete;
    static TaskQueue* getInstance()
    {
        if(m_taskQ == nullptr)
        {
            m_taskQ = new TaskQueue;
        }
        return m_taskQ;
    }
private:
    TaskQueue() = default;
    static TaskQueue* m_taskQ;
};
TaskQueue* TaskQueue::m_taskQ = nullptr;

在调用getInstance()函数获取单例对象的时候，如果在单线程情况下是没有什么问题的，如果是多个线程，调用这个函数去访问单例对象就有问题了。假设有三个线程同时执行了getInstance()函数，在这个函数内部每个线程都会new出一个实例对象。此时，这个任务队列类的实例对象不是一个而是3个，很显然这与单例模式的定义是相悖的

线程安全问题

双重检查锁定

对于饿汉模式是没有线程安全问题的，在这种模式下访问单例对象的时候，这个对象已经被创建出来了。要解决懒汉模式的线程安全问题，最常用的解决方案就是使用互斥锁。可以将创建单例对象的代码使用互斥锁锁住，处理代码如下：

class TaskQueue
{
public:
    // = delete 代表函数禁用, 也可以将其访问权限设置为私有
    TaskQueue(const TaskQueue& obj) = delete;
    TaskQueue& operator=(const TaskQueue& obj) = delete;
    static TaskQueue* getInstance()
    {
        m_mutex.lock();
        if (m_taskQ == nullptr)
        {
            m_taskQ = new TaskQueue;
        }
        m_mutex.unlock();
        return m_taskQ;
    }
private:
    TaskQueue() = default;
    static TaskQueue* m_taskQ;
    static mutex m_mutex;
};
TaskQueue* TaskQueue::m_taskQ = nullptr;
mutex TaskQueue::m_mutex;

在上面代码的10~13 行这个代码块被互斥锁锁住了，也就意味着不论有多少个线程，同时执行这个代码块的线程只能是一个（相当于是严重限行了，在重负载情况下，可能导致响应缓慢）。我们可以将代码再优化一下：

class TaskQueue
{
public:
    // = delete 代表函数禁用, 也可以将其访问权限设置为私有
    TaskQueue(const TaskQueue& obj) = delete;
    TaskQueue& operator=(const TaskQueue& obj) = delete;
    static TaskQueue* getInstance()
    {
        if (m_taskQ == nullptr)
        {
            m_mutex.lock();
            if (m_taskQ == nullptr)
            {
                m_taskQ = new TaskQueue;
            }
            m_mutex.unlock();
        }
        return m_taskQ;
    }
private:
    TaskQueue() = default;
    static TaskQueue* m_taskQ;
    static mutex m_mutex;
};
TaskQueue* TaskQueue::m_taskQ = nullptr;
mutex TaskQueue::m_mutex;

改进的思路就是在加锁、解锁的代码块外层有添加了一个if判断（第9行），这样当任务队列的实例被创建出来之后，访问这个对象的线程就不会再执行加锁和解锁操作了（只要有了单例类的实例对象，限行就解除了），对于第一次创建单例对象的时候线程之间还是具有竞争关系，被互斥锁阻塞。上面这种通过两个嵌套的 if 来判断单例对象是否为空的操作就叫做双重检查锁定。

双重检查锁定的问题

假设有两个线程A、B，当线程A 执行到第 8 行时在线程A中 TaskQueue 实例对象 被创建，并赋值给 m_taskQ

static TaskQueue* getInstance()
{
    if (m_taskQ == nullptr)
    {
        m_mutex.lock();
        if (m_taskQ == nullptr)
        {
            m_taskQ = new TaskQueue;
        }
        m_mutex.unlock();
    }
    return m_taskQ;
}

但是实际上 m_taskQ = new TaskQueue; 在执行过程中对应的机器指令可能会被重新排序。正常过程如下：

第一步：分配内存用于保存 TaskQueue 对象。

第二步：在分配的内存中构造一个 TaskQueue 对象（初始化内存）。

第三步：使用 m_taskQ 指针指向分配的内存。

但是被重新排序以后执行顺序可能会变成这样：

第一步：分配内存用于保存 TaskQueue 对象。

第二步：使用 m_taskQ 指针指向分配的内存。

第三步：在分配的内存中构造一个 TaskQueue 对象（初始化内存）。

这样重排序并不影响单线程的执行结果，但是在多线程中就会出问题。如果线程A按照第二种顺序执行机器指令，执行完前两步之后失去CPU时间片被挂起了，此时线程B在第3行处进行指针判断的时候m_taskQ 指针是不为空的，但这个指针指向的内存却没有被初始化，最后线程 B 使用了一个没有被初始化的队列对象就出问题了（出现这种情况是概率问题，需要反复的大量测试问题才可能会出现）。

在C++11中引入了原子变量atomic，通过原子变量可以实现一种更安全的懒汉模式的单例：

class TaskQueue
{
public:
    // = delete 代表函数禁用, 也可以将其访问权限设置为私有
    TaskQueue(const TaskQueue& obj) = delete;
    TaskQueue& operator=(const TaskQueue& obj) = delete;
    static TaskQueue* getInstance()
    {
        TaskQueue* queue = m_taskQ.load();  
        if (queue == nullptr)
        {
            // m_mutex.lock();  // 加锁: 方式1
            lock_guard<mutex> locker(m_mutex);  // 加锁: 方式2
            queue = m_taskQ.load();
            if (queue == nullptr)
            {
                queue = new TaskQueue;
                m_taskQ.store(queue);
            }
            // m_mutex.unlock();
        }
        return queue;
    }

    void print()
    {
        cout << "hello, world!!!" << endl;
    }
private:
    TaskQueue() = default;
    static atomic<TaskQueue*> m_taskQ;
    static mutex m_mutex;
};
atomic<TaskQueue*> TaskQueue::m_taskQ;
mutex TaskQueue::m_mutex;

int main()
{
    TaskQueue* queue = TaskQueue::getInstance();
    queue->print();
    return 0;
}

上面代码中使用原子变量atomic的store() 方法来存储单例对象，使用load() 方法来加载单例对象。在原子变量中这两个函数在处理指令的时候默认的原子顺序是memory_order_seq_cst（顺序原子操作 - sequentially consistent），使用顺序约束原子操作库，整个函数执行都将保证顺序执行，并且不会出现数据竞态（data races），不足之处就是使用这种方法实现的懒汉模式的单例执行效率更低一些。

静态局部对象

在实现懒汉模式的单例的时候，相较于双重检查锁定模式有一种更简单的实现方法并且不会出现线程安全问题，那就是使用静态局部局部对象，对应的代码实现如下：

class TaskQueue
{
public:
    // = delete 代表函数禁用, 也可以将其访问权限设置为私有
    TaskQueue(const TaskQueue& obj) = delete;
    TaskQueue& operator=(const TaskQueue& obj) = delete;
    static TaskQueue* getInstance()
    {
        static TaskQueue taskQ;
        return &taskQ;
    }
    void print()
    {
        cout << "hello, world!!!" << endl;
    }

private:
    TaskQueue() = default;
};

int main()
{
    TaskQueue* queue = TaskQueue::getInstance();
    queue->print();
    return 0;
}

在程序的第 9、10 行定义了一个静态局部队列对象，并且将这个对象作为了唯一的单例实例。使用这种方式之所以是线程安全的，是因为在C++11标准中有如下规定，并且这个操作是在编译时由编译器保证的：

如果指令逻辑进入一个未被初始化的声明变量，**所有并发执行应当等待该变量完成初始化**

懒汉模式和饿汉模式的区别：

懒汉模式的缺点是在创建实例对象的时候有安全问题，但这样可以减少内存的浪费（如果用不到就不去申请内存了）。饿汉模式则相反，在我们不需要这个实例对象的时候，它已经被创建出来，占用了一块内存。对于现在的计算机而言，内存容量都是足够大的，这个缺陷可以被无视

实现单例模式的任务队列

属性：
存储任务的容器，这个容器可以选择使用STL中的队列（queue)
互斥锁，多线程访问的时候用于保护任务队列中的数据

方法：主要是对任务队列中的任务进行操作
任务队列中任务是否为空
往任务队列中添加一个任务
从任务队列中取出一个任务
从任务队列中删除一个任务

#include <iostream>
#include <queue>
#include <mutex>
#include <thread>
using namespace std;

class TaskQueue
{
public:
    // = delete 代表函数禁用, 也可以将其访问权限设置为私有
    TaskQueue(const TaskQueue& obj) = delete;
    TaskQueue& operator=(const TaskQueue& obj) = delete;
    static TaskQueue* getInstance()
    {
        return &m_obj;
    }
    // 任务队列是否为空
    bool isEmpty()
    {
        lock_guard<mutex> locker(m_mutex);
        bool flag = m_taskQ.empty();
        return flag;
    }
    // 添加任务
    void addTask(int data)
    {
        lock_guard<mutex> locker(m_mutex);
        m_taskQ.push(data);
    }
    // 取出一个任务
    int takeTask()
    {
        lock_guard<mutex> locker(m_mutex);
        if (!m_taskQ.empty())
        {
            return m_taskQ.front();
        }
        return -1;
    }
    // 删除一个任务
    bool popTask()
    {
        lock_guard<mutex> locker(m_mutex);
        if (!m_taskQ.empty())
        {
            m_taskQ.pop();
            return true;
        }
        return false;
    }
private:
    TaskQueue() = default;
    static TaskQueue m_obj;
    queue<int> m_taskQ;
    mutex m_mutex;
};
TaskQueue TaskQueue::m_obj;

int main()
{
    thread t1([]() {
        TaskQueue* taskQ = TaskQueue::getInstance();
        for (int i = 0; i < 100; ++i)
        {
            taskQ->addTask(i + 100);
            cout << "+++push task: " << i + 100 << ", threadID: " 
                << this_thread::get_id() << endl;
            this_thread::sleep_for(chrono::milliseconds(500));
        }
    });
    thread t2([]() {
        TaskQueue* taskQ = TaskQueue::getInstance();
        this_thread::sleep_for(chrono::milliseconds(100));
        while (!taskQ->isEmpty())
        {
            int data = taskQ->takeTask();
            cout << "---take task: " << data << ", threadID: " 
                << this_thread::get_id() << endl;
            taskQ->popTask();
            this_thread::sleep_for(chrono::seconds(1));
        }
    });
    t1.join();
    t2.join();
}

正常情况下，任务队列中的任务应该是一个函数指针（这个指针指向的函数中有需要执行的任务动作），此处进行了简化，用一个整形数代替了任务队列中的任务

任务队列中的互斥锁保护的是单例对象的中的数据也就是任务队列中的数据，上面所说的线程安全指的是在创建单例对象的时候要保证这个对象只被创建一次，和此处完全是两码事儿，需要区别看待

t1线程的处理动作是往任务队列中添加任务，t2线程的处理动作是从任务队列中取任务，为了保证能够取出所有的任务，此处需要让t2线程的执行晚并且慢一些

本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处：http://www.coloradmin.cn/o/1068212.html

如若内容造成侵权/违法违规/事实不符，请联系多彩编程网进行投诉反馈，一经查实，立即删除！

相关文章

嵌入式基础知识-IP地址与子网划分

嵌入式基础知识-IP地址与子网划分

本篇介绍IP地址与子网划分的一些基础知识&#xff0c;在嵌入式开发&#xff0c;使用网络功能时&#xff0c;需要了解网络的一些基础知识。 1 IP地址 1.1 IPv4与IPv6 对比信息IPv4IPv6长度32位128位地址表示形式点分十进制冒分十六进制表示示例192.168.5.1002002:0000:0000:0…
阅读更多...
this关键字在不同上下文中的值是如何确定的？

this关键字在不同上下文中的值是如何确定的？

聚沙成塔每天进步一点点 ⭐ 专栏简介 前端入门之旅&#xff1a;探索Web开发的奇妙世界 欢迎来到前端入门之旅&#xff01;感兴趣的可以订阅本专栏哦&#xff01;这个专栏是为那些对Web开发感兴趣、刚刚踏入前端领域的朋友们量身打造的。无论你是完全的新手还是有一些基础的开发…
阅读更多...
最全解决docker配置kibana报错 Kibana server is not ready yet

最全解决docker配置kibana报错 Kibana server is not ready yet

问题复现&#xff1a; 在浏览器输入http://192.168.101.65:5601/ 访问kibana报错 Kibana server is not ready yet 问题报错&#xff1a; 首先查看kibana的日志 docker logs kibana 看到报错如下&#xff1a; {"type":"log","timestamp":&q…
阅读更多...
【小笔记】复杂模型小数据可能会造成过拟合还是欠拟合？

【小笔记】复杂模型小数据可能会造成过拟合还是欠拟合？

【学而不思则罔&#xff0c;思而不学则殆】 10.8 问题 针对这个问题&#xff0c;我先问了一下文心一言 它回答了为什么会过拟合和欠拟合&#xff0c;但并没有回答我给的场景。 简单分析 分析模型 复杂模型就表示模型的拟合能力很强&#xff0c;对于数据中特征&#xff08…
阅读更多...
如何保证 RabbitMQ 的消息可靠性？

如何保证 RabbitMQ 的消息可靠性？

项目开发中经常会使用消息队列来完成异步处理、应用解耦、流量控制等功能。虽然消息队列的出现解决了一些场景下的问题&#xff0c;但是同时也引出了一些问题&#xff0c;其中使用消息队列时如何保证消息的可靠性就是一个常见的问题。如果在项目中遇到需要保证消息一定被消费的…
阅读更多...
Mybatis 拦截器（Mybatis插件原理）

Mybatis 拦截器（Mybatis插件原理）

Mybatis为我们提供了拦截器机制用于插件的开发&#xff0c;使用拦截器可以无侵入的开发Mybatis插件&#xff0c;Mybatis允许我们在SQL执行的过程中进行拦截&#xff0c;提供了以下可供拦截的接口&#xff1a; Executor&#xff1a;执行器ParameterHandler&#xff1a;参数处理…
阅读更多...
深入解析PostgreSQL：命令和语法详解及使用指南

深入解析PostgreSQL：命令和语法详解及使用指南

文章目录 摘要引言基本操作安装与配置连接和退出 数据库操作创建数据库删除数据库切换数据库 表操作创建表删除表插入数据查询数据更新数据删除数据 索引和约束创建索引创建约束 用户管理创建用户授权用户修改用户密码 备份和恢复备份数据库恢复数据库 高级特性结语参考文献 摘…
阅读更多...
在win10里顺利安装了apache2.4.41和php7.4.29以及mysql8.0.33

在win10里顺利安装了apache2.4.41和php7.4.29以及mysql8.0.33

一、安装apache和php 最近在学习网站搭建。其中有一项内容是在windows操作系统里搭建apachephp环境。几天前根据一本书的上的说明尝试了一下&#xff0c;在win10操作系统里安装这两个软件&#xff1a;apache2.4.41和php7.4.29&#xff0c;安装以后apche能正常启动&#xff0c;…
阅读更多...
【转载】LLM-Native 产品的变与不变

【转载】LLM-Native 产品的变与不变

1. LLM-Native&#xff1a;AGI 的另一种路径 《银河系漫游指南》的作者——道格拉斯亚当斯曾经对「技术」一词做出这样一种解释&#xff1a; 「技术」是描述某种尚未发挥作用的东西的词汇。 这是一个充满实用主义的定义&#xff0c;这句话可以被更直观地表述为&#xff1a;当…
阅读更多...
机器学习7：pytorch的逻辑回归

机器学习7：pytorch的逻辑回归

一、说明 逻辑回归模型是处理分类问题的最常见机器学习模型之一。二项式逻辑回归只是逻辑回归模型的一种类型。它指的是两个变量的分类&#xff0c;其中概率用于确定二元结果&#xff0c;因此“二项式”中的“bi”。结果为真或假 — 0 或 1。 二项式逻辑回归的一个例子是预测人…
阅读更多...
安卓玩机----解锁system分区 可读写系统分区 magisk面具模块

安卓玩机----解锁system分区 可读写系统分区 magisk面具模块

玩机教程----安卓机型解锁system分区 任意修改删除系统文件 system分区可读写 参考上个博文可以了解到解锁system分区的有关常识。但目前很多机型都在安卓12 13 基础上。其实最简单的方法就在于刷写一个解锁system分区的第三方补丁包。在面具更新不能解锁系统分区的前提下。…
阅读更多...
8.2 JUC - 5.CountdownLatch

8.2 JUC - 5.CountdownLatch

目录 一、是什么&#xff1f;二、demo演示三、应用之同步等待多线程准备完毕四、 应用之同步等待多个远程调用结束五、CountDownLatch 原理 一、是什么&#xff1f; CountdownLatch 用来进行线程同步协作&#xff0c;等待所有线程完成倒计时。 其中构造参数用来初始化等待计数…
阅读更多...
C#，数值计算——数据建模Fitab的计算方法与源程序

C#，数值计算——数据建模Fitab的计算方法与源程序

1 文本格式 using System; namespace Legalsoft.Truffer { /// <summary> /// Fitting Data to a Straight Line /// </summary> public class Fitab { private int ndata { get; set; } private double a { get; set; } …
阅读更多...
Linux 根据 PID 查看进程名称

Linux 根据 PID 查看进程名称

ps aux | grep PID
阅读更多...
RabbitMQ之Fanout（扇形） Exchange解读

RabbitMQ之Fanout（扇形） Exchange解读

目录 基本介绍 适用场景 springboot代码演示 演示架构 工程概述 RabbitConfig配置类&#xff1a;创建队列及交换机并进行绑定 MessageService业务类&#xff1a;发送消息及接收消息 主启动类RabbitMq01Application&#xff1a;实现ApplicationRunner接口 基本介绍 Fa…
阅读更多...
跨域请求方案整理实践

跨域请求方案整理实践

项目场景&#xff1a; 调用接口进行手机验证提示,项目需要调用其它域名的接口,导致前端提示跨域问题 问题描述 前端调用其他域名接口时报错提示: index.html#/StatisticalAnalysisOfVacancy:1 Access to XMLHttpRequest at http://xxxxx/CustomerService/template/examineMes…
阅读更多...
openGauss学习笔记-92 openGauss 数据库管理-内存优化表MOT管理-内存表特性-使用MOT-MOT使用MOT SQL覆盖和限制

openGauss学习笔记-92 openGauss 数据库管理-内存优化表MOT管理-内存表特性-使用MOT-MOT使用MOT SQL覆盖和限制

文章目录 openGauss学习笔记-92 openGauss 数据库管理-内存优化表MOT管理-内存表特性-使用MOT-MOT使用MOT SQL覆盖和限制92.1 不支持的特性92.2 MOT限制92.3 不支持的DDL操作92.4 不支持的数据类型92.5 不支持的索引DDL和索引92.6 不支持的DML92.7 不支持的JIT功能&#xff08;…
阅读更多...
ThingsBoard如何自定义tcp-transport

ThingsBoard如何自定义tcp-transport

1、概述 很久没有更新了，一直忙于其他的事情，最近去搞了一个在ThingsBoard中自定义一个tcp-transport，用于连接使用tcp长连接的设备，目前使用tcp和mqtt协议连接服务端的设备还是很多，ThingsBoard的PE版提供了Integration是可以实现tcp的接入，但是CE版是没有提供接入tcp长…
阅读更多...
前端性能优化之防抖节流

前端性能优化之防抖节流

前端性能优化之防抖&节流 1.什么是防抖和节流2.代码实现2.1 实现防抖2.2 实现节流 3.应用场景3.1 防抖的应用3.2 节流的应用 1.什么是防抖和节流 防抖和节流是前端开发中常用的两种性能优化技术。 为什么需要防抖和节流呢&#xff1f; 两者目的都是为了防止某个时间段内…
阅读更多...
配置文件生成器-秒杀SSM的xml整合

配置文件生成器-秒杀SSM的xml整合

配置文件生成器-秒杀SSM的xml整合 思路&#xff1a; 通过简单的配置&#xff0c;直接生成对应配置文件。 maven坐标 <dependencies><!-- 配置文件生成 --><dependency><groupId>org.freemarker</groupId><artifactId>freemarker<…
阅读更多...
推荐文章
最新文章

Copyright @ 2022~2023