• 设计模式--Note5--对象性能类


    Singleton

    单件模式

    保证一个类仅有一个实例,并提供一个该实例的全局访问点。

    解决什么问题

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

    如何绕过常规的构造器,提供一种机制来保证一个类只有一个实例?

    这应该是类设计者的责任,而不是使用者的责任。

    结构

    要点总结

    1. Singleton模式中的构造器可以设置为protected以允许子类派生。
    2. Singleton模式一般不要支持拷贝构造函数和Clone接口,因为这有可能导致多个对象实例,与Singleton模式的初衷违背。
    3. 如何实现多线程环境下安全的Singleton?注意对双检查锁的正确使用。

    示例

    (2 封私信 / 14 条消息) 如何理解 C++11 的六种 memory order? - 知乎 (zhihu.com)

    class Singleton {
    private:
        Singleton();
        Singleton(const Singleton&);
    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;
    }
    
    // 线程安全版本,但是锁代价过高
    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;
    }
    
    // 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_gard<std::mutex> lock(m_mutex);
            tmp = m_instance.load(std::memory_order_release);
            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;
    }
    

    Flyweight

    享元模式

    运用共享技术有效地支持大量细粒度的对象。

    解决什么问题

    在软件系统中采用纯粹对象方案的问题在于大量细粒度的对象会很快充斥系统中,从而带来很高的运行时代价——主要指内存需求方面的代价。

    如何在避免大量细粒度对象问题的同时,让外部客户程序仍能够透明地使用面向对象的方式来进行操作?

    结构

    要点总结

    1. 面向对象很好地解决了抽象性的问题,但是作为一个运行在机器中的程序实体,我们需要考虑一个对象的代价问题。Flyweight主要解决面向对象的代价问题,一般不触及面向对象的抽象性问题。
    2. Flyweight采用对象共享的做法来降低系统中对象的个数,从而降低细粒度对象给系统带来的内存压力。在具体实现方面,要注意对象状态的处理。
    3. 对象的数量太大从而导致对象内存开销加大——什么样的数量才算大?这需要我们仔细地根据具体应用情况进行评估,而不能凭空臆断。

    示例:字体对象

    class Font {
    private:
        // unique object key
        string key;
    
        // object state
        // ........
    
    public:
        Font(const string& key) {
            // ...
        }
    };
    
    class FontFactory {
    private:
        map<string, Font*> fontPool;
    
    public:
        Font* GetFont(const string& key) {
            map<string, Font*>::iterator it = fontPool.find(key);
    
            if (it != fontPool.end()) {
                return fontPool[key];
            }
            else {
                Font* font = new Font(key);
                fontPool[key] = font;
                return font;
            }
        }
    
        void clear() {
            // ...
        }
    };
    
    转载请注明出处
  • 相关阅读:
    NHibernate学习之二
    ETL学习之四:SQL Server Integration Services入门
    NHibernate学习之五:三种常见的配置方法。
    ORACLE执行计划入门
    C# default關鍵字
    WordPress Mail On Update插件跨站请求伪造漏洞
    WordPress Colormix主题多个安全漏洞
    nginx 'ngx_http_parse.c'栈缓冲区溢出漏洞
    Apache HTTP Server日志内终端转义序列命令注入漏洞
    WordPress wpFileManager插件‘path’参数任意文件下载漏洞
  • 原文地址:https://www.cnblogs.com/lnlin/p/15259953.html
Copyright © 2020-2023  润新知