熟悉的味道——從Java單例寫到C++單例-有解無憂

設計模式中，單例模式是常見的一種，單例模式需要滿足以下兩個條件：

保證一個類只能創建一個示例；
提供對該實體的全域訪問點，

關于單例最經典的問題就是DCL(Double-Checked Lock)，今天就此問題展開敘述，

1 Java單例

1.1 通用的寫法

public class Singleton {

    private Singleton() {}
    public static Singleton INSTANCE = new Singleton();
}

最簡單的做法就是如上寫法，在類被加載的時候就初始化其靜態變數INSTANCE，因為JLS（Java Language Specification）中規定一個類只會被初始化一次，因此這樣就可以實作一個樸實的單例類，

1.2 延遲加載單例

需求是多變的，部分人可能因為單例類的資源負擔較重，想要其在需要的時候再進行初始化(Lazy initialization)，這樣也簡單，加把鎖就滿足你的需求，

public class Singleton {

    private Singleton() {}
    private static Singleton INSTANCE = null;
    public static synchronized Singleton getInstance() {
        if (null == INSTANCE) {
            INSTANCE = new Singleton();
        }
        return INSTANCE;
    }
}

但是挑剔的人又提出了需求，引入synchronized之后，多執行緒訪問單例，會因為synchronized導致訪問串行化，這性能上很不好看，程式員于是只能去進行優化，想到了DCL，于是BUG就被引入了，

public class Singleton {

    private Singleton() {}
    private static Singleton INSTANCE = null;
    public static Singleton getInstance() {
        if (null == INSTANCE) {
            synchronized (Singleton.class) {
                if (null == INSTANCE) {
                    INSTANCE = new Singleton();
                }
            }
        }
        return INSTANCE;
    }
}

這是一段看上去很優美的代碼，程式員在判斷INSTANCE為空，加鎖進行賦值時，還貼心的考慮到了可能存在多個執行緒同時判斷INSTANCE是否為空的情況，如果加鎖后發現INSTANCE被快一步的執行緒賦值了，那么我就直接回傳此INSTANCE，
但是計算機的套路太多了，BUG就出現在INSTANCE = new Singleton()這一句代碼上，這一句并不是原子操作，細分下去實際上可以被拆分為以下三個步驟：

分配Singleton物件的記憶體空間；
初始化Singleton物件(完成一些field賦值操作，本文為了篇幅，沒填充field)；
INSTANCE指向分配的記憶體空間，

假如計算機嚴格的按照這個方式執行，那么DCL沒錯，可是CPU為了效率，代碼可能會被亂序執行，假如執行緒A的指令被亂序為：

分配Singleton物件的記憶體空間；
INSTANCE指向分配的記憶體空間；
初始化Singleton物件，

執行緒B假如在執行到第二步的時候拿到了INSTANCE物件(此時并未初始化)，并且快速的傳給應用使用，那么一些美好的事情即將發生（至于是什么，我當然是不曉得的），

1.3 正確的DCL

2000年，一群致力于Java高性能開發者聚集在一起，發表了著名的文章 The "Double-Checked Locking is Broken" Declaration，
文章中討論了關于DCL的各種嘗試，比如使用ThreadLocal(雖然在老版本的代碼中，可能效率會較低，但是為了正確性這是可以忍受的)，不過文章的最后，大家最欣賞的辦法就是使用volatile修飾INSTANCE物件(加入記憶體屏障)，

public class Singleton {

    private Singleton() {}
    private static volatile Singleton INSTANCE = null;
    public static Singleton getInstance() {
        if (null == INSTANCE) {
            synchronized (Singleton.class) {
                if (null == INSTANCE) {
                    INSTANCE = new Singleton();
                }
            }
        }
        return INSTANCE;
    }
}

奏效的原因在于，對volatile物件的寫操作不能被重排序到之前對volatile物件的讀寫操作之前，對volatile物件的讀操作不能被重排序到之后對volatile的讀寫操作之后（如果對這段翻譯不甚理解，可以見下面貼著的原文，其實大概的意思就是告訴CPU別重排序了），當然，享受福利就需要付出一些代價，就是升級jdk至1.5及之后的版本(估計總是會有人守著歷史版本，就像鎖死在三體的百度，堅持XP優于WIN10的人們，我真的很respect)，

JDK5 and later extends the semantics for volatile so that the system will not allow a write of a volatile to be reordered with respect to any previous read or write, and a read of a volatile cannot be reordered with respect to any following read or write.

2 C++單例

2.1 加入記憶體屏障

讓我感興趣的是，在The "Double-Checked Locking is Broken一文中，各位大佬列舉了關于C++如何正確實作DCL的做法(加入記憶體屏障)，并且他們熱心的貼出了代碼，如下所示：

// C++ implementation with explicit memory barriers
// Should work on any platform, including DEC Alphas
// From "Patterns for Concurrent and Distributed Objects",
// by Doug Schmidt
template <class TYPE, class LOCK> TYPE *
Singleton<TYPE, LOCK>::instance (void) {
    // First check
    TYPE* tmp = instance_;
    // Insert the CPU-specific memory barrier instruction
    // to synchronize the cache lines on multi-processor.
    asm ("memoryBarrier");
    if (tmp == 0) {
        // Ensure serialization (guard
        // constructor acquires lock_).
        Guard<LOCK> guard (lock_);
        // Double check.
        tmp = instance_;
        if (tmp == 0) {
                tmp = new TYPE;
                // Insert the CPU-specific memory barrier instruction
                // to synchronize the cache lines on multi-processor.
                asm ("memoryBarrier");
                instance_ = tmp;
        }
    return tmp;
}

如果跟Java的代碼進行比較，會發現和Java的DCL基本類似，只不過有兩處顯式插入了記憶體屏障(即asm處)，此外，此段代碼使用了RCU（read-copy-update），即先獲取需要讀取或者創建的數值（此處就是tmp）,在檢測tmp是合法的數值之后，最后更新到instance_變數中去，通過RCU保證了在創建以及賦值的程序中，不會干擾到別的執行緒（假使失敗，那么也不會污染instance_數值，不過在C++編程中，new失敗了不如直接爆炸吧，這樣死的明明白白一點），

關于RCU的用法，可以參見stackoverflow的RCU大討論，

不過以上方法看似美好，但是在不同的平臺上，記憶體屏障的添加方式也是存在差異，這就導致了你沒法寫出可移植的代碼，甚至是依賴于特定編譯器和特定環境的代碼，這里就存在一個疑問，C++ 中也含有volatile，是否可以參考Java的代碼，使用volatile添加記憶體屏障，答案很悲傷，C++ 的volatile和Java的volatile存在區別，無法照搬（關于此區別，可能在后續會寫文章進行講解），

2.2 找一個類似于volatile的幫手

C++ 11中引入了std::atomic以及std::memory_order，有了標準庫的定義，我們就能夠寫出在絕大多數平臺下可移植的C++代碼，此處，我們要了解一個概念，std::atomic的默認數值是std::memory_order_seq_cst，這是一個永遠安全卻又代價昂貴的記憶體屏障，其作用是在所有CPU(或者核心)中，保持嚴格的代碼線性執行順序，

std::atomic<Singleton*> Singleton::m_instance;
std::mutex Singleton::m_mutex;

Singleton* Singleton::getInstance() {
    Singleton* tmp = m_instance.load();
    if (tmp == nullptr) {
        std::lock_guard<std::mutex> lock(m_mutex);
        tmp = m_instance.load();
        if (tmp == nullptr) {
            tmp = new Singleton;
            m_instance.store(tmp);
        }
    }
    return tmp;
}

使用std::atomic，利用編譯器提供的庫，現在DCL就能夠保證代碼的線性執行順序，代碼在多個平臺上也能夠保證通用性(假如不能保證，我們還能對編譯器要求再多嗎)，
然而C++開發者向來以追求性能為己任，還能快一點，再快一點嗎？當然能了，這段代碼存在的問題恰恰就是全部代碼都是順序執行，我們只需要對部分執行代碼做出順序保證即可，

2.3 精確控制順序

std::atomic<Singleton*> Singleton::m_instance;
std::mutex Singleton::m_mutex;

Singleton* Singleton::getInstance() {
    Singleton* tmp = m_instance.load(std::memory_order_relaxed);
    // 保證在獲取單例指標時，其他執行緒如果在創建單例物件
    // 這些操作，包括創建Singleton物件以及其成員變數的初始化，對于當前執行緒都是可見的
    std::atomic_thread_fence(std::memory_order_acquire);
    if (tmp == nullptr) {
        std::lock_guard<std::mutex> lock(m_mutex);
        tmp = m_instance.load(std::memory_order_relaxed);
        if (tmp == nullptr) {
            tmp = new Singleton;
            // 保證后續陳述句，存盤tmp指標時，new Singleton已經執行結束
            // 最重要的是，tmp的創建以及Singleton的內部初始化操作，對于其他執行緒均是可見的
            std::atomic_thread_fence(std::memory_order_release);
            m_instance.store(tmp, std::memory_order_relaxed);
        }
    }
    return tmp;
}

我們對代碼進行了修改，此處使用atomic_thread_fence實作關鍵位置的記憶體屏障，每次獲取或存盤變數m_instance，均使用memory_order_relaxed，保證單例的指標操作時原子操作，那么，存在的疑問就在于指標所指向的內容是不是跟隨著原子操作，被同步過來了呢？
答案不是，指標是原子操作，但是指標的內容并未保證同步，因此我們需要使用std::atomic_thread_fence(std::memory_order_acquire)以及std::atomic_thread_fence(std::memory_order_release)去保證指標存放的內容被正確的同步了（詳見代碼中的注釋內容），

關于std::atomic_thread_fence，這個確實很晦澀，知乎上wangyongcong
給出的例子，我覺得很是恰當，以下摘抄過來，

Thread A	Thread B
release-fence	atomic-load
atomic-store	acquire-fence

存在執行緒A與B，A上的release-fence之后的atomic-store操作，如果對B的atomic-load操作可見，那么A的release-fence與B的atomic-load同步(sync-with)；另一方面，B的atomic-load操作后跟acquire-fence，如果執行緒A的atomic-store所做出的的修改對該atomic-load可見，那么A的atomic-store與B的acquire-fence同步，
A的release-fence與B的acquire-fence構成了一個同步點，在時間軸上，如果A的release-fence在B的acquire-fence錢，那么A在release-fence之間的所有操作，也都在B的acquire-fence之前，同時也將在B的acquire-fence的后繼操作之前，簡單點，就是release-fence之前的所有store，對acquire-fence之后都是可見的，

補充：
1.上面所提到的atomic load/store均是指對同一個atmoic變數操作；
2.fence必須跟atomic變數共同作用才能起到一致性作用，離開atomic變數，那么無效，

通過使用std::atmoic以及std::atomic_thread_fence，大大的縮小了單例的同步范圍，這樣也就讓CPU有了更大的自由去實作優化（指令亂序本身就是為了提升處理效率，為了性能，我們還是得捏著鼻子忍受這件事情），

2.4 站在巨人的肩膀上

下面介紹一個單例的正確做法，那就是寄托于pthread庫已實作安全的單例，下面這段代碼摘抄于陳碩的muduo代碼中（省略了部分代碼），他對此做法的解釋是，如果pthread_once都不能保證單例的執行緒安全，那么我們的代碼就讓他崩潰吧(總不能讓我們再去修改pthread庫吧)，

template<typename T>
class Singleton : noncopyable
{
 public:
  // 對于C++開發者，使用delete以及boost::noncopyable真的是一個好習慣
  Singleton() = delete;
  ~Singleton() = delete;

  static T& instance()
  {
    pthread_once(&ponce_, &Singleton::init);
    assert(value_ != NULL);
    return *value_;
  }

 private:
  static pthread_once_t ponce_;
  static T*             value_;
};

2.5 讓我們時髦一些

雖然嘴上說著時髦，其實概念很老舊，那就是借助于C++ 11中的local static去正確的實作單例（其本質上，是讓編譯器去幫助我們完成那些復雜的同步操作，保證我們的代碼盡可能的less），以下是C++ 11關于local static的描述（翻譯過來就是在多執行緒呼叫的情況下，local static只會被初始化一次），

If control enters the declaration concurrently while the variable is being initialized, the concurrent execution shall wait for completion of the initialization.

于是，我們的代碼終于可以精簡到一個很完美的地步（比Java的版本還要易于理解，不過需要注意，這要求我們的編譯器支持C++ 11，或者說使用GCC 4.0以上版本，雖然GCC 4.0及以上的若干版本不完美支持C++ 11，但是它支持local static特性）：

T& Singleton()
{
    static T instance;
    return instance;
}

這個寫法太完美了，不過我還是不喜歡延遲加載，更傾向于在main函式執行之前就初始化靜態單例變數（Java稍簡單，一個宣告陳述句就可以，C++需要在類外執行初始化），

class Singleton: boost::noncopyable
{
private:
	static Singleton instance;
public:
	Singleton() = delete;
	~Singleton() = delete;
public:
	static Singleton& getInstance() {
		return instance;
	}
}

// 類外進行初始化操作
Singleton Singleton::instance;

PS:
如果您覺得我的文章對您有幫助，請關注我的微信公眾號，謝謝!

轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/91704.html

標籤：C++

上一篇：delphi可以開發 mt4呼叫的DLL嗎

下一篇：編譯出錯，不知道什么原因