單例模式有以下特點：
1、單例類只能有一個實例。
2、單例類必須自己創建自己的唯一實例。
3、單例類必須給所有其他對象提供這一實例。
編寫單例應該注意以下的問題
線程安全延遲加載序列化與反序列化安全a.懶加載模式
public class Singleton {
private static Singleton instance;
private Singleton (){}
public static Singleton getInstance () {
if (instance == null ) {
instance = new Singleton();
}
return instance;
}
}
缺點：當有多個線程並行調用 getInstance() 的時候，就會創建多個實例。也就是說在多線程下不能正常工作。
b.懶漢式
public static synchronized Singleton getInstance () {
if (instance == null ) {
instance = new Singleton();
}
return instance;
}
雖然做到了線程安全，並且解決了多實例的問題，但是它並不高效。因爲在任何時候只能有一個線程調用 getInstance() 方法。但是同步操作只需要在第一次調用時才被需要，即第一次創建單例實例對象時。這就引出了雙重檢驗鎖。
c.雙重檢驗鎖模式 （synchronized已經起到了多線程下原子性、有序性、可見性的作用）
雙重檢驗鎖模式（double checked locking pattern），是一種使用同步塊加鎖的方法。程序員稱其爲雙重檢查鎖，因爲會有兩次檢查 instance == null ，一次是在同步塊外，一次是在同步塊內。爲什麼在同步塊內還要再檢驗一次？因爲可能會有多個線程一起進入同步塊外的 if，如果在同步塊內不進行二次檢驗的話就會生成多個實例了。
public static Singleton getSingleton () {
if (instance == null ) { //Single Checked
synchronized (Singleton.class) {
if (instance == null ) { //Double Checked
instance = new Singleton();
}
}
}
return instance ;
}
問題 主要在於 instance = new Singleton() 這句，這並非是一個原子操作，事實上在
JVM 中這句話大概做了下面 3 件事情。
給 instance
分配內存
調用 Singleton 的構造函數來初始化成員變量
將instance對象指向分配的內存空間（執行完這步 instance 就爲非 null 了）
但是在 JVM 的即時編譯器中存在指令重排序的優化。也就是說上面的第二步和第三步的順序是不能保證的，最終的執行順序可能是 1-2-3 也可能是 1-3-2。如果是後者，則在 3 執行完畢、2 未執行之前，被線程二搶佔了，這時 instance 已經是非 null 了（但卻沒有初始化），所以線程二會直接返回 instance，然後使用，然後順理成章地報錯。
d.將 instance 變量聲明成 volatile
public class Singleton {
private volatile static Singleton instance; //聲明成 volatile
private Singleton (){}
public static Singleton getSingleton () {
if (instance == null ) {
synchronized (Singleton.class) {
if (instance == null ) {
instance = new Singleton();
}
}
}
return instance;
}
}
有些人認爲使用 volatile 的原因是可見性，也就是可以保證線程在本地不會存有 instance 的副本，每次都是去主內存中讀取。但其實是不對的。使用 volatile 的主要原因是其另一個特性：禁止指令重排序優化。也就是說，在 volatile 變量的賦值操作後面會有一個內存屏障（生成的彙編代碼上），讀操作不會被重排序到內存屏障之前。比如上面的例子，取操作必須在執行完
1-2-3 之後或者 1-3-2 之後，不存在執行到 1-3 然後取到值的情況。從「先行發生原則」的角度理解的話，就是對於一個 volatile 變量的寫操作都先行發生於後面對這個變量的讀操作（這裏的“後面”是時間上的先後順序）。
但是特別注意在 Java 5 以前的版本使用了 volatile 的雙檢鎖還是有問題的。其原因是 Java 5 以前的 JMM （Java 內存模型）是存在缺陷的，即時將變量聲明成 volatile 也不能完全避免重排序，主要是 volatile 變量前後的代碼仍然存在重排序問題。這個 volatile 屏蔽重排序的問題在 Java 5 中才得以修復，所以在這之後纔可以放心使用 volatile。
e 餓漢式 static final field
public class Singleton {
//類加載時就初始化
private static final Singleton instance = new Singleton();
private Singleton (){}
public static Singleton getInstance (){
return instance;
}
}
缺點是它不是一種懶加載模式（lazy initialization），單例會在加載類後一開始就被初始化，即使客戶端沒有調用 getInstance()方法。餓漢式的創建方式在一些場景中將無法使用：譬如 Singleton 實例的創建是依賴參數或者配置文件的，在 getInstance() 之前必須調用某個方法設置參數給它，那樣這種單例寫法就無法使用了。
f 靜態內部類 static nested class
public class Singleton {
private static class SingletonHolder {
private static final Singleton INSTANCE = new Singleton();
}
private Singleton (){}
public static final Singleton getInstance () {
return SingletonHolder.INSTANCE;
}
}
這種寫法仍然使用JVM本身機制保證了線程安全問題；由於 SingletonHolder 是私有的，除了 getInstance() 之外沒有辦法訪問它，因此它是懶漢式的；同時讀取實例的時候不會進行同步，沒有性能缺陷；也不依賴 JDK 版本。
g 枚舉 Enum
public enum EasySingleton{
INSTANCE;
}
我們可以通過EasySingleton.INSTANCE來訪問實例，這比調用getInstance()方法簡單多了。創建枚舉默認就是線程安全的，所以不需要擔心double checked locking，而且還能防止反序列化導致重新創建新的對象。但是還是很少看到有人這樣寫，可能是因爲不太熟悉吧。
總結： 一般來說，單例模式有五種寫法：懶漢、餓漢、雙重檢驗鎖、靜態內部類、枚舉。上述所說都是線程安全的實現，文章開頭給出的第一種方法不算正確的寫法