[C++知识库]奇异递归模板模式(Curiously Recurring Template Pattern)与在单例模式中的使用

奇异递归模板模式

? ? ? ? 奇异递归模板模式(Curiously Recurring Template Pattern，CRTP)，CRTP是C++模板编程时的一种惯用法（idiom）：把派生类作为基类的模板参数。更一般地被称作F-bound polymorphism。

1980年代作为F-bound polymorphism被提出。Jim Coplien于1995年称之为CRTP。

CRTP在C++中主要有两种用途：

• 静态多态（static polymorphism）
• 添加方法同时精简代码

1.静态多态

先看一个简单的例子：

#include <iostream>
using namespace std;

template <typename Child>
struct Base
{
	void interface()
	{
		static_cast<Child*>(this)->implementation();
	}
};

struct Derived : Base<Derived>
{
	void implementation()
	{
		std::cout << "Derived implementation\n";
	}
};

int main()
{
	Derived d;
	d.interface();  // Prints "Derived implementation"

	return 0;
}

????????这里基类Base为模板类，子类Drived继承自Base同时模板参数为Drived，基类中有接口interface而子类中则有接口对应实现implementation，基类interface中将this通过static_cast转换为模板参数类型，并调用该类型的implemention方法。由于Drived继承基类时的模板为Drived类型所以在static_cast时会转换为Drived并调用Drived的implemention方法。(注意这里采用的时static_cast而不是dynamic_cast，因为只有继承了Base的类型才能调用interface且这里是向下转型，所以采用static_cast是安全的。)

????????通过CRTP可以使得类具有类似于虚函数的效果，同时又没有虚函数调用时的开销(虚函数调用需要通过虚函数指针查找虚函数表进行调用)，同时类的对象的体积相比使用虚函数也会减少(不需要存储虚函数指针)，但是缺点是无法动态绑定。

下面是关于静态多态的第二个例子：

template<typename Child>
class Animal
{
public:
	void Run()
	{
		static_cast<Child*>(this)->Run();
	}
};

class Dog :public Animal<Dog>
{
public:
	void Run()
	{
		cout << "Dog Run" << endl;
	}
};

class Cat :public Animal<Cat>
{
public:
	void Run()
	{
		cout << "Cat Run" << endl;
	}
};

template<typename T>
void Action(Animal<T> &animal)
{
	animal.Run();
}

int main()
{
	Dog dog;
	Action(dog);

	Cat cat;
	Action(cat);
	return 0;
}

????????这里Dog继承自Animal且模板参数为Dog，Cat继承自Animal且模板参数为Cat，Animal，Dog，Cat中都声明了Run，而Animal中的Run是通过类型转换后调用模板类型的Run方法实现的。在Action模板函数中接收Animal类型的引用(或指针)并在其中调用了animal对象的Run方法，由于这里传入的是不同的子类对象，因此Action中的animal也会有不同的行为。

2.添加方法，减少冗余

????????假设现在我们需要实现一个数学运算库，我们需要支持Vector2，Vector3，Vector4...等类型，如果我们将每个类分别声明并实现如下：

//Vec3
struct Vector3
{
	float x;
	float y;
	float z;

	Vector3() = default;

	Vector3(float _x, float _y, float _z);

	inline Vector3& operator+=(const Vector3& rhs);
	inline Vector3& operator-=(const Vector3& rhs);
	//....
};

inline Vector3 operator+(const Vector3& lhs, const Vector3& rhs);
inline Vector3 operator-(const Vector3& lhs, const Vector3& rhs);
//....

//Vec2
struct Vector2
{
	float x;
	float y;

	Vector2() = default;

	Vector2(float _x, float _y);

	inline Vector2& operator+=(const Vector2& rhs);
	inline Vector2& operator-=(const Vector2& rhs);
	//....
};

inline Vector2 operator+(const Vector2& lhs, const Vector2& rhs);
inline Vector2 operator-(const Vector2& lhs, const Vector2& rhs);
//....

我们会发现需要为每个类型都实现+=, -= ,++ , -- , + , -等运算符重载，而且每个类型的一些运算符，行为都很类似，而且可以使用其他的运算符进行实现，比如+=, -=, ++, --都可以采用+，-运算符进行实现。这时我们就可以采用CRTP抽离出这些共同的类似方法，减少代码的冗余：

template<typename T>
struct VectorBase
{
	T& underlying() { return static_cast<T&>(*this); }
	T const& underlying() const { return static_cast<T const&>(*this); }

	inline T& operator+=(const T& rhs) 
	{ 
		this->underlying() = this->underlying() + rhs;
		return this->underlying();
	}

	inline T& operator-=(const T& rhs)
	{
		this->underlying() = this->underlying() - rhs;
		return this->underlying();
	}
	
	//.....
};

struct Vector3 : public VectorBase<Vector3>
{
	float x;
	float y;
	float z;

	Vector3() = default;

	Vector3(float _x, float _y, float _z)
	{
		x = _x;
		y = _y;
		z = _z;
	}
};

inline Vector3 operator+(const Vector3& lhs, const Vector3& rhs)
{
	Vector3 result;
	result.x = lhs.x + rhs.x;
	result.y = lhs.y + rhs.y;
	result.z = lhs.z + rhs.z;
	return result;
}

inline Vector3 operator-(const Vector3& lhs, const Vector3& rhs)
{
	Vector3 result;
	result.x = lhs.x - rhs.x;
	result.y = lhs.y - rhs.y;
	result.z = lhs.z - rhs.z;
	return result;
}
//......

int main()
{
	Vector3 v0(6.0f, 5.0f, 4.0f);
	Vector3 v2(4.0f, 5.0f, 6.0f);

	v0 += v2;
	v0 -= v2;

	return 0;
}

通过把+=， -=等操作放到基类中并采用+ ,-运算符实现，这样一来所有继承自VectorBase的类，只要其定义了+，-运算符就可以自动获得+=, -=等运算符，这样大大的减少了代码中的冗余。

在有多个类型存在相同方法，且这些方法可以借助于类的其他方法进行实现时，均可以采用CRTP进行精简代码。

3 std::enable_shared_from_this

假如在c++中想要在一个已被shareptr管理的类型对象内获取并返回this，为了防止被管理的对象已被智能指针释放，而导致this成为悬空指针，可能会考虑以share_ptr的形式返回this指针，代码实现如下：

struct Bad
{
    // 错误写法：用不安全的表达式试图获得 this 的 shared_ptr 对象
    std::shared_ptr<Bad> getptr() {
        return std::shared_ptr<Bad>(this);
    }
    ~Bad() { std::cout << "Bad::~Bad() called\n"; }
};

int main()
{
	{
		// 错误的示例，每个 shared_ptr 都认为自己是对象仅有的所有者
		std::shared_ptr<Bad> bp1 = std::make_shared<Bad>();
		std::shared_ptr<Bad> bp2 = bp1->getptr();
		std::cout << "bp2.use_count() = " << bp2.use_count() << '\n';
	}

	return 0;
}

但是上面的写法是完全错误的，因为share_ptr内部存储了两个指针，一个指向被管理对象，另一个指向控制块。控制块内存有删除器，占有被管理对象的?shared_ptr?的数量，涉及被管理对象的?weak_ptr?的数量等信息，一旦占有被管理对象的shared_ptr的数量减少至0，被管理的对象就会通过删除器被释放（控制块会等到weakptr计数器也清0时才会释放）。上面的代码中由于在返回this的sharedptr时，又通过this指针构造了一个shared_ptr，这样就会导致有两个shared_ptr通过不同的控制块，管理相同的对象。一旦其中一个shared_ptr释放了所管理的对象，那么另一个shared_ptr将会变成非法的。

而正确的写法应该是让需要返回this指针的类，继承std::enable_shared_from_this模板类，同时模板参数为该类的类型：

struct Good: std::enable_shared_from_this<Good> // 注意：继承
{
    std::shared_ptr<Good> getptr() {
        return shared_from_this();
    }
};

至于为什么要这样做，可以参见以下的伪代码：

template<class D>
class enable_shared_from_this {
protected:
    constexpr enable_shared_from_this() { }
    enable_shared_from_this(enable_shared_from_this const&) { }
    enable_shared_from_this& operator=(enable_shared_from_this const&) {
        return *this;
    }

public:
    shared_ptr<T> shared_from_this() { return self_; }
    shared_ptr<T const> shared_from_this() const { return self_; }

private:
    weak_ptr<D> self_;

    friend shared_ptr<D>;
};

template<typename T>
shared_ptr<T>::shared_ptr(T* ptr) {
    // ...
    // Code that creates control block goes here.
    // ...

    // NOTE: This if check is pseudo-code. Won't compile. There's a few
    // issues not being taken in to account that would make this example
    // rather noisy.
    if (is_base_of<enable_shared_from_this<T>, T>::value) {
        enable_shared_from_this<T>& base = *ptr;
        base.self_ = *this;
    }
}

enable_shared_from_this类使用了CRTP的写法，类中存储了一个weak_ptr<T>，使用这个weak_ptr<t>初始化shared_ptr<T>时，如果这个类型是否继承自enable_shared_from_this，则会使shared_from_this中构造的shared_ptr<T>共享weak_ptr<T>指向的对象的所有权(即从weak_ptr构造的shared_ptr和构造weak_ptr的shared_ptr共享控制块)(std::shared_ptr::shared_ptr - cppreference.com?参见构造函数11)，这样就可以保证shared_from_this返回的shared_ptr的内存安全，不会像第一个例子那样出现悬空指针。

(enable_shared_from_this中的weak_ptr是通过shared_ptr的构造函数初始化的，所以必须在shared_ptr构造函数调用之后才能调用shared_from_this，而且不能对一个没有被shared_ptr接管的类调用shared_from_this，否则会产生未定义行为)

单例模式 C++

一、什么是单例

单例 Singleton 是设计模式的一种，其特点是只提供唯一一个类的实例,具有全局变量的特点，在任何位置都可以通过接口获取到那个唯一实例;
具体运用场景如：

1. 设备管理器，系统中可能有多个设备，但是只有一个设备管理器，用于管理设备驱动;
2. 数据池，用来缓存数据的数据结构，需要在一处写，多处读取或者多处写，多处读取;

二、C++单例的实现

2.1 基础要点

• 全局只有一个实例：static 特性，同时禁止用户自己声明并定义实例（把构造函数设为 private）
• 线程安全
• 禁止赋值和拷贝
• 用户通过接口获取实例：使用 static 类成员函数

2.2 C++ 实现单例的几种方式

懒汉式

懒汉式(Lazy-Initialization)的方法是直到使用时才实例化对象，也就说直到调用get_instance() 方法的时候才 new 一个单例的对象， 如果不被调用就不会占用内存。

“双检锁”机制

#include <iostream>
#include <memory> 
#include <mutex>  


class Singleton{
public:
    typedef std::shared_ptr<Singleton> Ptr;
    ~Singleton(){
        std::cout<<"destructor called!"<<std::endl;
    }
    Singleton(Singleton&)=delete;
    Singleton& operator=(const Singleton&)=delete;
    static Ptr get_instance(){

        // "double checked lock"
        if(m_instance_ptr==nullptr){
            std::lock_guard<std::mutex> lk(m_mutex);
            if(m_instance_ptr == nullptr){
              m_instance_ptr = std::shared_ptr<Singleton>(new Singleton);
            }
        }
        return m_instance_ptr;
    }


private:
    Singleton(){
        std::cout<<"constructor called!"<<std::endl;
    }
    static Ptr m_instance_ptr;
    static std::mutex m_mutex;
};

// initialization static variables out of class
Singleton::Ptr Singleton::m_instance_ptr = nullptr;
std::mutex Singleton::m_mutex;

int main(){
    Singleton::Ptr instance = Singleton::get_instance();
    Singleton::Ptr instance2 = Singleton::get_instance();
    return 0;
}

shared_ptr和mutex都是C++11的标准，以上这种方法的优点是

• 基于 shared_ptr, 用了C++比较倡导的 RAII思想，用对象管理资源,当 shared_ptr 析构的时候，new 出来的对象也会被 delete掉。以此避免内存泄漏。
• 加了锁，使用互斥量来达到线程安全。这里使用了两个 if判断语句的技术称为双检锁；好处是，只有判断指针为空的时候才加锁，避免每次调用 get_instance的方法都加锁，锁的开销毕竟还是有点大的。

不足之处在于： 使用智能指针会要求用户也得使用智能指针，非必要不应该提出这种约束; 使用锁也有开销; 同时代码量也增多了，实现上我们希望越简单越好。

????????还有更加严重的问题，在某些平台（与编译器和指令集架构有关），双检锁会失效！

????????问题的来源是CPU的乱序执行，C++的New操作实际上包含了两个步骤：

1. 分配内存
2. 调用构造函数

所以m_instance_ptr = std::shared_ptr<Singleton>(new Singleton);包含了三个步骤：

1. 分配内存
2. 在内存的位置上调用构造函数
3. 将内存的地址赋值给m_instance_ptr

因为(2)和(3)是可以颠倒的，所以可以出现这样的情况：pInst的值已经不是NULL，但对象仍然没有构造完毕。如果另外一个线程对GetInstance的调用，此时第一个if为false，这样就会返回一个未构造完成的对象，此时可能会导致程序崩溃。

局部静态变量

#include <iostream>

class Singleton
{
public:
    ~Singleton(){
        std::cout<<"destructor called!"<<std::endl;
    }
    Singleton(const Singleton&)=delete;
    Singleton& operator=(const Singleton&)=delete;
    static Singleton& get_instance(){
        static Singleton instance;
        return instance;

    }
private:
    Singleton(){
        std::cout<<"constructor called!"<<std::endl;
    }
};

int main(int argc, char *argv[])
{
    Singleton& instance_1 = Singleton::get_instance();
    Singleton& instance_2 = Singleton::get_instance();
    return 0;
}

这种方法又叫做 Meyers' SingletonMeyer's的单例， 是著名的写出《Effective C++》系列书籍的作者 Meyers 提出的。所用到的特性是在C++11标准中的Magic Static特性：

If control enters the declaration concurrently while the variable is being initialized, the concurrent execution shall wait for completion of the initialization.
如果当变量在初始化的时候，并发同时进入声明语句，并发线程将会阻塞等待初始化结束。

这样保证了并发线程在获取静态局部变量的时候一定是初始化过的，所以具有线程安全性。

1. 通过局部静态变量的特性保证了线程安全 (C++11, GCC > 4.3, VS2015支持该特性);
2. 不需要使用共享指针，代码简洁；
3. 注意在使用的时候需要声明单例的引用?Single&?才能获取对象。

call_once

call_once - C++ Reference

template <class Fn, class... Args>
  void call_once (once_flag& flag, Fn&& fn, Args&&... args);

在C++11中提供一种方法，使得函数可以线程安全的只调用一次。即使用std::call_once和std::once_flag。std::call_once是一种lazy load的很简单易用的机制

#include<iostream>
#include <mutex>
using namespace std;
class Singleton
{
public:
	static Singleton& getInstance()
	{
		static Singleton* single = nullptr;
		static std::once_flag flag;
		std::call_once(flag, []() {
			if (nullptr == single) {
				single = new Singleton();
			}
			});

		return *single;
	}
private:

	Singleton() { cout << "Singleton()" << endl; }
	~Singleton() { cout << "~Singleton()" << endl; }
	Singleton(const Singleton&);//防止外部使用拷贝构造产生新的对象，如下面CSingleton s = *p1;
};


int main()
{
	Singleton &p1 = Singleton::getInstance();
	Singleton &p2 = Singleton::getInstance();
	Singleton &p3 = Singleton::getInstance();

	return 0;
}

引用还是指针

????????Singleton返回的实例的生存期是由Singleton本身所决定的，而不是用户代码。我们知道，指针和引用在语法上的最大区别就是指针可以为NULL，并可以通过delete运算符删除指针所指的实例，而引用则不可以。由该语法区别引申出的语义区别之一就是这些实例的生存期意义：通过引用所返回的实例，生存期由非用户代码管理，而通过指针返回的实例，其可能在某个时间点没有被创建，或是可以被删除的。但是这两条Singleton都不满足，因此在这里，使用指针，而不是引用

单例模式的复用

CRTP 奇异递归模板模式实现

// brief: a singleton base class offering an easy way to create singleton
#include <iostream>

template<typename T>
class Singleton{
public:
    static T& get_instance(){
        static T instance;
        return instance;
    }
    virtual ~Singleton(){
        std::cout<<"destructor called!"<<std::endl;
    }
    Singleton(const Singleton&)=delete;
    Singleton& operator =(const Singleton&)=delete;
protected:
    Singleton(){
        std::cout<<"constructor called!"<<std::endl;
    }

};
/********************************************/
// Example:
// 1.friend class declaration is requiered!
// 2.constructor should be private


class DerivedSingle:public Singleton<DerivedSingle>{
   // !!!! attention!!!
   // needs to be friend in order to
   // access the private constructor/destructor
   friend class Singleton<DerivedSingle>;
public:
   DerivedSingle(const DerivedSingle&)=delete;
   DerivedSingle& operator =(const DerivedSingle&)= delete;
private:
   DerivedSingle()=default;
};

int main(int argc, char* argv[]){
    DerivedSingle& instance1 = DerivedSingle::get_instance();
    DerivedSingle& instance2 = DerivedSingle::get_instance();
    return 0;
}

以上实现一个单例的模板基类，使用方法如例子所示意，子类需要将自己作为模板参数T?传递给?Singleton<T>?模板; 同时需要将基类声明为友元，这样才能调用子类的私有构造函数。

基类模板的实现要点是：

1. 构造函数需要是?protected，这样子类才能继承；
2. 使用了奇异递归模板模式CRTP(Curiously recurring template pattern)
3. get instance 方法和 2.2.3 的static local方法一个原理。
4. 在这里基类的析构函数可以不需要 virtual ，因为子类在应用中只会用 Derived 类型，保证了析构时和构造时的类型一致

何时应该使用或者不使用单例

c++ - Singleton: How should it be used - Stack Overflow

你需要系统中只有唯一一个实例存在的类的全局变量的时候才使用单例。

• 如果使用单例，应该用什么样子的

How to create the best singleton:

• The smaller, the better. I am a minimalist
• Make sure it is thread safe
• Make sure it is never null
• Make sure it is created only once
• Lazy or system initialization? Up to your requirements
• Sometimes the OS or the JVM creates singletons for you (e.g. in Java every class definition is a singleton)
• Provide a destructor or somehow figure out how to dispose resources
• Use little memory
  越小越好，越简单越好，线程安全，内存不泄露

单例模式缺点：

　“从语法上来讲，首先Singleton模式实际上将类型功能与类型实例个数限制的代码混合在了一起，违反了SRP。其次Singleton模式在Instance()函数中将创建一个确定的类型，从而禁止了通过多态提供另一种实现的可能。”

开源项目中单例的实现方式

Chromium

base\no_destructor.h

// A wrapper that makes it easy to create an object of type T with static
// storage duration that:
// - is only constructed on first access
// - never invokes the destructor
// in order to satisfy the styleguide ban on global constructors and
// destructors.
//
// Runtime constant example:
// const std::string& GetLineSeparator() {
//  // Forwards to std::string(size_t, char, const Allocator&) constructor.
//   static const base::NoDestructor<std::string> s(5, '-');
//   return *s;
// }
//
// More complex initialization with a lambda:
// const std::string& GetSessionNonce() {
//   static const base::NoDestructor<std::string> nonce([] {
//     std::string s(16);
//     crypto::RandString(s.data(), s.size());
//     return s;
//   }());
//   return *nonce;
// }
//
// NoDestructor<T> stores the object inline, so it also avoids a pointer
// indirection and a malloc. Also note that since C++11 static local variable
// initialization is thread-safe and so is this pattern. Code should prefer to
// use NoDestructor<T> over:
// - A function scoped static T* or T& that is dynamically initialized.
// - A global base::LazyInstance<T>.
//
// Note that since the destructor is never run, this *will* leak memory if used
// as a stack or member variable. Furthermore, a NoDestructor<T> should never
// have global scope as that may require a static initializer.
template <typename T>
class NoDestructor {
 public:
  // Not constexpr; just write static constexpr T x = ...; if the value should
  // be a constexpr.
  template <typename... Args>
  explicit NoDestructor(Args&&... args) {
    new (storage_) T(std::forward<Args>(args)...);
  }

  // Allows copy and move construction of the contained type, to allow
  // construction from an initializer list, e.g. for std::vector.
  explicit NoDestructor(const T& x) { new (storage_) T(x); }
  explicit NoDestructor(T&& x) { new (storage_) T(std::move(x)); }

  NoDestructor(const NoDestructor&) = delete;
  NoDestructor& operator=(const NoDestructor&) = delete;

  ~NoDestructor() = default;

  const T& operator*() const { return *get(); }
  T& operator*() { return *get(); }

  const T* operator->() const { return get(); }
  T* operator->() { return get(); }

  const T* get() const { return reinterpret_cast<const T*>(storage_); }
  T* get() { return reinterpret_cast<T*>(storage_); }

 private:
  alignas(T) char storage_[sizeof(T)];

#if defined(LEAK_SANITIZER)
  // TODO(https://crbug.com/812277): This is a hack to work around the fact
  // that LSan doesn't seem to treat NoDestructor as a root for reachability
  // analysis. This means that code like this:
  //   static base::NoDestructor<std::vector<int>> v({1, 2, 3});
  // is considered a leak. Using the standard leak sanitizer annotations to
  // suppress leaks doesn't work: std::vector is implicitly constructed before
  // calling the base::NoDestructor constructor.
  //
  // Unfortunately, I haven't been able to demonstrate this issue in simpler
  // reproductions: until that's resolved, hold an explicit pointer to the
  // placement-new'd object in leak sanitizer mode to help LSan realize that
  // objects allocated by the contained type are still reachable.
  T* storage_ptr_ = reinterpret_cast<T*>(storage_);
#endif  // defined(LEAK_SANITIZER)
};

使用：

// Factory& Factory::GetInstance() {
//   static base::NoDestructor<Factory> instance;
//   return *instance;
// }

base\memory\singleton.h

// Copyright (c) 2011 The Chromium Authors. All rights reserved.
// Use of this source code is governed by a BSD-style license that can be
// found in the LICENSE file.
//
// !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
// PLEASE READ: Do you really need a singleton? If possible, use a
// function-local static of type base::NoDestructor<T> instead:
//
// Factory& Factory::GetInstance() {
//   static base::NoDestructor<Factory> instance;
//   return *instance;
// }
// !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
//
// Singletons make it hard to determine the lifetime of an object, which can
// lead to buggy code and spurious crashes.
//
// Instead of adding another singleton into the mix, try to identify either:
//   a) An existing singleton that can manage your object's lifetime
//   b) Locations where you can deterministically create the object and pass
//      into other objects
//
// If you absolutely need a singleton, please keep them as trivial as possible
// and ideally a leaf dependency. Singletons get problematic when they attempt
// to do too much in their destructor or have circular dependencies.

#ifndef BASE_MEMORY_SINGLETON_H_
#define BASE_MEMORY_SINGLETON_H_

#include "base/at_exit.h"
#include "base/atomicops.h"
#include "base/base_export.h"
#include "base/lazy_instance_helpers.h"
#include "base/logging.h"
#include "base/macros.h"
#include "base/threading/thread_restrictions.h"

namespace base {

// Default traits for Singleton<Type>. Calls operator new and operator delete on
// the object. Registers automatic deletion at process exit.
// Overload if you need arguments or another memory allocation function.
template<typename Type>
struct DefaultSingletonTraits {
  // Allocates the object.
  static Type* New() {
    // The parenthesis is very important here; it forces POD type
    // initialization.
    return new Type();
  }

  // Destroys the object.
  static void Delete(Type* x) {
    delete x;
  }

  // Set to true to automatically register deletion of the object on process
  // exit. See below for the required call that makes this happen.
  static const bool kRegisterAtExit = true;

#if DCHECK_IS_ON()
  // Set to false to disallow access on a non-joinable thread.  This is
  // different from kRegisterAtExit because StaticMemorySingletonTraits allows
  // access on non-joinable threads, and gracefully handles this.
  static const bool kAllowedToAccessOnNonjoinableThread = false;
#endif
};


// Alternate traits for use with the Singleton<Type>.  Identical to
// DefaultSingletonTraits except that the Singleton will not be cleaned up
// at exit.
template<typename Type>
struct LeakySingletonTraits : public DefaultSingletonTraits<Type> {
  static const bool kRegisterAtExit = false;
#if DCHECK_IS_ON()
  static const bool kAllowedToAccessOnNonjoinableThread = true;
#endif
};

// Alternate traits for use with the Singleton<Type>.  Allocates memory
// for the singleton instance from a static buffer.  The singleton will
// be cleaned up at exit, but can't be revived after destruction unless
// the ResurrectForTesting() method is called.
//
// This is useful for a certain category of things, notably logging and
// tracing, where the singleton instance is of a type carefully constructed to
// be safe to access post-destruction.
// In logging and tracing you'll typically get stray calls at odd times, like
// during static destruction, thread teardown and the like, and there's a
// termination race on the heap-based singleton - e.g. if one thread calls
// get(), but then another thread initiates AtExit processing, the first thread
// may call into an object residing in unallocated memory. If the instance is
// allocated from the data segment, then this is survivable.
//
// The destructor is to deallocate system resources, in this case to unregister
// a callback the system will invoke when logging levels change. Note that
// this is also used in e.g. Chrome Frame, where you have to allow for the
// possibility of loading briefly into someone else's process space, and
// so leaking is not an option, as that would sabotage the state of your host
// process once you've unloaded.
template <typename Type>
struct StaticMemorySingletonTraits {
  // WARNING: User has to support a New() which returns null.
  static Type* New() {
    // Only constructs once and returns pointer; otherwise returns null.
    if (subtle::NoBarrier_AtomicExchange(&dead_, 1))
      return nullptr;

    return new (buffer_) Type();
  }

  static void Delete(Type* p) {
    if (p)
      p->Type::~Type();
  }

  static const bool kRegisterAtExit = true;

#if DCHECK_IS_ON()
  static const bool kAllowedToAccessOnNonjoinableThread = true;
#endif

  static void ResurrectForTesting() { subtle::NoBarrier_Store(&dead_, 0); }

 private:
  alignas(Type) static char buffer_[sizeof(Type)];
  // Signal the object was already deleted, so it is not revived.
  static subtle::Atomic32 dead_;
};

template <typename Type>
alignas(Type) char StaticMemorySingletonTraits<Type>::buffer_[sizeof(Type)];
template <typename Type>
subtle::Atomic32 StaticMemorySingletonTraits<Type>::dead_ = 0;

// The Singleton<Type, Traits, DifferentiatingType> class manages a single
// instance of Type which will be created on first use and will be destroyed at
// normal process exit). The Trait::Delete function will not be called on
// abnormal process exit.
//
// DifferentiatingType is used as a key to differentiate two different
// singletons having the same memory allocation functions but serving a
// different purpose. This is mainly used for Locks serving different purposes.
//
// Example usage:
//
// In your header:
//   namespace base {
//   template <typename T>
//   struct DefaultSingletonTraits;
//   }
//   class FooClass {
//    public:
//     static FooClass* GetInstance();  <-- See comment below on this.
//     void Bar() { ... }
//    private:
//     FooClass() { ... }
//     friend struct base::DefaultSingletonTraits<FooClass>;
//
//     DISALLOW_COPY_AND_ASSIGN(FooClass);
//   };
//
// In your source file:
//  #include "base/memory/singleton.h"
//  FooClass* FooClass::GetInstance() {
//    return base::Singleton<FooClass>::get();
//  }
//
// Or for leaky singletons:
//  #include "base/memory/singleton.h"
//  FooClass* FooClass::GetInstance() {
//    return base::Singleton<
//        FooClass, base::LeakySingletonTraits<FooClass>>::get();
//  }
//
// And to call methods on FooClass:
//   FooClass::GetInstance()->Bar();
//
// NOTE: The method accessing Singleton<T>::get() has to be named as GetInstance
// and it is important that FooClass::GetInstance() is not inlined in the
// header. This makes sure that when source files from multiple targets include
// this header they don't end up with different copies of the inlined code
// creating multiple copies of the singleton.
//
// Singleton<> has no non-static members and doesn't need to actually be
// instantiated.
//
// This class is itself thread-safe. The underlying Type must of course be
// thread-safe if you want to use it concurrently. Two parameters may be tuned
// depending on the user's requirements.
//
// Glossary:
//   RAE = kRegisterAtExit
//
// On every platform, if Traits::RAE is true, the singleton will be destroyed at
// process exit. More precisely it uses AtExitManager which requires an
// object of this type to be instantiated. AtExitManager mimics the semantics
// of atexit() such as LIFO order but under Windows is safer to call. For more
// information see at_exit.h.
//
// If Traits::RAE is false, the singleton will not be freed at process exit,
// thus the singleton will be leaked if it is ever accessed. Traits::RAE
// shouldn't be false unless absolutely necessary. Remember that the heap where
// the object is allocated may be destroyed by the CRT anyway.
//
// Caveats:
// (a) Every call to get(), operator->() and operator*() incurs some overhead
//     (16ns on my P4/2.8GHz) to check whether the object has already been
//     initialized.  You may wish to cache the result of get(); it will not
//     change.
//
// (b) Your factory function must never throw an exception. This class is not
//     exception-safe.
//

template <typename Type,
          typename Traits = DefaultSingletonTraits<Type>,
          typename DifferentiatingType = Type>
class Singleton {
 private:
  // A class T using the Singleton<T> pattern should declare a GetInstance()
  // method and call Singleton::get() from within that. T may also declare a
  // GetInstanceIfExists() method to invoke Singleton::GetIfExists().
  friend Type;

  // This class is safe to be constructed and copy-constructed since it has no
  // member.

  // Returns a pointer to the one true instance of the class.
  static Type* get() {
#if DCHECK_IS_ON()
    if (!Traits::kAllowedToAccessOnNonjoinableThread)
      ThreadRestrictions::AssertSingletonAllowed();
#endif

    return subtle::GetOrCreateLazyPointer(
        &instance_, &CreatorFunc, nullptr,
        Traits::kRegisterAtExit ? OnExit : nullptr, nullptr);
  }

  // Returns the same result as get() if the instance exists but doesn't
  // construct it (and returns null) if it doesn't.
  static Type* GetIfExists() {
#if DCHECK_IS_ON()
    if (!Traits::kAllowedToAccessOnNonjoinableThread)
      ThreadRestrictions::AssertSingletonAllowed();
#endif

    if (!subtle::NoBarrier_Load(&instance_))
      return nullptr;

    // Need to invoke get() nonetheless as some Traits return null after
    // destruction (even though |instance_| still holds garbage).
    return get();
  }

  // Internal method used as an adaptor for GetOrCreateLazyPointer(). Do not use
  // outside of that use case.
  static Type* CreatorFunc(void* /* creator_arg*/) { return Traits::New(); }

  // Adapter function for use with AtExit().  This should be called single
  // threaded, so don't use atomic operations.
  // Calling OnExit while singleton is in use by other threads is a mistake.
  static void OnExit(void* /*unused*/) {
    // AtExit should only ever be register after the singleton instance was
    // created.  We should only ever get here with a valid instance_ pointer.
    Traits::Delete(reinterpret_cast<Type*>(subtle::NoBarrier_Load(&instance_)));
    instance_ = 0;
  }
  static subtle::AtomicWord instance_;
};

template <typename Type, typename Traits, typename DifferentiatingType>
subtle::AtomicWord Singleton<Type, Traits, DifferentiatingType>::instance_ = 0;

}  // namespace base

#endif  // BASE_MEMORY_SINGLETON_H_

?????????单例使得很难确定对象的生命周期，如果你绝对需要一个单例，请让它们尽可能简单。理想情况下是叶子依赖。 否则会遇到问题：在它们的析构函数中做太多或有循环依赖。

????????其中

????????DefaultSingletonTraits：提供了new 和delete 方法，在进程退出时调用析构函数

????????LeakySingletonTraits：进程退出时不会清理

????????StaticMemorySingletonTraits：内存分配在静态缓冲区：这对于特定类别的事物很有用，尤其是日志记录。基于堆的单例的终止竞争：如果一个线程调用get()，但随后另一个线程启动 AtExit 处理，第一个线程可以调用驻留在未分配内存中的对象。如果实例是从数据段分配，那么这是可存活的。

base\lazy_instance_helpers.h

template <typename Type>
Type* GetOrCreateLazyPointer(subtle::AtomicWord* state,
                             Type* (*creator_func)(void*),
                             void* creator_arg,
                             void (*destructor)(void*),
                             void* destructor_arg) {
  DCHECK(state);
  DCHECK(creator_func);

  // If any bit in the created mask is true, the instance has already been
  // fully constructed.
  constexpr subtle::AtomicWord kLazyInstanceCreatedMask =
      ~internal::kLazyInstanceStateCreating;

  // We will hopefully have fast access when the instance is already created.
  // Since a thread sees |state| == 0 or kLazyInstanceStateCreating at most
  // once, the load is taken out of NeedsLazyInstance() as a fast-path. The load
  // has acquire memory ordering as a thread which sees |state| > creating needs
  // to acquire visibility over the associated data. Pairing Release_Store is in
  // CompleteLazyInstance().
  subtle::AtomicWord instance = subtle::Acquire_Load(state);
  if (!(instance & kLazyInstanceCreatedMask)) {
    if (internal::NeedsLazyInstance(state)) {
      // This thread won the race and is now responsible for creating the
      // instance and storing it back into |state|.
      instance =
          reinterpret_cast<subtle::AtomicWord>((*creator_func)(creator_arg));
      internal::CompleteLazyInstance(state, instance, destructor,
                                     destructor_arg);
    } else {
      // This thread lost the race but now has visibility over the constructed
      // instance (NeedsLazyInstance() doesn't return until the constructing
      // thread releases the instance via CompleteLazyInstance()).
      instance = subtle::Acquire_Load(state);
      DCHECK(instance & kLazyInstanceCreatedMask);
    }
  }
  return reinterpret_cast<Type*>(instance);
}

base\lazy_instance_helpers.cc

void CompleteLazyInstance(subtle::AtomicWord* state,
                          subtle::AtomicWord new_instance,
                          void (*destructor)(void*),
                          void* destructor_arg) {
  // Instance is created, go from CREATING to CREATED (or reset it if
  // |new_instance| is null). Releases visibility over |private_buf_| to
  // readers. Pairing Acquire_Load is in NeedsLazyInstance().
  subtle::Release_Store(state, new_instance);

  // Make sure that the lazily instantiated object will get destroyed at exit.
  if (new_instance && destructor)
    AtExitManager::RegisterCallback(destructor, destructor_arg);
}

使用：

// Trace provider class to drive log control and transport
// with Event Tracing for Windows.
class BASE_EXPORT LogEventProvider : public base::win::EtwTraceProvider {
 public:
  static LogEventProvider* GetInstance();

  static bool LogMessage(logging::LogSeverity severity, const char* file,
      int line, size_t message_start, const std::string& str);

  static void Initialize(const GUID& provider_name);
  static void Uninitialize();

 protected:
  // Overridden to manipulate the log level on ETW control callbacks.
  void OnEventsEnabled() override;
  void OnEventsDisabled() override;

 private:
  LogEventProvider();

  // The log severity prior to OnEventsEnabled,
  // restored in OnEventsDisabled.
  logging::LogSeverity old_log_level_;

  friend struct base::StaticMemorySingletonTraits<LogEventProvider>;
  DISALLOW_COPY_AND_ASSIGN(LogEventProvider);
};

声明友元类：? friend struct base::StaticMemorySingletonTraits<LogEventProvider>;

对外提供：?static LogEventProvider* GetInstance();

构造函数:private

base\logging_win.cc

LogEventProvider* LogEventProvider::GetInstance() {
  return base::Singleton<LogEventProvider, base::StaticMemorySingletonTraits<
                                               LogEventProvider>>::get();
}

protobuf

namespace google {
namespace protobuf {
namespace internal {
template<typename T>
class Singleton {
 public:
  static T* get() {
    GoogleOnceInit(&once_, &Singleton<T>::Init);
    return instance_;
  }
  static void ShutDown() {
    delete instance_;
    instance_ = NULL;
  }
 private:
  static void Init() {
    instance_ = new T();
  }
  static ProtobufOnceType once_;
  static T* instance_;
};

template<typename T>
ProtobufOnceType Singleton<T>::once_;

template<typename T>
T* Singleton<T>::instance_ = NULL;
}  // namespace internal
}  // namespace protobuf
}  // namespace google

参考：

面试中的Singleton - loveis715 - 博客园

C++ 单例模式总结与剖析 - 行者孙 - 博客园

1.The Curiously Recurring Template Pattern (CRTP)

2.The cost of dynamic (virtual calls) vs. static (CRTP) dispatch in C++

奇异递归模板模式(Curiously Recurring Template Pattern) - 知乎

1. https://zh.cppreference.com/w/cpp/memory/enable_shared_from_this
2. std::shared_ptr - cppreference.com
3. How std::enable_shared_from_this::shared_from_this works
4. enable_shared_from_this类的作用和实现 - 杨文的博客 - 博客园
5. 关于boost中enable_shared_from_this类的原理分析 - 阿玛尼迪迪 - 博客园