問題

在設計模式中，有一個很經典的模式-單例模式，它可能是實現上最簡單的模式，在程式碼中也經常使用，在單執行緒下，毫無疑問延遲化載入是比較常用的，但是在多執行緒條件下，單例模式的延遲載入可能就會出現一些問題。

如以下的程式碼：

T* GetInstance()
{
	if (pInst == NULL)
	{
		pInst = new T;
	}
	return pInst;
}

如果檢測程式碼和例項化程式碼不是同一執行緒，則很容易出現返回NULL的現象。

經典的單例模式下的雙重檢測

解決以上問題就是加併發鎖，我們將需要例項化的物件加鎖，於是有了以下程式碼：

T* GetInstance
 
()
{
	if (pInst == NULL)
	{
		lock();
		if (pInst == NULL)
			pInst = new T;
		unlock();
 	}
 	return pInst;
}

為什麼要用兩層if檢查，第一層的if檢查是因為當例項為空的時候，才去對例項加鎖，這樣可以避免多次對lock資源的呼叫，當第二層if檢測的時候，才是程式要對程式進行初始化。

乍看這種程式碼是沒有問題的，但是問題的來源是CPU的亂序執行，C++的New操作實際上包含了兩個步驟：

1. 分配記憶體
2. 呼叫建構函式

所以pInst = new T包含了三個步驟：

1. 分配記憶體
2. 在記憶體的位置上呼叫建構函式
3. 將記憶體的地址賦值給pInst

因為(2)和(3)是可以顛倒的，所以可以出現這樣的情況：pInst的值已經不是NULL，但物件仍然沒有構造完畢。如果另外一個執行緒對GetInstance的呼叫，此時第一個if為false，這樣就會返回一個未構造完成的物件，此時可能會導致程式崩潰。

解決思路

許多體系結構都提供barrier指令，POWERPC提供了其中一條名為lwsync的指令，我們可以這樣來保證執行緒安全:

#define barrier() __asm__ volatile ("lwsyc")
volatile T* pInst = 0;
T* GetInstance()
{
	if
 
 (!pInst) 
	{
		lock();
		if (!pInst)
		{
			T* temp = new T;
			barrier()
			pInst = temp;
		}
		unlock();
	}
	return pInst;
}

由於barrier的存在，物件的構造一定會在barrier執行之前完成，所以這樣不會出現一些問題。