• 单例模式


    首先介绍一下单例模式: 
        单例模式(Singleton),也叫单子模式,是一种常用的软件设计模式。在应用这个模式时,单例对象的类必须保证只有一个实例存在。许多时候整个系统只需要拥有一个的全局对象,这样有利于我们协调系统整体的行为。比如在某个服务器程序中,该服务器的配置信息存放在一个文件中,这些配置数据由一个单例对象统一读取,然后服务进程中的其他对象再通过这个单例对象获取这些配置信息。这种方式简化了在复杂环境下的配置管理。 

    实现单例模式的思路是: 
        一个类能返回对象一个引用(永远是同一个)和一个获得该实例的方法(必须是静态方法,通常使用getInstance这个名 称);当我们调用这个方法时,如果类持有的引用不为空就返回这个引用,如果类保持的引用为空就创建该类的实例并将实例的引用赋予该类保持的引用;同时我们 还将该类的构造函数定义为私有方法,这样其他处的代码就无法通过调用该类的构造函数来实例化该类的对象,只有通过该类提供的静态方法来得到该类的唯一实例。 

    需要注意的地方: 
        单例模式在多线程的 应用场合下必须小心使用。如果当唯一实例尚未创建时,有两个线程同时调用创建方法,那么它们同时没有检测到唯一实例的存在,从而同时各自创建了一个实例, 这样就有两个实例被构造出来,从而违反了单例模式中实例唯一的原则。 解决这个问题的办法是为指示类是否已经实例化的变量提供一个互斥锁(虽然这样会降低效率)。 

    优点: 
        1.在单例模式中,活动的单例只有一个实例,对单例类的所有实例化得到的都是相同的一个实例。这样就 防止其它对象对自己的实例化,确保所有的对象都访问一个实例 
        2.单例模式具有一定的伸缩性,类自己来控制实例化进程,类就在改变实例化进程上有相应的伸缩性。 
        3.提供了对唯一实例的受控访问。 
        4.由于在系统内存中只存在一个对象,因此可以 节约系统资源,当 需要频繁创建和销毁的对象时单例模式无疑可以提高系统的性能。 
        5.允许可变数目的实例。 
        6.避免对共享资源的多重占用。 
    缺点: 
        1.不适用于变化的对象,如果同一类型的对象总是要在不同的用例场景发生变化,单例就会引起数据的错误,不能保存彼此的状态。 
        2.由于单利模式中没有抽象层,因此单例类的扩展有很大的困难。 
        3.单例类的职责过重,在一定程度上违背了“单一职责原则”。 
        4.滥用单例将带来一些负面问题,如为了节省资源将数据库连接池对象设计为的单例类,可能会导致共享连接池对象的程序过多而出现连接池溢出;如果实例化的对象长时间不被利用,系统会认为是垃圾而被回收,这将导致对象状态的丢失。 
    使用注意事项: 
        1.使用时不能用反射模式创建单例,否则会实例化一个新的对象 
        2.使用懒单例模式时注意线程安全问题 
        3.饿单例模式和懒单例模式构造方法都是私有的,因而是不能被继承的,有些单例模式可以被继承(如登记式模式) 
    适用场景: 
        单例模式只允许创建一个对象,因此节省内存,加快对象访问速度,因此对象需要被公用的场合适合使用,如多个模块使用同一个数据源连接对象等等。如: 
        1.需要频繁实例化然后销毁的对象。 
        2.创建对象时耗时过多或者耗资源过多,但又经常用到的对象。 
        3.有状态的工具类对象。 
        4.频繁访问数据库或文件的对象。

    Single.cpp

    class Singleton{
    private:
        Singleton(); //构造函数
        Singleton(const Singleton& other);  //拷贝构造函数
    public:
        static Singleton* getInstance();
        static Singleton* m_instance;
    };
    
    Singleton* Singleton::m_instance = nullptr;
    //线程非安全版本
    Singleton* Singleton::getInstance()
    {
        if (m_instance == nullptr){
            m_instance = new Singleton();
        }
        return m_instance;
    }
    
    /*
    该写法在单线程里是OK的,但是在多线程下就不行
    例如有两个thread,thread1和thread2
    如果thread1执行到了14行但是没有执行到第15行,恰巧此时的thread2页执行到了
    第14行,这就意味着接下里第15行都会被thread1和thread2执行,在多线程的情况下就
    会出现被创建两个对象,所以这是一个多线程非安全的版本
    */
    
    //线程安全版本,但锁的代价过高
    Singleton* Singleton::getInstance(){
        Lock lock;
        if (m_instance == nullptr)
        {
            m_instance = new Singleton();
        }
        return m_instance;
    }
    
    /*
    该方法加了一个锁,在thread1在进入该代码后,在锁未释放前,thread2不会
    执行到第30行代码,但是锁的代价太高
    假如第31行不是空,thread1执行到了第31行,而thread2此时进不了29行,因为thread1锁还没有释放,
    那么这个过程有没有必要加锁?
    其实没有必要的,读的过程没有必要加锁的,因此在读的过程加锁,是浪费的。
    将它放在高并发的场景下,那么锁的代价是非常高的
    */
    
    //双检查锁,但由于内存读写reorder不安全
    Singleton* Singleton::getInstance()
    {
        if (m_instance == nullptr){
            Lock lock;
            if (m_instance == nullptr)
            {
                m_instance = new Singleton();
            }
        }
        return m_instance;
    }
    /*
    该方法的特点是在锁前在检查一次
    锁前检查避免了如果都是读取的时候,也就是m_instance不是nullptr的时候,
    出现代价过高的问题
    锁后检查是避免thread1和thread2进入51行之后,在52行之前,创建两个对象的
    错误。
    */
    
    //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);
        std::atomic_thread_fence(std::memory_order_acquire);//获取内存fence
        if (tmp == nullptr)
        {
            std::lock_guard<std::muutex> 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);
            }
        }
    
    }

  • 相关阅读:
    转载一篇不错的Mac上安装Apache和多版本PHP的文章
    Mac 上配置tomcat 及可能碰到的问题。
    iOS通知中心 NSNotificationCenter详解
    字符缓冲区读取文件BufferedReader
    BufferedWriter—newLine
    缓冲流复制文件与基本流复制文件比较
    BufferedOutputStream缓冲流
    properties集合
    JDK7,JDK9流中异常的处理
    try-catch-finally处理流中的异常
  • 原文地址:https://www.cnblogs.com/zhuifeng-mayi/p/11066452.html
Copyright © 2020-2023  润新知