探究Singleton設計模式
2024-07-21 02:19:25
供稿：網友
[簡介]
上期我們刊登了jeffrey richter的《探究observer模式》，詳細講解了在微軟架構下實現observer模式的技術和經驗。本期我們繼續探討設計模式方面的話題。singleton通常被認為是最簡單的設計模式，很多初學者都是通過它來了解設計模式的含義。然而，熟悉設計模式的技術人員都知道，要正確實現singleton模式實際上是非常難的，涉及到很多技術細節。本文對于singleton做了大膽深入的研究，并且探討了c++、java和c#中的singleton實現。
在開發軟件應用程序過程中，隨著應用程序的開發，會出現重復性的模式。隨著整個軟件系統的開發，很多相同的模式會逐漸顯現出來。
這種重復性模式概念在其他應用中是非常明顯的。汽車制造就是一種此類應用。很多不同的汽車型號使用相同的子構件，包括大多數基本部件（例如，燈泡和緊固零件）以及較大的構件（例如，底盤和發動機）。
在住宅建筑中，重復性模式概念適用于螺絲和螺釘以及整體總體建筑物配電系統。無論組建的小組是為了開發新的汽車設計還是新的建筑物設計，它通常不必沒有考慮到以前已解決的問題。如果設計和建筑住宅的小組必須重新構思和設計房子的每一個組成部分，則整個過程所花的時間比現在要長得多。門高或燈開關功能等許多設計決策（例如，門高或燈開關功能）很容易理解。房為滿足給房子不同部分提供洗手功能的要求，房屋設計師不必重新設計和重新建造不同類型的輸供水和蓄水設施，以便達到為房子不同部分提供洗手功能的要求：標準水槽以及標準的熱水和冷水輸入接頭和排水輸出接頭是很容易理解非常常見的房屋建筑構件。可以將重復性模式概念反復應用于我們周圍的幾乎每樣東西上，包括軟件。
汽車和住宅建筑示例有助于在軟件設計和構造中體現某些一般性的抽象概念。易于理解且明確定義的通用功能部件的概念是設計模式的源動力，它也是其他兩篇設計模式文章探究工廠設計模式和探究觀察者設計模式的重點。這些模式幾乎涵蓋了面向對象的軟件設計的各個方面，包括對象創建、對象交互和對象生存期。在本文中，我們將討論singleton模式，它包含在創造性模式系列中。
創造性模式指示如何以及何時創建對象。很多實例需要只能通過創造性方法解決的特殊行為，而不是在創建實例后強制實施所需的行為。此類行為要求最好的例子之一包含在singleton模式中。singleton模式在《設計模式：可復用的面向對象軟件的基礎》這一經典參考書目中有正式的定義，該書的作者包括erich gamma、richard helm、ralph johnson和john vlissides（也稱為四人組或gof）。在設計模式中，此模式是最簡單也是使用最廣泛的模式之一。但是，正如我們將會看到的一樣，在實現此模式時可能會出現一些問題。本文試圖通過singleton模式的多個早期實現來從頭開始分析singleton模式，以及如何在microsoft .net應用程序開發中發揮其最佳用途。
singleton模式
按照設計模式中的定義，singleton模式的用途是“ensure a class has only one instance, and provide a global point of access to it（確保每個類只有一個實例，并提供它的全局訪問點）”。
它可以解決什么問題，或者換句話說，我們使用它的動機是什么？幾乎在每個應用程序中，都需要有一個從中進行全局訪問和維護某種類型數據的區域。在面向對象的(oo)系統中也有這種情況，在此類系統中，在任何給定時間只應運行一個類或某個類的一組預定義數量的實例。例如，當使用某個類來維護增量計數器時，此簡單的計數器類需要跟蹤在多個應用程序領域中使用的整數值。此類需要能夠增加該計數器并返回當前的值。對于這種情況，所需的類行為應該僅使用一個類實例來維護該整數，而不是使用其它類實例來維護該整數。
最初，人們可能會試圖將計數器類實例只作為靜態全局變量來創建。這是一種通用的方法，但實際上只解決一部分問題；它解決了全局可訪問性問題，但沒有采取任何措施來確保在任何給定的時間只運行一個類實例。應該由類本身來負責只使用一個類實例，而不是由類用戶來負責。應該始終不要讓類用戶來監視和控制運行的類實例的數量。
所需要的是使用某種方法來控制如何創建類實例，然后確保在任何給定的時間只創建一個類實例。這會確切地給我們提供所需的行為，并使客戶端不必了解任何類細節。
邏輯模型
singleton模型非常簡單直觀。（通常）只有一個singleton實例。客戶端通過一個已知的訪問點來訪問singleton實例。在這種情況下，客戶端是一個需要訪問唯一singleton實例的對象。圖1以圖形方式顯示此關系。
物理模型
singleton模式的物理模型也是非常簡單的。但是，隨著時間的推移，實現singleton的方式也略有不同。讓我們看一下原始的gofsingleton實現。圖2顯示按設計模式所定義的原始singleton模式的uml模型。
我們看到的是一個簡單的類圖表，顯示有一個singleton對象的私有靜態屬性以及返回此相同屬性的公共方法instance()。這實際上是singleton的核心。還有其他一些屬性和方法，用于說明在該類上允許執行的其他操作。為了便于此次討論，讓我們將重點放在實例屬性和方法上。
客戶端僅通過實例方法來訪問任何singleton實例。此處沒有定義創建實例的方式。我們還希望能夠控制如何以及何時創建實例。在oo開發中，通常可以在類的構造函數中最好地處理特殊對象的創建行為。這種情況也不例外。我們可以做的是，定義我們何時以及如何構造類實例，然后禁止任何客戶端直接調用該構造函數。這是在singleton構造中始終使用的方法。讓我們看一下設計模式中的原始示例。通常，將下面所示的c++singleton示例實現代碼示例視為singleton的默認實現。本示例已移植到很多其他編程語言中，通常它在任何地方的形式與此幾乎相同。
c++singleton示例實現代碼
//declaration
class singleton{
public:
static singleton* instance();
protected:
singleton();
private:
static singleton* _instance;
}
// implementation
singleton* singleton::_instance = 0;
singleton* singleton::instance() {
if (_instance == 0) {
_instance = new singleton;
}
return _instance;
}
讓我們先花點時間分析一下此代碼。該簡單類有一個成員變量，此變量是指向該類自身的指針。注意，構造函數是受保護的，并且只有公共方法才是實例方法。在實例方法實現中，有一個控制塊(if)，它檢查成員變量是否已初始化，如果沒有的話，則創建一個新實例。控制塊中這種惰性初始化意味著僅在第一次調用instance()方法時初始化或創建singleton實例。對于很多應用程序，這種方法效果很好。但對于多線程應用程序，這種方法證明具有潛在危險的副作用。如果兩個線程同時進入控制塊，則可能會創建該成員變量的兩個實例。要解決這一問題，您可能想只將重要部分放在控制塊周圍以確保線程安全。如果您這樣做，則將對實例方法的所有調用進行序列化處理，并且可能會對性能產生不利影響（取決于應用程序）。正是由于這個原因，創建了此模式的另一個版本，它使用某種稱為雙重檢驗機制的功能。下一個代碼示例顯示使用java語法的雙重檢驗鎖定。
使用java語法的雙重檢驗鎖定singleton代碼
//c++ port to java
class singleton
{
public staticsingletoninstance() {
if (_instance == null) {
synchronized (class.forname("singleton")) {
if (_instance == null) {
_instance = new singleton();
}
}
}
return _instance;
}
protected singleton() {}
private staticsingleton_instance = null;
}
在使用java語法的雙重檢驗鎖定singleton代碼示例中，我們直接將c++代碼移植到java代碼，以便利用java關鍵部分塊（已同步）。主要差別是不再有單獨的聲明和實現部分，沒有指針數據類型，并且采用了新的雙重檢驗機制。雙重檢驗發生在第一個if塊上。如果成員變量為空，則執行進入關鍵部分塊，該塊再次雙重檢驗該成員變量。僅在通過此最終測試后，才會實例化該成員變量。一般來說，兩個線程無法使用這種方法創建兩個類實例。另外，因為在第一次檢查時沒有出現線程阻塞，所以對此方法的大多數調用不會由于必須進入鎖定而導致性能下降。目前，在實現singleton模式時，很多java應用程序中都廣泛使用這種方法。這種方法很巧妙，但也有瑕疵。某些優化編譯器可以將惰性初始化代碼優化掉或對其重新進行排序，并且會重新產生線程安全問題。有關更深入的解釋，請參閱"the double-check locking is broken" （http://www.cs.umd.edu/~pugh/java/memorymodel/doublecheckedlocking.html）。
另一種試圖解決此問題的方法可能是，在成員變量聲明中使用volatile關鍵字。這應該告訴編譯器不要對代碼重新排序，并且放棄優化。目前，這是唯一建議的jvm內存模型，并且不會立即解決該問題。
實現singleton的最好方法是什么？最終（而不是碰巧），microsoft .net框架解決了所有這些問題，從而更易于實現singleton，卻不會產生我們目前討論的不利副作用。.net框架以及c#語言允許我們在必要時通過替換語言關鍵字，將上述的java語法移植到c#語法。因此，singleton代碼變為以下內容：
以c#編碼的雙重檢驗鎖定
// port to c#
class singleton
{
public staticsingletoninstance() {
if (_instance == null) {
lock (typeof(singleton)) {
if (_instance == null) {
_instance = new singleton();
}
}
}
return _instance;
}
protected singleton() {}
private static volatilesingleton_instance = null;
}
此處，我們替換了鎖定關鍵字來執行關鍵部分塊，使用typeof操作并添加volatile關鍵字，以確保沒有對代碼進行優化程序重新排序。雖然此代碼或多或少是gofsingleton模式的直接移植，但它可達到我們的目的，并且我們可獲得所需的行為。此代碼還說明了將c++移植到java和將java移植到c#代碼的一些相似之處和主要差別。但是，正如任何代碼移植一樣，通常目標語言或平臺的一些優點可能在移植過程中失去。需要做的就是對代碼重構，以便利用新目標語言或平臺的功能。
在前面的每個代碼示例中，singleton的原始實現隨時間的推移而發生變化，以解決在每個新模式實現中發現的問題。一些問題（例如，線程安全）要求對大多數實現進行更改，以滿足在目前應用程序中日益增長的需要并解決演變發展問題。.net在應用程序開發中提供了一個演變步驟。可以在“框架”級別解決前面示例中出現的很多亟待解決的問題，而不是在實現級別解決。雖然上一個示例顯示了一個使用.net框架和c#的有效singleton類，但只需更好地利用.net框架本身就可以大大簡化此代碼。以下示例使用.net，它是一個松散地基于原始gof模式的最小限度的singleton類，并且仍然可獲得類似的行為。
.netsingleton示例
//.net singleton
sealed class singleton
{
private singleton() {}
public static readonlysingletoninstance = new singleton();
}
此版本已大大簡化并且更加直觀。它仍然是singleton嗎？讓我們看一下更改了哪些內容，然后再做決定。我們修改了要密封的類本身（該類密封后是不可繼承的），刪除了惰性初始化代碼，刪除了instance()方法，并且對_instance變量做了大量的修改。對_instance變量所做的更改包括修改對公共方法的訪問級別，將變量標記為只讀，以及在聲明時初始化該變量。此處，我們可以直接定義所需的行為，而不關心實現的潛在有害的副作用。那么，使用惰性初始化有什么優點以及使用多個線程有什么危險呢？在.net框架中內置了所有正確的行為。讓我們先看第一種情況：惰性初始化。
最初使用惰性初始化的主要原因是要獲取僅在第一次調用instance()方法中創建實例的行為，還因為c++規范中具有某種開放性，并不定義靜態變量的確切初始化順序。要在c++中獲得所需的singleton行為，必須采用涉及使用惰性初始化的運算方法。我們真正關心的是在第一次（在該情況下）調用實例屬性中創建該實例，還是在此調用之前創建該實例的，并且類中的靜態變量是否有已定義的初始化順序。對于.net框架，這就是我們獲取的行為。在jit過程中，當（且僅當）任何方法使用靜態屬性時，“框架”將初始化此靜態屬性。如果沒有使用該屬性，則不會創建實例。更準確地說，在jit過程中發生的事情就是，在任何調用方使用該類的任何靜態成員時構造和加載該類。在這種情況下，結果是相同的。
那么，線程安全初始化呢？“框架”也解決了這一問題。“框架”內部保證靜態類型初始化的線程安全。換句話說，在上面的示例中，只創建一個singleton類實例。還要注意，用于保存類實例的屬性字段稱為實例。此選項更好地說明了，在本文中的討論過程中，此值是類的實例。在“框架”本身中，雖然使用的屬性名稱稱為值，但有多個類使用此類型的singleton。概念完全相同。
對類所做的其他更改意味著禁止劃分子類。添加密封類修飾符可確保不會將該類劃分為子類。gofsingleton模式詳細介紹了試圖對singleton劃分子類所產生的問題，該劃分通常并不是小事。在大多數情況下，可以很容易地開發沒有父類的singleton，并且添加劃分子類功能會增加通常根本不需要的新的復雜性級別。隨著復雜性的提高，測試、培訓和文檔編制等所需的時間也會增加。通常，除非絕對必要，否則您不希望提高任何代碼的復雜性。
讓我們看一下如何使用singleton。使用我們最初的計數器的有關動機的概念，我們可以創建一個簡單的singleton計數器類并說明我們將如何使用它。圖3顯示了uml類說明將包含什么內容。
相應的類實現代碼以及示例客戶端使用如下所示。
示例singleton使用
sealed class singletoncounter {
public static readonly singletoncounter instance =
new singletoncounter();
private long count = 0;
private singletoncounter() {}
public long nextvalue() {
return ++count;
}
}
class singletonclient {
[stathread]
static void main() {
for (int i=0; i<20; i++) {
console.writeline("nextsingletonvalue: {0}",
singletoncounter.instance.nextvalue());
}
}
}
此處，我們還創建了一個singleton類來維護具有long類型的增量計數。客戶端是一個簡單的控制臺應用程序，它顯示計數器類的20個值。雖然此示例極其簡單，但它卻說明了如何使用.net來實現singleton，然后將其用在應用程序中。
小結
singleton設計模式是一個非常有用的機制，可用于在面向對象的應用程序中提供單個對象訪問點。無論使用的是什么實現，該模式提供一個大家所熟知的概念，以便其在設計和開發小組之間方便地進行共享。但是，正如我們所發現的一樣，注意到這些實現有多大差異及其潛在的副作用也是非常重要的。.net框架為模式實現者在設計所需的功能類型方面提供了很大的幫助，實現者無需處理本文中所討論的很多副作用。在正確實現后，可以證實模式的最初目的的有效性。
設計模式是非常有用的軟件設計概念，可使小組將重點放在提供最佳類型的應用程序上，而不考慮它們是什么應用程序。關鍵在于正確而有效地使用設計模式，目前有很多關于將設計模式用于microsoft .net方面的msdn系列文檔，其中介紹了如何正確而有效地使用設計模式。
