單例模式是設計模式中最簡單的形式之一。這一模式的目的是使得類的一個對象成爲系統中的唯一實例。要實現這一點，可以從客戶端對其進行實例化開始。因此需要用一種只允許生成對象類的唯一實例的機制，“阻止”所有想要生成對象的訪問。使用工廠方法來限制實例化過程。這個方法應該是靜態方法（類方法），因爲讓類的實例去生成另一個唯一實例毫無意義
意圖：
保證一個類僅有一個實例，並提供一個訪問它的全局訪問點。
適用性：
當類只能有一個實例而且客戶可以從一個衆所周知的訪問點訪問它時。
當這個唯一實例應該是通過子類化可擴展的，並且客戶應該無需更改代碼就能使用一個擴展的實例時。
第一種（懶漢，線程不安全）
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;
}
}
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之後，雙重檢查鎖定才能夠正常達到單例效果
優點
一、實例控制
單例模式會阻止其他對象實例化其自己的單例對象的副本，從而確保所有對象都訪問唯一實例。
二、靈活性
因爲類控制了實例化過程，所以類可以靈活更改實例化過程。
缺點
一、開銷
雖然數量很少，但如果每次對象請求引用時都要檢查是否存在類的實例，將仍然需要一些開銷。可以通過使用靜態初始化解決此問題。
二、可能的開發混淆
使用單例對象（尤其在類庫中定義的對象）時，開發人員必須記住自己不能使用new關鍵字實例化對象。因爲可能無法訪問庫源代碼，因此應用程序開發人員可能會意外發現自己無法直接實例化此類。
三、對象生存期
不能解決刪除單個對象的問題。在提供內存管理的語言中（例如基於.NET Framework的語言），只有單例類能夠導致實例被取消分配，因爲它包含對該實例的私有引用。在某些語言中（如 C++），其他類可以刪除對象實例，但這樣會導致單例類中出現懸浮引用。