[原] blade中C++ singleton的实现

最近看了龚大大KalyGE中的singleton, 觉得非常不错(C++中线程安全并且高效的singleton).

可惜blade的代码都是C++03的, 没有使用C++11的任何特性. 笔者对于singleton也有些经验, 不过由于业余写代码本来就时间不够(blade在6年内堆了近20W行有效代码), 所以笔记记得非常少. 最近几个月业余没有写代码了, 所以有时间把blade在开发中遇到的问题贴出来.

而C++11虽然很爽很方便, 但是目前还没有加入支持的打算.

为了方便分析, 列出两种方式的singleton实现:

简单实现 (local static object):

template<typename T> class Singleton
{
    static T& getSingleton()
    {
        static T instance;
        return instance;
    }
};

复杂实现( double check lock):

static T* msSingleton = NULL;
static Lock msLock;

T& getSingleton()
{
    if (NULL == msSingleton )
    {
        ScopeLock lock(msLock);
        if (NULL == msSingleton )
        {
            msSingleton = new T;
        }
    }
     return *msSingleton;
}

下面两种实现, 称为简单模式和复杂模式, 并基于C++03标准分析.

1.定义和限制

singleton顾名思义, 就是单例, 所以不能有多个实例, 也不能复制. 笔者曾在工作中就遇到过新手类似下面的复制:

A a = A::getSingleton();

即便是老鸟, 也难以保证不会有手抖的时候. 这种问题可以在runtime做检查. 不过在编译期排除错误更好: 把ctor, copy  ctor设为私有, 同时把operator new设置为protected.

然而有时候为了更加灵活, 允许singleton的一次性new, 比如数据加载时, 统一用new创建对象, 又比如, Singleton的MFC类, MFC在PostNcDestroy的时候, 会自动delete this, 那么要求对象必须new出来

这些情况,可以考虑允许operator new, 并加上runtime check.同时, 为了防止new情况msSingleton无法初始化, 将它的初始化放在构造函数里:

Singleton
{
    assert(msSingleton == NULL );
    msSingleton = static_cast<T*>(this);
}

2.多线程

多线程的问题, 龚大大已经说的很详细了, 这里不多说了.

因为没有使用C++11, 目前blade的singleton使用的是double check lock, 可惜还没有加memory barrier, 考虑后面可能会加上.

对于多线程来说, 个人还是认为, singleton应该在程序初始化时就构建好, 这样可以简化singleton的实现.

---

更新(08/26/2015)补充: 由于上面为了兼容new, 在基类构造函数里面初始化了子类指针, 而指针初始化后子类还未构造, 所以不管线程怎么安全, 都是会有问题的. 这个问题在单线程下看不出来, 但是多线程下就暴露了. 而它本身不是一个多线程问题, 基本无解, 目前还没有想到更好的做法. 最近把支持new/堆分配的特性去掉了, 不再支持基类自动初始化指针, 牺牲一点灵活性换来稳健性. 对于PostNcDestroy的情况, 可以重载以后什么都不做, 跳过delete this. 对于其他三方库接入可能会有一些限制.
对于抽象工厂可以创建Singleton的情况, 理论上可以解决, 强制使用智能指针来声明所有权, 同时智能指针像C++11一样有deleter, 就可以了, 对于singleton指针的deleter,什么都不做. blade的抽象工厂有创建和删除的方法, 可以绑定到智能指针的deleter. 然而blade的智能指针还不支持deleter, 所以目前去掉new的支持以后, 抽象工厂不能创建singleton. 如果以后迁移到C++11, 那么可以使用std::weak_ptr和std::shared_ptr, 并弃用blade自己的智能指针.

另外, 虽然mutex lock比较重量级, 而blade的Lock是spin lock, 其特性特别适合这种场合: 只有第一次构造会花费一点时间, 后面每次调用都是马上返回. 所以由于spin lock的使用, 效率不会有问题, 可以不考虑double check. 如果不使用double check, 那么spin lock直接将整个function scope覆盖, 保证访问的一致性(spin lock隐含barrier), 自然也不需要memory barrier了:

T& getSingleton()
{
#if __cplusplus < 201103L //C++11 doesn't need manual sync
    Lock msLock; //spin lock is fast enough, NO NEED for double check, thus no need for memory barrier
    ScopedLock guard(msLock);
#endif
    static T instance;
    return instance;
}

 当然也可以使用double check lock+memory barrier, 效率上或许会好一点点?

再加上下面构造/析构顺序的检查, 目前最新的代码整理如下(比下文新):

/********************************************************************
    created:    2009/02/07
    filename:     Singleton.h
    author:        Crazii
    
    purpose:    the Singleton pattern: lazy initialization mode
*********************************************************************/
#ifndef __Blade_Singleton_h__
#define __Blade_Singleton_h__
#include "BladeTypes.h" //NULL
#include "Lock.h"
#include "memory/BladeMemory.h"

namespace Blade
{

    template< typename T >
    class Singleton : public StaticAllocatable
    {
    private:
        Singleton(const Singleton&);
        Singleton& operator=(const Singleton&);
        static void* operator new(size_t);
        static void* operator new[](size_t);

        typedef T*    pointer;
    public:

        /* @brief public reference access */
        static T& getSingleton()
        {
            //lazy initialization
            return *Singleton<T>::operateSingleton();
        }

        /* @brief public pointer access */
        static pointer getSingletonPtr()
        {
            return Singleton<T>::operateSingleton();
        }

    protected:
        Singleton()
        {
        }

        virtual ~Singleton()
        {
            Singleton<T>::operateSingleton(true);
        }

        /* @brief call to create instance */
        static T* operateSingleton(bool reset = false)
        {
            static Lock    msLock;    //spin lock is fast enough, NO NEED for double check, thus no need for memory barrier
            ScopedLock lock(msLock);

            static T* msPtr = NULL;
#if BLADE_DEBUG
            static bool isCreated = false;
#endif

            if( reset )
            {
                assert( msPtr != NULL );
                msPtr = NULL;
                return NULL;
            }

            if( msPtr == NULL )
            {
#if BLADE_DEBUG
                //avoid repeat destroying & creating 2nd time.
                //this usually happens when singleton construction order need explicit control
                assert(isCreated == false);
#endif
                //local static make sure it constructed right on first call
                static T msInstance;

                msPtr = &msInstance;
#if BLADE_DEBUG
                isCreated = true;
#endif
            }
            return msPtr;
        }
    };

}//namespace Blade

#endif // __Blade_Singleton_h__

再次更新:

blade中有类似这样的用法:

//ClientConfig.h
class ClientConfig : public Singleton<ClientConfig>
{
...
};



//main.cc
static ClientConfig cfg(APP_NAME, APP_DESC, APP_VER);

int main()
{
    return 0;
}

//xxx.cc
ClientConfig.getSingleton().xxxx();

这么做只是为了灵活, 然而经过上面的改动以后, 这种方法已经不支持了. 所以又做了小的调整, 兼容这种初始化方式. 具体怎么写就不贴出来了, 应该比较简单.

---

3.构造和析构顺序

先贴以下笔者之前的笔记:

http://wenzhang.baidu.com/page/view?key=0f256d18fe5d14a2-1426750048

http://wenzhang.baidu.com/page/view?key=f06f2a30029f88ef-1426750071

而对于#pragma init_seg这种东西暂时忽略, 因为如果可以通过标准定义可以解决, 那么跨平台和移植性就有保证, 所以尽量不考虑compiler pragma.

对于静态变量的初始化/销毁顺序, 这里就不引用C++03标准的原文了, 简单描述如下:

• 单个编译单元内的静态变量, 按顺序初始化
• 不同编译单元内的静态变量, 初始化顺序是不确定的
• 函数内的局部静态变量, 在第一次执行到变量定义的时候,执行初始化
• 所有静态变量的析构顺序与构造顺序相反, 逆序执行

贴两个blade在开发中遇到的问题:

问题a: 初始化

class A : Singleton<A> {};
class B
{
    B()
    {
        A::getSingleton().xxxx();
    }
};

static B b;

以上情况对于简单模式的singleton没有问题, 单例A会在第一次调用时初始化.
但是对于复杂模式呢?

注意Singleton<A>::msSingleon和b都是非局部静态变量. 对于模板来说, 模板实例化的位置不确定, 不知道在哪个编译单元, 所以可以认为::b和::Singleton<A>::msSingleton的初始化顺序是不确定的.

当b先于Singleton<A>::msSingleton初始化的时候, 由于b的构造调用的A的singleton lazy init,  而后, ::Singleton<A>::msSingleton又接着初始化, 根据用户定义

static T* msSingleton = NULL;

将Singleton<A>::msSingleton指针清空! 这是lazy init在指针初始化之前, 给指针赋值了, 不用去查标准如何定义该行为, 很明显在逻辑上已经错了.

解决方法是不指定initializer, 这样local static的对象只会被清零(zero-initialization), 而且是最先执行清零, 而后不再被赋值.  (C++03: 6.7 Declaration statement: 4).

 static T* msSingleton;

更正: 由于NULL是常量, 所以在编译期已经有值, 实际中可以直接编译到二进制镜像. 而C++对于常量初始化, 跟zero-initialization一样是最开始就有值的, 所以=NULL跟不写是一样的. 可能是时间太长记混了,Blade遇到的应该是msLock对象, 以及智能指针对象. 因为Lock不是常量构造, Lock()初始化函数会在程序加载以后, main之前调用. 这样msLock会有初始化顺序的问题, 只要对Lock制定特殊的初始化函数, 不做任何事情就可以了.

        //static locks maybe accessed/initialized by other pre-main routine(i.e. constructor of other static variables) before its own constructor
        //static constructor:DO NOT initialize members, to avoid reset data
        Lock(const int){}

这样即使Lock在使用以后调用intializer也没有问题了.

题外: C++的NULL被定义为0, 所以清零没有问题. 而且指针可以被隐式转换为bool, 所以C++是鼓励用户使用if( ptr )的, 而C没有明确规定NULL的值, 甚至在某些机器上, NULL 不是0.所以if(ptr)对于C来说就"呵呵"了.而blade的代码全部是C++, 但全使用类似if( ptr == NULL )的格式, 这个只是习惯而已. 当然理论上(NULL == ptr)更好.

 

问题b: 析构

然而再看下面的情况:

class A: Singelton<A> {}
class B: Singleton<B>
{
    ~B()
    {
        A::getSingleton().xxxx();
    }
};

B在析构时依赖了A, 所以必须要求A在B之前构造. 但是由于lazy init的原因, 方便嘛, 可能使用的时候就很随意, 导致没有控制初始化顺序, 那么析构顺序也不对了.

但对于简单模式的Singleton, 至少顺序还是能控制的:

B::getSingleton().xxxx();  //lazy init of B
...
A::getSingleton().xxxx(); //lazy init of A

把上面的代码改为:

A::getSingleton();         //force (explicit) init of A,B: A must construct before B
B::getSingleton();
...

B::getSingleton().xxxx();
...
A::getSingleton().xxxx();
...

这样A在B之前初始化, 所以A能够在B之后析构.

而对于复杂模式的Singlton, 因为使用的是指针. 为了完成lazy de-init, 将msSingleton, 改为智能指针, 这样可以自动析构. 同样为了解决问题a, 这个智能指针不能有initializer, 或者initializer为空.

然而, 不同的singleton类内的静态变量msSingletonSP(smart pointer), 由于分布在不同的编译单元内, 其初始化顺序用户无法控制, 所以析构顺序根本无法控制,成了硬伤.

分析: 简单模式(local static object)的单例, 至少是可以控制析构顺序的, 而复杂模式(double check lock), 直接成了硬伤. 那么把简单模式应用到复杂模式, 会怎么样?

local static smart pointer:

T* msSingleton;

T& getSingleton()
{
    if (NULL == msSingleton )
    {
        static Lock msLock;
        ScopeLock lock(msLock);
        if (NULL == msSingleton )
        {
            static SMART_PTR<T> p;
            p = new T;
            msSingleton = p;
        }
    }
     return *msSingleton;
}

由于local static smart pointer的存在, 就可以控制lazy de-init的顺序了. 这种模式对于问题a和问题b都可以解决顺序问题. 对于问题b, 因为初始化顺序比较随意, 除非事先仔细分析, 否则要等析构出问题了才能修复.

然而lazy init就是为了方便, 使程序员可以不管这些细节, 集中精力做业务逻辑. 所以等出了问题再改也不是不能接受. 至少析构顺序是可控制的, 而不像之前, 那么痛苦的根本不能控制顺序.

为了方便检测问题b, 不至于崩溃在深层调用后, 还要费神查看调用栈, 加上一个assert提前拦截到错误就可以了.

T* msSingleton;
 
~Singleton()
{
    msSingleton = NULL;
}

T& getSingleton()
{
    if (NULL == msSingleton )
    {
        static bool isCreated = false;
        assert( isCreated == false ); //avoid create for the second time, this usually happens when singleton construction order need explicit control

        static Lock msLock;
        ScopeLock lock(msLock);
        isCreated = true;
        if (NULL == msSingleton )
        {
            static SMART_PTR<T> p;
            p = new T;
            msSingleton = p;
         }
     }
     return *msSingleton;
}

在这种情况下, Singleton析构时msSington会被清空. 如果之后还有调用, 那么就会触发assertion failure.

因为这种情况非常少, blade至今遇到过3-5次, 如果遇到了, 调整一下调用顺序, 或则按上面问题b的处理方式, 提前显式调用一次, 强制初始化就可以了.

个人以为, 这种方式比纯静态变量要方便, 不用仔细分析依赖. 况且, 即便提前分析了依赖, 为了稳健性, 往往还要加上assert确保依赖没有出错, 而singleton将assert写入模板, 避免了重复手写.

上面的两个问题是blade的singleton在开发中遇到的典型问题, 理论上可能还有其他问题没有记录, 或者没有遇到也没有解决, 但是俗话说, 车到山前必有路, 总会有个解决方案的, 比如修改设计和实现等等.

只要singleton的初始化顺序是用户(程序猿)可控的, 而不是无序执行, 用户无法控制, 问题都好说.

比如在问题a中, 如果也有析构的依赖: A在B之后析构.那么要求A在B之前构造, 可以多加一个静态变量:

class A : Singleton<A> {}
class B
{
    B()
    {
        A::getSingleton().xxxx();
    }
    ~B()
    {
        A::getSingleton().yyyy();
    }
};

template <typename T> class SingletonInitializer
{
    SingletonInitializer()
    {
        T::getSingleton();
    }
};

static SingletonInitializer<A> c;
static B b;

4. 动态库(.DLL/.so)的导出

如果Singleton没有用模板, 那么这个问题可以忽略. 如果使用了模板, 那么就得考虑动态库导出的问题了, 这个问题可以转化为模板类的导出问题:
[原]DLL导出实例化的模板类

GCC对于MSVC, 区别比较大, 细节先不写了, 主要的原理和思路笔者在这中间提到一些:

[原]跨平台编程注意事项(三): window 到 android 的 移植

具体细节有空了再补上.

5.内存模型

singleton 需要考虑内存管理吗? 绝大多数情况都不需要. 然而对于笔者这样一个完美主义的强迫症来说, 一想到lazy init的singleton在程序运行的任何时间, 都有可能申请一块内存(第一次初始化时), 并且永不释放, 就心里别扭.

会不会产生内存碎片? 理论上会. 况且一个singleton object内部还有数据, 这些数据也是同样的问题.

一种方式是在double check lock的内部, 仍然使用local static object, 而不使用local static smart pointer, 这样静态变量的内存不是动态分配(堆内存), 不需要特殊的管理. 这种方式最简单, 也是目前blade使用的方案.

//note: DO NOT specify a initializer for it
//Otherwise some early lazy initialization will be overwritten by initializer.
T* msSingleton;

Singleton()
{
    assert(msSingleton == NULL );
    msSingleton = static_cast<T*>(this);
}
 
~Singleton()
{
    msSingleton = NULL;
}

T& getSingleton()
{
    if (NULL == msSingleton )
    {
        static bool isCreated = false;
         assert( isCreated = false ); //avoid create for the second time, this usually happens when singleton construction order need explicit control

        static Lock msLock;
        ScopeLock lock(msLock);
        isCreated = true;
        if (NULL == msSingleton )
        {
            static volatile T p;
            assert( msSingleton == &p );
         }
     }
     return *msSingleton;
}

如果是local static smart pointer, 那么需要动态分配, 由于blade已经有static memory pool, 所以这里也用上了, 将singleton 对象占用的内存, 放在static memory pool中. 不过缺点是, 这样让singleton的实现变得又更加复杂了...

 虽然看起来并不是那么复杂:

template<typename T> class Singleton : public StaticAllocatable
{
...
};

 不过前面也提到了, 即便使用local static object, 但是singleton也有可能是new出来的, 如果这种情况允许, 虽然情况不多, 加上内存管理会更好. 这样即便使用smart pointer也没有问题了.

singleton的内存管理思路, 是基于生命周期的内存管理, 笔者在另一个博客也简单提了思路:

[原]基于内存生命周期的内存管理

显然static memory不是为singleton专门设计的, 它的用处也不止于此, 比如游戏的database, 等等各种静态数据, 都可以放入static pool中去. singleton只是享受了一下便利罢了.

还比如对应的还有标准容器扩展, 只要实现了符合std标准的allocator就可以了. 比如staticvector, staticmap static set等等, 这些都可以作为singleton object的成员变量来使用.

不过内存管理是另一个巨话题, 这里不能多说了, 否则又将是另一个长篇大论了.

6.抽象单例

Abstract/Interface Singleton