Singleton(单例)模式和Double-Checked Locking(双重检查锁定)模式

问题描述

现在,不管开发一个多大的系统(至少我现在的部门是这样的),都会带一个日志功能;在实际开发过程中,会专门有一个日志模块,负责写日志,由于在系统的任何地方,我们都有可能要调用日志模块中的函数,进行写日志。那么,如何构造一个日志模块的实例呢?难道,每次new一个日志模块实例,写完日志,再delete,不要告诉我你是这么干的。在C++中,可以构造一个日志模块的全局变量,那么在任何地方就都可以用了,是的,不错。但是,我所在的开发部门的C++编码规范是参照Google的编码规范的。

全局变量在项目中是能不用就不用的,它是一个定时炸弹,是一个不安全隐患,特别是在多线程程序中,会有很多的不可预测性;同时,使用全局变量,也不符合面向对象的封装原则,所以,在纯面向对象的语言Java和C#中,就没有纯粹的全局变量。那么,如何完美的解决这个日志问题,就需要引入设计模式中的单例模式。

单例模式

何为单例模式,在GOF的《设计模式:可复用面向对象软件的基础》中是这样说的:保证一个类只有一个实例,并提供一个访问它的全局访问点。首先,需要保证一个类只有一个实例;在类中,要构造一个实例,就必须调用类的构造函数,如此,为了防止在外部调用类的构造函数而构造实例,需要将构造函数的访问权限标记为protected或private;最后,需要提供要给全局访问点,就需要在类中定义一个static函数,返回在类内部唯一构造的实例。意思很明白,使用UML类图表示如下。

UML类图

代码实现

单例模式,单从UML类图上来说,就一个类,没有错综复杂的关系。但是,在实际项目中,使用代码实现时,还是需要考虑很多方面的。

#include <iostream>
using namespace std;

class Singleton
{
public:
    static Singleton *GetInstance()
    {
        if (m_Instance == NULL )
        {
            m_Instance = new Singleton ();
        }
        return m_Instance;
    }

    static void DestoryInstance()
    {
        if (m_Instance != NULL )
        {
            delete m_Instance;
            m_Instance = NULL ;
        }
    }

    // This is just a operation example
    int GetTest()
    {
        return m_Test;
    }

private:
    Singleton(){ m_Test = 10; }
    static Singleton *m_Instance;
    int m_Test;
};

Singleton *Singleton ::m_Instance = NULL;

int main(int argc , char *argv [])
{
    Singleton *singletonObj = Singleton ::GetInstance();
    cout<<singletonObj->GetTest()<<endl;

    Singleton ::DestoryInstance();
    return 0;
}

这是最简单,也是最普遍的实现方式,也是现在网上各个博客中记述的实现方式,但是,这种实现方式,有很多问题,比如:没有考虑到多线程的问题,在多线程的情况下,就可能创建多个Singleton实例,以下版本是改善的版本。

实现二:

#include <iostream>
using namespace std;

class Singleton
{
public:
    static Singleton *GetInstance()
    {
        if (m_Instance == NULL )
        {
            Lock(); // C++没有直接的Lock操作,请使用其它库的Lock,比如Boost,此处仅为了说明
            if (m_Instance == NULL )
            {
                m_Instance = new Singleton ();
            }
            UnLock(); // C++没有直接的Lock操作,请使用其它库的Lock,比如Boost,此处仅为了说明
        }
        return m_Instance;
    }

    static void DestoryInstance()
    {
        if (m_Instance != NULL )
        {
            delete m_Instance;
            m_Instance = NULL ;
        }
    }

    int GetTest()
    {
        return m_Test;
    }

private:
    Singleton(){ m_Test = 0; }
    static Singleton *m_Instance;
    int m_Test;
};

Singleton *Singleton ::m_Instance = NULL;

int main(int argc , char *argv [])
{
    Singleton *singletonObj = Singleton ::GetInstance();
    cout<<singletonObj->GetTest()<<endl;
    Singleton ::DestoryInstance();

    return 0;
}

此处进行了两次m_Instance == NULL的判断,是借鉴了Java的单例模式实现时,使用的所谓的“双检锁”机制。因为进行一次加锁和解锁是需要付出对应的代价的,而进行两次判断,就可以避免多次加锁与解锁操作,同时也保证了线程安全。但是,这种实现方法在平时的项目开发中用的很好,也没有什么问题?但是,如果进行大数据的操作,加锁操作将成为一个性能的瓶颈;为此,一种新的单例模式的实现也就出现了。

实现三:

#include <iostream>
using namespace std;

class Singleton
{
public:
    static Singleton *GetInstance()
    {
        return const_cast <Singleton *>(m_Instance);
    }

    static void DestoryInstance()
    {
        if (m_Instance != NULL )
        {
            delete m_Instance;
            m_Instance = NULL ;
        }
    }

    int GetTest()
    {
        return m_Test;
    }

private:
    Singleton(){ m_Test = 10; }
    static const Singleton *m_Instance;
    int m_Test;
};

const Singleton *Singleton ::m_Instance = new Singleton();

int main(int argc , char *argv [])
{
    Singleton *singletonObj = Singleton ::GetInstance();
    cout<<singletonObj->GetTest()<<endl;
    Singleton ::DestoryInstance();
}

因为静态初始化在程序开始时,也就是进入主函数之前,由主线程以单线程方式完成了初始化,所以静态初始化实例保证了线程安全性。在性能要求比较高时,就可以使用这种方式,从而避免频繁的加锁和解锁造成的资源浪费。由于上述三种实现,都要考虑到实例的销毁,关于实例的销毁,待会在分析。由此,就出现了第四种实现方式:

实现四:

#include <iostream>
using namespace std;

class Singleton
{
public:
    static Singleton *GetInstance()
    {
        static Singleton m_Instance;
        return &m_Instance;
    }

    int GetTest()
    {
        return m_Test++;
    }

private:
    Singleton(){ m_Test = 10; };
    int m_Test;
};

int main(int argc , char *argv [])
{
    Singleton *singletonObj = Singleton ::GetInstance();
    cout<<singletonObj->GetTest()<<endl;

    singletonObj = Singleton ::GetInstance();
    cout<<singletonObj->GetTest()<<endl;
}

以上就是四种主流的单例模式的实现方式,如果大家还有什么好的实现方式,希望大家能推荐给我。谢谢了。

实例销毁

在上述的四种方法中,除了第四种没有使用new操作符实例化对象以外,其余三种都使用了;我们一般的编程观念是,new操作是需要和delete操作进行匹配的;是的,这种观念是正确的。在上述的实现中,是添加了一个DestoryInstance的static函数,这也是最简单,最普通的处理方法了;但是,很多时候,我们是很容易忘记调用DestoryInstance函数,就像你忘记了调用delete操作一样。由于怕忘记delete操作,所以就有了智能指针;那么,在单例模型中,没有“智能单例”,该怎么办?怎么办?

那我先从实际的项目中说起吧,在实际项目中,特别是客户端开发,其实是不在乎这个实例的销毁的。因为,全局就这么一个变量,全局都要用,它的生命周期伴随着软件的生命周期,软件结束了,它也就自然而然的结束了,因为一个程序关闭之后,它会释放它占用的内存资源的,所以,也就没有所谓的内存泄漏了。但是,有以下情况,是必须需要进行实例销毁的:

  1. 在类中,有一些文件锁了,文件句柄,数据库连接等等,这些随着程序的关闭而不会立即关闭的资源,必须要在程序关闭前,进行手动释放;
  2. 具有强迫症的程序员。

以上,就是我总结的两点。

虽然,在代码实现部分的第四种方法能满足第二个条件,但是无法满足第一个条件。好了,接下来,就介绍一种方法,这种方法也是我从网上学习而来的,代码实现如下:

#include <iostream>
using namespace std;

class Singleton
{
public:
    static Singleton *GetInstance()
    {
        return m_Instance;
    }

    int GetTest()
    {
        return m_Test;
    }

private:
    Singleton(){ m_Test = 10; }
    static Singleton *m_Instance;
    int m_Test;

    // This is important
    class GC
    {
    public :
        ~GC()
        {
            // We can destory all the resouce here, eg:db connector, file handle and so on
            if (m_Instance != NULL )
            {
                cout<< "Here is the test" <<endl;
                delete m_Instance;
                m_Instance = NULL ;
            }
        }
    };
    static GC gc;
};

Singleton *Singleton ::m_Instance = new Singleton();
Singleton ::GC Singleton ::gc;

int main(int argc , char *argv [])
{
    Singleton *singletonObj = Singleton ::GetInstance();
    cout<<singletonObj->GetTest()<<endl;

    return 0;
}

在程序运行结束时,系统会调用Singleton的静态成员GC的析构函数,该析构函数会进行资源的释放,而这种资源的释放方式是在程序员“不知道”的情况下进行的,而程序员不用特别的去关心,使用单例模式的代码时,不必关心资源的释放。那么这种实现方式的原理是什么呢?我剖析问题时,喜欢剖析到问题的根上去,绝不糊涂的停留在表面。由于程序在结束的时候,系统会自动析构所有的全局变量,实际上,系统也会析构所有类的静态成员变量,就像这些静态变量是全局变量一样。我们知道,静态变量和全局变量在内存中,都是存储在静态存储区的,所以在析构时,是同等对待的。

由于此处使用了一个内部GC类,而该类的作用就是用来释放资源,而这种使用技巧在C++中是广泛存在的,在后面的博客中,我会总结这一技巧,参见《C++中的RAII机制》

模式扩展

在实际项目中,一个模式不会像我们这里的代码那样简单,只有在熟练了各种设计模式的特点,才能更好的在实际项目中进行运用。单例模式和工厂模式在实际项目中经常见到,两种模式的组合,在项目中也是很常见的。所以,有必要总结一下两种模式的结合使用。

一种产品,在一个工厂中进行生产,这是一个工厂模式的描述;而只需要一个工厂,就可以生产一种产品,这是一个单例模式的描述。所以,在实际中,一种产品,我们只需要一个工厂,此时,就需要工厂模式和单例模式的结合设计。由于单例模式提供对外一个全局的访问点,所以,我们就需要使用简单工厂模式中那样的方法,定义一个标识,用来标识要创建的是哪一个单件。由于模拟代码较多,在文章最后,提供下载链接。

总结

为了写这篇文章,自己调查了很多方面的资料,由于网上的资料在各方面都有很多的瑕疵,质量参次不齐,对我也造成了一定的误导。而这篇文章,有我自己的理解,如有错误,请大家指正。

由于该文对设计模式的总结,我认为比网上80%的都全面,希望对大家有用。在实际的开发中,并不会用到单例模式的这么多种,每一种设计模式,都应该在最适合的场合下使用,在日后的项目中,应做到有地放矢,而不能为了使用设计模式而使用设计模式。

转载:http://www.jellythink.com/archives/82

时间: 2024-10-22 07:48:25

Singleton(单例)模式和Double-Checked Locking(双重检查锁定)模式的相关文章

Double Checked Locking 模式

之前在使用Double Check Locking 模式时,发现自己还是不太理解.于是写个记录,其实很简单,一看就明白了. 应用特别说明:1.Double Check Locking模式是singleton的多线程版本,如果是单线程则应使用singleton.2.Double Check Locking模式依就会使用锁--临界区锁定,不要以为可以避免使用锁.3.Double Check Locking 解决的问题是:当多个线程存在访问临界区企图时,保证了临界区只需要访问一次. 下面是其适用特点:

完美的单例实现(The Perfect Singleton)

我经常遇到一些这样的Java程序员,他们不确定应该如何恰当的实现单例模式. 我不考虑在线程的环境中合适的实现.但是使用你能在网络上找到的大多数常见的实现方式,你可以轻松地创建你想要的多种单例实现. 假设你有下面这种常见的单例的实现: 1 public final class NonSafeSingleton implements Serializable { 2     private static final NonSafeSingleton INSTANCE = new NonSafeSin

Java单例进化史

关于单例,从我学Java到现在只知道以下两点: 1.为了让一个类只能有一个实例,所以使用单例的设计模式. 2.有两种实现方法:①饿汉式 ②懒汉式 ①饿汉式简单,是线程安全的.但是在类加载时就创建了一个实例,但是这个单例类可能永远不会被使用,这就造成了浪费.而且类被加载器加载时就会实例化一次.这就有可能被实例化多次. public class Singleton { private static final Singleton INSTANCE = new Singleton(); private

【秒懂设计模式】单例设计模式

 秒懂设计模式--单例设计模式 (三)单例设计模式 1.先解释一下,什么是单例模式呢? 在Java中是这样定义的:"一个类有且仅有一个实例,并且自行实例化向整个系统提供." 显然从单例模式的定义中,我们可以发现它有三个要点: ①某个类只能有一个实例: ②它必须自行创建这个实例: ③它必须自行向整个系统提供这个实例. 2.要满足这三个要点,应该如何实现呢?下面让我们来逐条分析: ①如何保证某个类只能有一个实例? 让我先来想一下,一个类的对象是如何创建的呢?答案是:一个类的对象的产生是由类

【java设计模式】之 单例(Singleton)模式

1. 单例模式的定义         单例模式(Singleton Pattern)是一个比较简单的模式,其原始定义如下:Ensure a class has only one instance, and provide a global point of access to it. 即确保只有一个实例,而且自行实例化并向整个系统提供这个实例.单例模式的通用类如下图所示:         Singleton类称为单例类,通过使用private的构造函数确保了在一个应用中只产生一个实例,并且是自行

《JavaScript设计模式》——9.4 Singleton(单例)模式

9.4 Singleton(单例)模式 Singleton(单例)模式被熟知的原因是因为它限制了类的实例化次数只能一次.从经典意义上来说,Singleton模式,在该实例不存在的情况下,可以通过一个方法创建一个类来实现创建类的新实例:如果实例已经存在,它会简单返回该对象的引用.Singleton不同于静态类(或对象),因为我们可以推迟它们的初始化,这通常是因为它们需要一些信息,而这些信息在初始化期间可能无法获得.对于没有察觉到之前的引用的代码,它们不会提供方便检索的方法.这是因为它既不是对象,也

javascript 单例/单体模式(Singleton)_javascript技巧

单例模式的三个特点: 1,该类只有一个实例 2,该类自行创建该实例(在该类内部创建自身的实例对象) 3,向整个系统公开这个实例接口 Java中大概是这个样子 复制代码 代码如下: class Singleton { //私有,静态的类自身实例 private static Singleton instance = new Singleton(); //私有的构造子(构造器,构造函数,构造方法) private Singleton(){} //公开,静态的工厂方法 public static Si

设计模式C#描述——单例与多例模式

设计 设计模式C#描述--单例与多例模式 作为对象的创建模式,单例模式确保某一个类只有一个实例,而且自行实例化并向整个系统提供这个实例.这个类称为单例类. 单例模式有以下特点: 单例类只能有一个实例. 单例类必须自己创建自己的唯一实例. 单例类必须给所有其他对象提供这一实例. 一个典型的单例类的实现如下所示:其中构造子私有表示子类不能被继承. public class Singleton { private static Singleton m_instance = null; private

Ruby设计模式透析:单例(Singleton)

写软件的时候经常需要用到打印日志功能,可以帮助你调试和定位问题,项目上线后还可以帮助你 分析数据,但是Ruby原生带有的puts方法却很少在真正的项目开发中使用. 为什么作为Ruby新 手神器的puts,到了真正项目开发当中会被唾弃呢?其实只要细细分析,你就会发现它的很多弊端.比 如不可控制,所有的日志都会在项目上线后照常打印,从而降低运行效率:又或者不能将日志记录到本 地文件,一旦打印被清除,日志将再也找不回来:再或者打印的内容没有Tag区分,你将很难辨别这一 行日志是在哪个类里打印的. 你的