C++单例并发问题和析构顺序问题

Posted on 2020-11-03 Edited on 2020-11-05

简单单例的问题
Take Aways
参考文献

单例模式本身很简单，就是为一个类只创建一个对象。并在全局引用这个对象。单例模式包含了两层涵义：

一个类只有一个对象
这个对象会被全局访问
要实现一个简单的单例也很容易：

class A {
public:
    static A *GetInstance() {
        if (a != nullptr) {
            a = new A;
        }
        return a;
    }
private:
    A *a;
};

这里我故意用了一个千疮百孔的单例实现。下面我就列出这个单例的问题。

简单单例的问题

谁来释放这个对象？

因为a是一个指针，指针变量是一个POD（plain of data）变量。所以没有人会帮你调用A的析构函数。这可能会造成内存泄漏。但进程退出时，所有该进程分配的内存和系统资源都会被标记成释放。但如果这里涉及到线程，情况会有些许不同。一个joinable线程，如果不在进程结束前join，就会发生资源泄漏，产生僵尸线程。但这不是本文想重点阐述的问题。因为释放这种单例内存的方法有很多，比如：

定义一个deletor类，再定义一个static的deletor对象，并在deletor对象中释放a
直接用局部静态变量
或者将A *a定义成智能指针

如何处理并发？

如果GetInstance函数被并发访问，上面的简单单例实现会有并发问题。即a可能被重复赋值，从而产生了几个野对象。解决这个问题比较优雅点的办法就是用std::call_once，如下：

class A {
public:
    static A& GetInstance() {
        std::once_flag flag;
        std::call_once(flag, []()(
            if (a != nullptr) {
                a = new A;
            }
        });
        return *a;
    }
private:
    A *a;
};

这里返回值从指针，变成了引用。言下之意，单例的获取在程序整个生命周期内从来不会失败。不过这是理想状况，在某些模型下，我们不得不让单例返回空指针。
另外，C++11的语言规范定义了局部静态对象的构造析构行为，确保其只会被构造一次。所以在C++11及以上的场景下，最优雅的代码如下：

class A {
public:
    A& GetInstance() {
        static A a;
        return a;
    }
};

这就是著名的Meyer's Singleton，既简洁又不会犯错，可惜只能用于C++11以后的版本。

析构顺序？

可以引出今天的主角了。单例模式如何处理析构问题？上面的优雅的单例实现中，C++11规范规定，局部静态变量a，在第一次调用GetInstance函数时构造。由于a是static变量且未被初始化，会被直接放入.bss段，所以只要程序一加载，这段内存已经存在了，只是A类的构造函数还未被调用。当GetInstance被第一次调用时，a对象所占用的存储空间会被A的构造函数初始化。

对象a什么时候会被析构呢？

首先，A的析构函数由编译器插入的代码，在main函数退出之后调用。
其次，C++规范规定析构顺序一定是构造顺序的逆序。由于局部静态变量晚于全局变量被构造，所以局部静态变量晚于全局变量析构。全局变量析构也晚于gcc标签__attribute__((destructor))定义的函数。所以顺序如下：

main ==> 局部静态变量 ==> __attribute__((destructor)) ==> 全局变量。

析构引入的问题

这里最大的问题，就出在单例的对象。一个单例对象其实就是一个全局名字空间下的全局变量。而对于整个程序名字空间下的全局变量们的构造顺序，C++规范并没有明确说明。他依赖于编译，链接和库加载的顺序。请一定注意这一点。因为他打开了一个潘多拉魔盒，各种析构问题因此而生。
请设想这样一种情况，假如B依赖A的某种方法，但因为单例，B可以轻松避过与A建立构造依赖关系，如下：

class B{
public:
    ～B() {
        A &a = A::GetInstance();
        a.func();
    }
};

B可能先于A构造也可能后于A构造。如果B的构造函数调用了A::GetInstance，那么A就先于B构造，且A后于B析构。上面的调用成立。
假如，B的构造没调用A::GetInstance，那么可能B析构中调用A的函数（例如：a.func()）就会造成崩溃。解决这个问题的办法，很简单，请记住当类之间有依赖关系的时候，请用代码固化这个依赖关系。例如：

class B{
public:
    B(A& a) {}; // <== 这一行确保了B依赖A，B构造的时候，A的单例已经构造好了
    ～B() {
        A &a = A::GetInstance();
        a.func();
    }
};

虽然解决方法很简单，但其实很容易被忽略，因为人们都讨厌依赖和耦合。但别忘了显式依赖要远好于隐式依赖。如果要依赖就光明正大的做，不要暗戳戳的做，因为那是掩耳盗铃，而且会引入很多问题。

C++实现提供C语言接口引入的析构问题

这个问题才是最让人头疼的问题。因为C语言是无状态的，所以C语言的接口，可能在任意时候调用。例如：

void c_func() {
    A &a = A::GetInstance();
    a.func();
}

class D {
public:
    ~D() {
        c_func();
    }
}

现在D根本就不知道A的存在，他只知道c_func这个接口，因为class D和c_func是来自两个团队，甚至两个公司或两个社区。于是在某个程序里定义的D对象，在某个全局变量析构时调用了c_func，从而触发了a.func，而此时可能a已经释放了，因为a对象可能晚于D对象的构建，所以早于D对象析构。这是完全有可能的。
特别在A是一个复杂类的情况下，特别容易引入问题，而你一无所知。因为这个问题并不是一定发生，只是会碰巧发生，按照墨菲定律，往往是在最严重的时候发生。例如：

class A {
public:
    static A& GetInstance() {
        static A a;
        return a;
    }
private:
    std::vector arr;
};

这里仅仅引入了一个std::vector，情况就会很严重。因为std::vector里有内存分配，这些内存都是malloc出来的。在vector析构的时候，这些内存毫无疑问会被释放。那么当A的单例在析构之后被调用的时候，虽然A本身的内存还在，但他的成员分配出的内存已经不在了。**一旦发生引用这些已释放的内存，行为就是不确定的。**coredump已经是比较好的结果了。如果没发生coredump，就会为产品留下一个漏洞，从而成为攻击的后门。

解法也有，但是代码会变的既啰嗦又丑陋。思路是，借用shared_ptr和weak_ptr的县城安全特性，实现析构时的内存保护。

class A { // 错误的示例，仅为阐述思路
public:
    static std::shared_ptr<A> GetInstance() {
        static std::shared_ptr<A> a = new A;
        static std::weak_ptr<A> ref = a;
        return ref.lock();
    }
};

只可惜这段简洁的代码并不能完成我们的目标。因为std::weak_ptr<A> ref也会被析构。而weak_ptr中的manager object是在构造时被new出来的，在weak_ptr析构时，会被释放(参考[1])。如果weak_ptr已经被析构，再调用ref.lock()则会访问野指针。要解决ref析构以后访问的问题，代码就会变的很长。不在这里列出完整的代码了。给出思路：

class A {
public:
    static std::shared_ptr<A> GetInstance() {
        static std::shared_ptr<A> a = new A;
        static MyWeakPtr<A> ref = a;
        return ref.Acquire();
    }
};

template<class T>
class MyWeakPtr {
public:
    explicit MyWeakPtr(const std::shared_ptr<T> ptr) : destroyed(0), data(ptr){}
    ~MyWeakPtr() {
        AtomicLockGuard lk(&destroyedLock);
        destroyed = 1;
    }
    
    std::shared_ptr<T> Acquire() {
        AtomicLockGuard lk(&destroyedLock);
        if (!destoryed) { // line1
            return data.lock(); // line2
        }
        return nullptr;
    }
private:
    int destroyed;
    std::weak_ptr<T> data;
    AtomicLock destroyedLock;
}

这里的核心思想是用自定义的MyWeakPtr替代标准库的weak_ptr。而自定义的MyWeakPtr除了std::weak_ptr外，不再含有任何堆上分配的内存。这也保证了析构后的安全访问。剩下的就是保证，weak_ptr析构后不再被访问到。思路是通过一个原子锁来保护一个析构的标志位。确保，析构后，weak_ptr不再被访问。
这里还有一个隐蔽的线程安全问题。

如果MyWeakPtr顺利拿到line1这一行的锁。如果weak_ptr在line1-line2之间进入析构，由于此时析构被原子锁阻挡，无法完成，weak_ptr的内存在析构完成之前是不会被释放的。所以line2可以在weak_ptr被析构前完成调用。因为shared_ptr先于weak_ptr构造，所以shared_ptr后于weak_ptr析构。所以此时shared_ptr必然还有效，所以可以通过weak_ptr锁住shared_ptr，使其不会被析构。
后续shared_ptr被析构后，由于析构顺序的关系，此时weak_ptr必然已完成析构函数，则代码执行会选择destructor==1的分支，而不会执行weak_ptr.lock操作。

综上所述，本实现是线程安全的。

另外一点值得注意的是，这里将GetInstance改为返回智能指针，即单例析构后的访问，可能返回nullptr，以示对象已经不存在了。但这样的设计势必会引起各处nullptr的判断，这里比较适合使用Null Object设计模式。

class A {
public:
    static std::shared_ptr<A> GetInstance() {
        static std::shared_ptr<A> a = new A;
        static MyWeakPtr<A> ref = a;
        auto b = ref.Acquire();
        if (b == nullptr) {
            return NullObjA::GetInstance();
        }
        return b;
    }
};
    ...
};

class NullObjA : public A {
public:
    void func() override {}
    static GetInstance();
    
private:
    static NullObjA nullA;
}

这里NullObjA不存在析构问题，因为这个对象里只有一个vptr，啥都没有，而这个指针是静态对象nullA的附属物，其占有的内存在nullA分配的时候分配，在nullA构造的时候，被赋值。而且nullA的内存是静态的全局数据区，是不会被释放的。所以对他的引用是安全的。
好了，到此算是把这个问题解掉了，对比一下代码，相比最优雅的Meyer's Singleton，这里已经多出很多行了。

Take Aways

如果是纯C++项目，请用依赖关系解决析构问题
如果是C/C++混编项目，请慎重提供全局对象（包括单例），尤其是复杂的全局对象。
如果非提供不可，请考虑线程安全和析构安全

参考文献

[1] C++ 智能指针（shared_ptr/weak_ptr）源码分析

[2] shared_ptr源码：shared_ptr_base.h, shared_ptr.h

[3] 当析构函数遇到多线程 ── C++ 中线程安全的对象回调