Java設計模式

Java設計模式的六大原則

設計模式六大原則（1）：單一職責原則

​ 單一職責原則(Single Responsibility Principle, SRP)：一個類只負責一個功能領域中的相應職責，或者可以定義爲：就一個類而言，應該只有一個引起它變化的原因。
​ 問題由來：類T負責兩個不同的職責：職責P1，職責P2。當由於職責P1需求發生改變而需要修改類T時，有可能會導致原本運行正常的職責P2功能發生故障。
​ 解決方案：遵循單一職責原則。分別建立兩個類T1、T2，使T1完成職責P1功能，T2完成職責P2功能。這樣，當修改類T1時，不會使職責P2發生故障風險；同理，當修改T2時，也不會使職責P1發生故障風險。
​ 單一職責原則告訴我們：一個類不能太“累”！在軟件系統中，一個類（大到模塊，小到方法）承擔的職責越多，它被複用的可能性就越小，而且一個類承擔的職責過多，就相當於將這些職責耦合在一起，當其中一個職責變化時，可能會影響其他職責的運作，因此要將這些職責進行分離，將不同的職責封裝在不同的類中，即將不同的變化原因封裝在不同的類中，如果多個職責總是同時發生改變則可將它們封裝在同一類中。

       單一職責原則是實現高內聚、低耦合的指導方針，它是最簡單但又最難運用的原則，需要設計人員發現類的不同職責並將其分離，而發現類的多重職責需要設計人員具有較強的分析設計能力和相關實踐經驗。
​ 下面通過一個簡單實例來進一步分析單一職責原則：

​ Sunny軟件公司開發人員針對某CRM（Customer Relationship  Management，客戶關係管理）系統中客戶信息圖形統計模塊提出瞭如圖1所示初始設計方案：

​ 圖1  初始設計方案結構圖

​ 在圖1中，CustomerDataChart類中的方法說明如下：getConnection()方法用於連接數據庫，findCustomers()用於查詢所有的客戶信息，createChart()用於創建圖表，displayChart()用於顯示圖表。

​ 現使用單一職責原則對其進行重構：

​ 在圖1中，CustomerDataChart類承擔了太多的職責，既包含與數據庫相關的方法，又包含與圖表生成和顯示相關的方法。如果在其他類中也需要連接數據庫或者使用findCustomers()方法查詢客戶信息，則難以實現代碼的重用。無論是修改數據庫連接方式還是修改圖表顯示方式都需要修改該類，它不止一個引起它變化的原因，違背了單一職責原則。因此需要對該類進行拆分，使其滿足單一職責原則，類CustomerDataChart可拆分爲如下三個類：

      (1) DBUtil：負責連接數據庫，包含數據庫連接方法getConnection()；

      (2) CustomerDAO：負責操作數據庫中的Customer表，包含對Customer表的增刪改查等方法，如findCustomers()；

      (3) CustomerDataChart：負責圖表的生成和顯示，包含方法createChart()和displayChart()。

      使用單一職責原則重構後的結構如圖2所示：

​ 圖2  重構後的結構圖

設計模式六大原則（2）：開閉原則

​ 開閉原則(Open-Closed Principle, OCP)：一個軟件實體應當對擴展開放，對修改關閉。即軟件實體應儘量在不修改原有代碼的情況下進行擴展。

​  在開閉原則的定義中，軟件實體可以指一個軟件模塊、一個由多個類組成的局部結構或一個獨立的類。

      任何軟件都需要面臨一個很重要的問題，即它們的需求會隨時間的推移而發生變化。當軟件系統需要面對新的需求時，我們應該儘量保證系統的設計框架是穩定的。如果一個軟件設計符合開閉原則，那麼可以非常方便地對系統進行擴展，而且在擴展時無須修改現有代碼，使得軟件系統在擁有適應性和靈活性的同時具備較好的穩定性和延續性。隨着軟件規模越來越大，軟件壽命越來越長，軟件維護成本越來越高，設計滿足開閉原則的軟件系統也變得越來越重要。

      爲了滿足開閉原則，需要對系統進行抽象化設計，抽象化是開閉原則的關鍵。在Java、C#等編程語言中，可以爲系統定義一個相對穩定的抽象層，而將不同的實現行爲移至具體的實現層中完成。在很多面向對象編程語言中都提供了接口、抽象類等機制，可以通過它們定義系統的抽象層，再通過具體類來進行擴展。如果需要修改系統的行爲，無須對抽象層進行任何改動，只需要增加新的具體類來實現新的業務功能即可，實現在不修改已有代碼的基礎上擴展系統的功能，達到開閉原則的要求。

實例：

 Sunny軟件公司開發的CRM系統可以顯示各種類型的圖表，如餅狀圖和柱狀圖等，爲了支持多種圖表顯示方式，原始設計方案如圖1所示：

​ 圖1 初始設計方案結構圖

​ 在本實例中，由於在ChartDisplay類的display()方法中針對每一個圖表類編程，因此增加新的圖表類不得不修改源代碼。可以通過抽象化的方式對系統進行重構，使之增加新的圖表類時無須修改源代碼，滿足開閉原則。具體做法如下：

      (1) 增加一個抽象圖表類AbstractChart，將各種具體圖表類作爲其子類；

      (2)  ChartDisplay類針對抽象圖表類進行編程，由客戶端來決定使用哪種具體圖表。

      重構後結構如圖2所示：

​ 圖2 重構後的結構圖

      在圖2中，我們引入了抽象圖表類AbstractChart，且ChartDisplay針對抽象圖表類進行編程，並通過setChart()方法由客戶端來設置實例化的具體圖表對象，在ChartDisplay的display()方法中調用chart對象的display()方法顯示圖表。如果需要增加一種新的圖表，如折線圖LineChart，只需要將LineChart也作爲AbstractChart的子類，在客戶端向ChartDisplay中注入一個LineChart對象即可，無須修改現有類庫的源代碼。    

       注意：因爲xml和properties等格式的配置文件是純文本文件，可以直接通過VI編輯器或記事本進行編輯，且無須編譯，因此在軟件開發中，一般不把對配置文件的修改認爲是對系統源代碼的修改。如果一個系統在擴展時只涉及到修改配置文件，而原有的Java代碼或C#代碼沒有做任何修改，該系統即可認爲是一個符合開閉原則的系統。

設計模式六大原則（3）：里氏替換原則

​ 里氏代換原則(Liskov Substitution Principle, LSP)：所有引用基類（父類）的地方必須能透明地使用其子類的對象。

​ 里氏代換原則告訴我們：在軟件中將一個基類對象替換成它的子類對象，程序將不會產生任何錯誤和異常，反過來則不成立，如果一個軟件實體使用的是一個子類對象的話，那麼它不一定能夠使用基類對象。例如：我喜歡動物，那我一定喜歡狗，因爲狗是動物的子類；但是我喜歡狗，不能據此斷定我喜歡動物，因爲我並不喜歡老鼠，雖然它也是動物。

      例如有兩個類，一個類爲BaseClass，另一個是SubClass類，並且SubClass類是BaseClass類的子類，那麼一個方法如果可以接受一個BaseClass類型的基類對象base的話，如：method1(base)，那麼它必然可以接受一個BaseClass類型的子類對象sub，method1(sub)能夠正常運行。反過來的代換不成立，如一個方法method2接受BaseClass類型的子類對象sub爲參數：method2(sub)，那麼一般而言不可以有method2(base)，除非是重載方法。

      里氏代換原則是實現開閉原則的重要方式之一，由於使用基類對象的地方都可以使用子類對象，因此在程序中儘量使用基類類型來對對象進行定義，而在運行時再確定其子類類型，用子類對象來替換父類對象。

​ 在使用里氏代換原則時需要注意如下幾個問題：

      (1)子類的所有方法必須在父類中聲明，或子類必須實現父類中聲明的所有方法。根據里氏代換原則，爲了保證系統的擴展性，在程序中通常使用父類來進行定義，如果一個方法只存在子類中，在父類中不提供相應的聲明，則無法在以父類定義的對象中使用該方法。

      (2) 在運用里氏代換原則時，儘量把父類設計爲抽象類或者接口，讓子類繼承父類或實現父接口，並實現在父類中聲明的方法，運行時，子類實例替換父類實例，我們可以很方便地擴展系統的功能，同時無須修改原有子類的代碼，增加新的功能可以通過增加一個新的子類來實現。里氏代換原則是開閉原則的具體實現手段之一。

      (3) Java語言中，在編譯階段，Java編譯器會檢查一個程序是否符合里氏代換原則，這是一個與實現無關的、純語法意義上的檢查，但Java編譯器的檢查是有侷限的。

實例：

​ 在Sunny軟件公司開發的CRM系統中，客戶(Customer)可以分爲VIP客戶(VIPCustomer)和普通客戶(CommonCustomer)兩類，系統需要提供一個發送Email的功能，原始設計方案如圖1所示：

​ 圖1原始結構圖

      在對系統進行進一步分析後發現，無論是普通客戶還是VIP客戶，發送郵件的過程都是相同的，也就是說兩個send()方法中的代碼重複，而且在本系統中還將增加新類型的客戶。爲了讓系統具有更好的擴展性，同時減少代碼重複，使用里氏代換原則對其進行重構。

​ 在本實例中，可以考慮增加一個新的抽象客戶類Customer，而將CommonCustomer和VIPCustomer類作爲其子類，郵件發送類EmailSender類針對抽象客戶類Customer編程，根據里氏代換原則，能夠接受基類對象的地方必然能夠接受子類對象，因此將EmailSender中的send()方法的參數類型改爲Customer，如果需要增加新類型的客戶，只需將其作爲Customer類的子類即可。重構後的結構如圖2所示：

​ 圖2 重構後的結構圖

​ 里氏代換原則是實現開閉原則的重要方式之一。在本實例中，在傳遞參數時使用基類對象，除此以外，在定義成員變量、定義局部變量、確定方法返回類型時都可使用里氏代換原則。針對基類編程，在程序運行時再確定具體子類。

設計模式六大原則（4）：依賴倒置原則

​ 依賴倒轉原則(Dependency Inversion Principle, DIP)：抽象不應該依賴於細節，細節應當依賴於抽象。換言之，要針對接口編程，而不是針對實現編程。

​ 依賴倒轉原則要求我們在程序代碼中傳遞參數時或在關聯關係中，儘量引用層次高的抽象層類，即使用接口和抽象類進行變量類型聲明、參數類型聲明、方法返回類型聲明，以及數據類型的轉換等，而不要用具體類來做這些事情。爲了確保該原則的應用，一個具體類應當只實現接口或抽象類中聲明過的方法，而不要給出多餘的方法，否則將無法調用到在子類中增加的新方法。

      在引入抽象層後，系統將具有很好的靈活性，在程序中儘量使用抽象層進行編程，而將具體類寫在配置文件中，這樣一來，如果系統行爲發生變化，只需要對抽象層進行擴展，並修改配置文件，而無須修改原有系統的源代碼，在不修改的情況下來擴展系統的功能，滿足開閉原則的要求。

      在實現依賴倒轉原則時，我們需要針對抽象層編程，而將具體類的對象通過依賴注入(DependencyInjection, DI)的方式注入到其他對象中，依賴注入是指當一個對象要與其他對象發生依賴關係時，通過抽象來注入所依賴的對象。常用的注入方式有三種，分別是：構造注入，設值注入（Setter注入）和接口注入。構造注入是指通過構造函數來傳入具體類的對象，設值注入是指通過Setter方法來傳入具體類的對象，而接口注入是指通過在接口中聲明的業務方法來傳入具體類的對象。這些方法在定義時使用的是抽象類型，在運行時再傳入具體類型的對象，由子類對象來覆蓋父類對象。

實例：

  Sunny軟件公司開發人員在開發某CRM系統時發現：該系統經常需要將存儲在TXT或Excel文件中的客戶信息轉存到數據庫中，因此需要進行數據格式轉換。在客戶數據操作類中將調用數據格式轉換類的方法實現格式轉換和數據庫插入操作，初始設計方案結構如圖1所示：

​ 圖1 初始設計方案結構圖

      在編碼實現圖1所示結構時，Sunny軟件公司開發人員發現該設計方案存在一個非常嚴重的問題，由於每次轉換數據時數據來源不一定相同，因此需要更換數據轉換類，如有時候需要將TXTDataConvertor改爲ExcelDataConvertor，此時，需要修改CustomerDAO的源代碼，而且在引入並使用新的數據轉換類時也不得不修改CustomerDAO的源代碼，系統擴展性較差，違反了開閉原則，現需要對該方案進行重構。

​ 在本實例中，由於CustomerDAO針對具體數據轉換類編程，因此在增加新的數據轉換類或者更換數據轉換類時都不得不修改CustomerDAO的源代碼。我們可以通過引入抽象數據轉換類解決該問題，在引入抽象數據轉換類DataConvertor之後，CustomerDAO針對抽象類DataConvertor編程，而將具體數據轉換類名存儲在配置文件中，符合依賴倒轉原則。根據里氏代換原則，程序運行時，具體數據轉換類對象將替換DataConvertor類型的對象，程序不會出現任何問題。更換具體數據轉換類時無須修改源代碼，只需要修改配置文件；如果需要增加新的具體數據轉換類，只要將新增數據轉換類作爲DataConvertor的子類並修改配置文件即可，原有代碼無須做任何修改，滿足開閉原則。重構後的結構如圖2所示：

​ 圖2重構後的結構圖

     在上述重構過程中，我們使用了開閉原則、里氏代換原則和依賴倒轉原則，在大多數情況下，這三個設計原則會同時出現，開閉原則是目標，里氏代換原則是基礎，依賴倒轉原則是手段，它們相輔相成，相互補充，目標一致，只是分析問題時所站角度不同而已。

設計模式六大原則（5）：接口隔離原則

​ 接口隔離原則(Interface Segregation Principle, ISP)：使用多個專門的接口，而不使用單一的總接口，即客戶端不應該依賴那些它不需要的接口。

​ 根據接口隔離原則，當一個接口太大時，我們需要將它分割成一些更細小的接口，使用該接口的客戶端僅需知道與之相關的方法即可。每一個接口應該承擔一種相對獨立的角色，不幹不該乾的事，該乾的事都要幹。這裏的“接口”往往有兩種不同的含義：一種是指一個類型所具有的方法特徵的集合，僅僅是一種邏輯上的抽象；另外一種是指某種語言具體的“接口”定義，有嚴格的定義和結構，比如Java語言中的interface。對於這兩種不同的含義，ISP的表達方式以及含義都有所不同：

      (1) 當把“接口”理解成一個類型所提供的所有方法特徵的集合的時候，這就是一種邏輯上的概念，接口的劃分將直接帶來類型的劃分。可以把接口理解成角色，一個接口只能代表一個角色，每個角色都有它特定的一個接口，此時，這個原則可以叫做“角色隔離原則”。

      (2) 如果把“接口”理解成狹義的特定語言的接口，那麼ISP表達的意思是指接口僅僅提供客戶端需要的行爲，客戶端不需要的行爲則隱藏起來，應當爲客戶端提供儘可能小的單獨的接口，而不要提供大的總接口。在面向對象編程語言中，實現一個接口就需要實現該接口中定義的所有方法，因此大的總接口使用起來不一定很方便，爲了使接口的職責單一，需要將大接口中的方法根據其職責不同分別放在不同的小接口中，以確保每個接口使用起來都較爲方便，並都承擔某一單一角色。接口應該儘量細化，同時接口中的方法應該儘量少，每個接口中只包含一個客戶端（如子模塊或業務邏輯類）所需的方法即可，這種機制也稱爲“定製服務”，即爲不同的客戶端提供寬窄不同的接口。

實例：

​ Sunny軟件公司開發人員針對某CRM系統的客戶數據顯示模塊設計瞭如圖1所示接口，其中方法dataRead()用於從文件中讀取數據，方法transformToXML()用於將數據轉換成XML格式，方法createChart()用於創建圖表，方法displayChart()用於顯示圖表，方法createReport()用於創建文字報表，方法displayReport()用於顯示文字報表。

​ 圖1 初始設計方案結構圖

      在實際使用過程中發現該接口很不靈活，例如如果一個具體的數據顯示類無須進行數據轉換（源文件本身就是XML格式），但由於實現了該接口，將不得不實現其中聲明的transformToXML()方法（至少需要提供一個空實現）；如果需要創建和顯示圖表，除了需實現與圖表相關的方法外，還需要實現創建和顯示文字報表的方法，否則程序編譯時將報錯。

​ 在圖1中，由於在接口CustomerDataDisplay中定義了太多方法，即該接口承擔了太多職責，一方面導致該接口的實現類很龐大，在不同的實現類中都不得不實現接口中定義的所有方法，靈活性較差，如果出現大量的空方法，將導致系統中產生大量的無用代碼，影響代碼質量；另一方面由於客戶端針對大接口編程，將在一定程序上破壞程序的封裝性，客戶端看到了不應該看到的方法，沒有爲客戶端定製接口。因此需要將該接口按照接口隔離原則和單一職責原則進行重構，將其中的一些方法封裝在不同的小接口中，確保每一個接口使用起來都較爲方便，並都承擔某一單一角色，每個接口中只包含一個客戶端（如模塊或類）所需的方法即可。

      通過使用接口隔離原則，本實例重構後的結構如圖2所示：

​ 圖2 重構後的結構圖

      在使用接口隔離原則時，需要注意控制接口的粒度，接口不能太小，如果太小會導致系統中接口氾濫，不利於維護；接口也不能太大，太大的接口將違背接口隔離原則，靈活性較差，使用起來很不方便。一般而言，接口中僅包含爲某一類用戶定製的方法即可，不應該強迫客戶依賴於那些它們不用的方法。

設計模式六大原則（6）：迪米特原則

​ 迪米特法則(Law of Demeter, LoD)：一個軟件實體應當儘可能少地與其他實體發生相互作用。

​ 如果一個系統符合迪米特法則，那麼當其中某一個模塊發生修改時，就會盡量少地影響其他模塊，擴展會相對容易，這是對軟件實體之間通信的限制，迪米特法則要求限制軟件實體之間通信的寬度和深度。迪米特法則可降低系統的耦合度，使類與類之間保持鬆散的耦合關係。

      迪米特法則還有幾種定義形式，包括：不要和“陌生人”說話、只與你的直接朋友通信等，在迪米特法則中，對於一個對象，其朋友包括以下幾類：

      (1) 當前對象本身(this)；

     (2) 以參數形式傳入到當前對象方法中的對象；

      (3) 當前對象的成員對象；

      (4) 如果當前對象的成員對象是一個集合，那麼集合中的元素也都是朋友；

      (5) 當前對象所創建的對象。

      任何一個對象，如果滿足上面的條件之一，就是當前對象的“朋友”，否則就是“陌生人”。在應用迪米特法則時，一個對象只能與直接朋友發生交互，不要與“陌生人”發生直接交互，這樣做可以降低系統的耦合度，一個對象的改變不會給太多其他對象帶來影響。

      迪米特法則要求我們在設計系統時，應該儘量減少對象之間的交互，如果兩個對象之間不必彼此直接通信，那麼這兩個對象就不應當發生任何直接的相互作用，如果其中的一個對象需要調用另一個對象的某一個方法的話，可以通過第三者轉發這個調用。簡言之，就是通過引入一個合理的第三者來降低現有對象之間的耦合度。

      在將迪米特法則運用到系統設計中時，要注意下面的幾點：在類的劃分上，應當儘量創建鬆耦合的類，類之間的耦合度越低，就越有利於複用，一個處在鬆耦合中的類一旦被修改，不會對關聯的類造成太大波及；在類的結構設計上，每一個類都應當儘量降低其成員變量和成員函數的訪問權限；在類的設計上，只要有可能，一個類型應當設計成不變類；在對其他類的引用上，一個對象對其他對象的引用應當降到最低。

實例：

  Sunny軟件公司所開發CRM系統包含很多業務操作窗口，在這些窗口中，某些界面控件之間存在複雜的交互關係，一個控件事件的觸發將導致多個其他界面控件產生響應，例如，當一個按鈕(Button)被單擊時，對應的列表框(List)、組合框(ComboBox)、文本框(TextBox)、文本標籤(Label)等都將發生改變，在初始設計方案中，界面控件之間的交互關係可簡化爲如圖1所示結構：

​ 圖1 初始設計方案結構圖

​ 在圖1中，由於界面控件之間的交互關係複雜，導致在該窗口中增加新的界面控件時需要修改與之交互的其他控件的源代碼，系統擴展性較差，也不便於增加和刪除新控件。

​ 在本實例中，可以通過引入一個專門用於控制界面控件交互的中間類(Mediator)來降低界面控件之間的耦合度。引入中間類之後，界面控件之間不再發生直接引用，而是將請求先轉發給中間類，再由中間類來完成對其他控件的調用。當需要增加或刪除新的控件時，只需修改中間類即可，無須修改新增控件或已有控件的源代碼，重構後結構如圖2所示：

​ 圖2  重構後的結構圖

Java設計模式之單例模式

單例模式，也叫單子模式，是一種簡單和常用的軟件設計模式。在應用這個模式時，單例對象的類必須保證只有一個實例存在。許多時候整個系統只需要擁有一個的全局對象，這樣有利於我們協調系統整體的行爲。比如在某個服務器程序中，該服務器的配置信息存放在一個文件中，這些配置數據由一個單例對象統一讀取，然後服務進程中的其他對象再通過這個單例對象獲取這些配置信息。這種方式簡化了在複雜環境下的配置管理，有利於Java垃圾回收。

單例模式主要有3個特點：

• 1、單例類確保自己只有一個實例。
• 2、單例類必須自己創建自己的實例。
• 3、單例類必須爲其他對象提供唯一的實例。

單例模式的實現方式有五種方法：懶漢，惡漢，雙重校驗鎖，枚舉和靜態內部類。

懶漢模式

懶漢方式，指全局的單例實例在第一次被使用時構建。注意線程安全與否。

線程不安全：

//Non Thread Safe
public class Singleton {  
    private static Singleton instance;  
    private Singleton (){}  

    public static Singleton getInstance() {  
        if (instance == null) {  
            instance = new Singleton();  
        }  
    return instance;  
    }  
}

這種寫法lazy loading很明顯，但是致命的是在多線程不能正常工作。

線程安全：

public class Singleton {
    private static Singleton instance;
    private Singleton (){}

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

這種寫法能夠在多線程中很好的工作，而且看起來它也具備很好的lazy loading，但是，遺憾的是，效率很低，99%情況下不需要同步。

惡漢模式

餓漢方式，指全局的單例實例在類裝載時構建。

public class Singleton {
    private static Singleton instance = new Singleton();
    private Singleton (){}

    public static Singleton getInstance() {
        return instance;
    }
}

這種方式基於classloder機制避免了多線程的同步問題，不過，instance在類裝載時就實例化，雖然導致類裝載的原因有很多種，在單例模式中大多數都是調用getInstance方法， 但是也不能確定有其他的方式（或者其他的靜態方法）導致類裝載，這時候初始化instance顯然沒有達到lazy loading的效果。

靜態內部類

因爲單例是靜態的final變量，當類第一次加載到內存中的時候就初始化了，其thread-safe性由 JVM 來負責保證。

//一個延遲實例化的內部類的單例模式
public final class Singleton {

    //一個內部類的容器，調用getInstance時，JVM加載這個類
    private static final class SingletonHolder {
        static final Singleton singleton =  new Singleton();
    }

    private Singleton() {}

    public static Singleton getInstance() {
        return SingletonHolder.singleton;
    }
 }

首先，其他類在引用這個Singleton的類時，只是新建了一個引用，並沒有開闢一個的堆空間存放（對象所在的內存空間）。接着，當使用Singleton.getInstance()方法後，Java虛擬機（JVM）會加載SingletonHolder.class（JLS規定每個class對象只能被初始化一次），並實例化一個Singleton對象。

缺點：需要在Java的另外一個內存空間（Java PermGen 永久代內存，這塊內存是虛擬機加載class文件存放的位置）佔用一個大塊的空間。

枚舉

枚舉單例（Enum Singleton）是實現單例模式的一種新方式，枚舉這個特性是在Java5纔出現的。《Effective Java》一書中有介紹這個特性，它不僅能避免多線程同步問題，而且還能防止反序列化重新創建新的對象。

public enum Singleton {  
    INSTANCE;  
    public void whateverMethod() {  
    }  
}

默認枚舉實例的創建是線程安全的，但是在枚舉中的其他任何方法由程序員自己負責。如果你正在使用實例方法，那麼你需要確保線程安全（如果它影響到其他對象的狀態的話）。傳統單例存在的另外一個問題是一旦你實現了序列化接口，那麼它們不再保持單例了，但是枚舉單例，JVM對序列化有保證。枚舉實現單例的好處：有序列化和線程安全的保證，代碼簡單。

雙重校驗鎖

public class Singleton {
    public static final Singleton singleton = null;
    private Singleton(){}
    public static Singleton getInstance(){
        if(singleton == null){ 
           synchronize (Singleton.class){
               if( singleton == null ) { // double check 
                   singleton = new Singleton();
               }
        }
        return singleton;
    }
}

當兩個線程執行完第一個 singleton == null 後等待鎖， 其中一個線程獲得鎖並進入synchronize後，實例化了，然後退出釋放鎖，另外一個線程獲得鎖，進入又想實例化，會判斷是否進行實例化了，如果存在，就不進行實例化了。