單例模式(Singleton Pattern)：確保某一個類只有一個實例，而且自行實例化並向整個系統提供這個實例，這個類稱為單例類，它提供全局訪問的方法。單例模式是一種對象創建型模式。
單例模式有三個要點：一是某個類只能有一個實例；二是它必須自行創建這個實例；三是它必須自行向整個系統提供這個實例。
單例模式是結構最簡單的設計模式一，在它的核心結構中只包含一個被稱為單例類的特殊類。 
單例模式結構圖中只包含一個單例角色：
Singleton（單例）：在單例類的內部實現只生成一個實例，同時它提供一個靜態的getInstance()工廠方法，讓客戶可以訪問它的唯一實例；為了防止在外部對其實例化，將其構造函數設計為私有；在單例類內部定義了一個Singleton類型的靜態對象，作為外部共享的唯一實例。
單例模式是一種比較常見的設計模式。
單例模式作用：
1.控制資源的使用，通過線程同步來控制資源的並發訪問；
2.控制實例產生的數量，達到節約資源的目的。
3.作為通信媒介使用，也就是數據共享，它可以在不建立直接關聯的條件下，讓多個不相關的兩個線程或者進程之間實現通信。
單例模式適用場景
在以下情況下可以考慮使用單例模式：
(1) 系統只需要一個實例對象，如系統要求提供一個唯一的序列號生成器或資源管理器，或者需要考慮資源消耗太大而只允許創建一個對象。
(2) 客戶調用類的單個實例只允許使用一個公共訪問點，除了該公共訪問點，不能通過其他途徑訪問該實例。
單例模式優缺點
主要優點：
A.提供了對唯一實例的受控訪問。
B.由於在系統內存中只存在一個對象，因此可以節約系統資源，對於一些需要頻繁創建和銷毀的對象單例模式無疑可以提高系統的性能。
C.允許可變數目的實例。
主要缺點：
A.由於單利模式中沒有抽象層，因此單例類的擴展有很大的困難。
B.單例類的職責過重，在一定程度上違背了“單一職責原則”。
C.濫用單例將帶來一些負面問題，如為了節省資源將數據庫連接池對象設計為的單例類，可能會導致共享連接池對象的程序過多而出現連接池溢出；如果實例化的對象長時間不被利用，系統會認為是垃圾而被回收，這將導致對象狀態的丟失。
單例模式的七種書寫方式
第一種（懶漢，線程不安全）
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的效果。
第四種（餓漢，變種）
public class Singleton { private Singleton instance = null; static { instance = new Singleton(); } private Singleton (){} public static Singleton getInstance() { return this.instance; } }
表面上看起來差別挺大，其實和第三種方式差不多，都是在類初始化即實例化instance。
第五種（靜態內部類）
public class Singleton { private static class SingletonHolder { private static final Singleton INSTANCE = new Singleton(); } private Singleton (){} public static final Singleton getInstance() { return SingletonHolder.INSTANCE; } }
這種方式同樣利用了classloder的機制來保證初始化instance時只有一個線程，它跟第三種和第四種方式不同的是（很細微的差別）：第三種和第四種方式是只要Singleton類被裝載了，那么instance就會被實例化（沒有達到lazy loading效果），而這種方式是Singleton類被裝載了，instance不一定被初始化。因為SingletonHolder類沒有被主動使用，只有顯示通過調用getInstance方法時，才會顯示裝載SingletonHolder類，從而實例化instance。想象一下，如果實例化instance很消耗資源，我想讓他延遲加載，另外一方面，我不希望在Singleton類加載時就實例化，因為我不能確保Singleton類還可能在其他的地方被主動使用從而被加載，那么這個時候實例化instance顯然是不合適的。這個時候，這種方式相比第三和第四種方式就顯得很合理。
第六種（枚舉）
public enum Singleton { INSTANCE; public void whateverMethod() { } }
這種方式是Effective Java作者Josh Bloch 提倡的方式，它不僅能避免多線程同步問題，而且還能防止反序列化重新創建新的對象，可謂是很堅強的壁壘啊，不過，個人認為由於1.5中才加入enum特性，用這種方式寫不免讓人感覺生疏，在實際工作中，我也很少看見有人這么寫過。
第七種（雙重校驗鎖）
public class Singleton { private volatile static Singleton singleton; private Singleton (){} public static Singleton getSingleton() { if (singleton == null) { synchronized (Singleton.class) { if (singleton == null) { singleton = new Singleton(); } } } return singleton; } }
在JDK1.5之后，雙重檢查鎖定才能夠正常達到單例效果。
總結
有兩個問題需要注意：
1.如果單例由不同的類裝載器裝入，那便有可能存在多個單例類的實例。假定不是遠端存取，例如一些servlet容器對每個servlet使用完全不同的類裝載器，這樣的話如果有兩個servlet訪問一個單例類，它們就都會有各自的實例。
問題修復的辦法是：
private static Class getClass(String classname) throws ClassNotFoundException { ClassLoader classLoader = Thread.currentThread().getContextClassLoader(); if(classLoader == null) classLoader = Singleton.class.getClassLoader(); return (classLoader.loadClass(classname)); } }
2.如果Singleton實現了java.io.Serializable接口，那么這個類的實例就可能被序列化和復原。不管怎樣，如果你序列化一個單例類的對象，接下來復原多個那個對象，那你就會有多個單例類的實例。
問題修復的辦法是：
public class Singleton implements java.io.Serializable { public static Singleton INSTANCE = new Singleton(); protected Singleton() { } private Object readResolve() { return INSTANCE; } }
第三種和第五種方式，簡單易懂，而且在JVM層實現了線程安全（如果不是多個類加載器環境），一般的情況下，我會使用第三種方式，只有在要明確實現lazy loading效果時才會使用第五種方式，另外，如果涉及到反序列化創建對象時，可以試着使用枚舉的方式來實現單例，不過，我一直會保證我的程序是線程安全的，而且我永遠不會使用第一種和第二種方式，如果有其他特殊的需求，我可能會使用第七種方式，畢竟，JDK1.5已經沒有雙重檢查鎖定的問題了。
不過一般來說，第一種不算單例，第四種和第三種就是一種，如果算的話，第五種也可以分開寫了。所以說，一般單例都是五種寫法。懶漢，惡漢，雙重校驗鎖，枚舉和靜態內部類。
餓漢式單例類與懶漢式單例類比較
餓漢式單例類在類被加載時就將自己實例化，它的優點在於無須考慮多線程訪問問題，可以確保實例的唯一性；從調用速度和反應時間角度來講，由於單例對象一開始就得以創建，因此要優於懶漢式單例。但是無論系統在運行時是否需要使用該單例對象，由於在類加載時該對象就需要創建，因此從資源利用效率角度來講，餓漢式單例不及懶漢式單例，而且在系統加載時由於需要創建餓漢式單例對象，加載時間可能會比較長。
懶漢式單例類在第一次使用時創建，無須一直占用系統資源，實現了延遲加載，但是必須處理好多個線程同時訪問的問題，特別是當單例類作為資源控制器，在實例化時必然涉及資源初始化，而資源初始化很有可能耗費大量時間，這意味着出現多線程同時首次引用此類的機率變得較大，需要通過雙重檢查鎖定等機制進行控制，這將導致系統性能受到一定影響。
新型單例實現方法
餓漢式單例類不能實現延遲加載，不管將來用不用始終占據內存；懶漢式單例類線程安全控制煩瑣，而且性能受影響。可見，無論是餓漢式單例還是懶漢式單例都存在這樣那樣的問題，有沒有一種方法，能夠將兩種單例的缺點都克服，而將兩者的優點合二為一呢？答案是：Yes！下面我們來學習這種更好的被稱之為Initialization on Demand Holder (IoDH)的技術。
在IoDH中，我們在單例類中增加一個靜態(static)內部類，在該內部類中創建單例對象，再將該單例對象通過getInstance()方法返回給外部使用，實現代碼如下所示：
//Initialization on Demand Holder public class Singleton{ private Singleton(){ } private static class HolderClass{ private final static Singleton instance = new Singleton(); } public static Singleton getInstance(){ return HolderClass.instance; } public static void main(String args[]){ Singleton s1, s2; s1 = Singleton.getInstance(); s2 = Singleton.getInstance(); System.out.println(s1==s2); } }
編譯並運行上述代碼，運行結果為：true，即創建的單例對象s1和s2為同一對象。由於靜態單例對象沒有作為Singleton的成員變量直接實例化，因此類加載時不會實例化Singleton，第一次調用getInstance()時將加載內部類HolderClass，在該內部類中定義了一個static類型的變量instance，此時會首先初始化這個成員變量，由Java虛擬機來保證其線程安全性，確保該成員變量只能初始化一次。由於getInstance()方法沒有任何線程鎖定，因此其性能不會造成任何影響。
通過使用IoDH，我們既可以實現延遲加載，又可以保證線程安全，不影響系統性能，不失為一種最好的Java語言單例模式實現方式（其缺點是與編程語言本身的特性相關，很多面向對象語言不支持IoDH）