JAVA設計模式（6：單例模式詳解）
單例模式作為一種創建型模式，在日常開發中用處極廣，我們先來看一一段程式碼：
// 構造函數
protected Calendar(TimeZone var1, Locale var2) {
this.lenient = true;
this.sharedZone = false;
this.nextStamp = 2;
this.serialVersionOnStream = 1;
this.fields = new int[17];
this.isSet = new boolean[17];
this.stamp = new int[17];
this.zone = var1;
this.setWeekCountData(var2);
}
// 提供 Calendar 類實例的方法
public static Calendar getInstance(){
return createCalendar(TimeZone.getDefault(), Locale.getDefault(Locale.Category.FORMAT));
}
看過上一篇部落格Java設計模式（5：工廠模式詳解）的朋友應該熟悉這段來自JDK中Calendar類的程式碼，這就是單例模式的一種實現：
Calendar類的構造函數被protected修飾，保證其不能被其他包下的類訪問。getInstance()方法提供了獲得Calendar類實例化對象的方法。
從上述程式碼來看，我們可以認定實現單例模式需要滿足兩個基本原則：
- 類的構造函數私有化。
- 該類需要提供一個獲得實例的全局訪問點。
所以可以得出結論：單例模式是指確保一個類在任何情況下都絕對只有一個實例，並提供一個全局的訪問點。
得出結論後，再來看看實現。在java語言當中，兩種方式構建單例模式：餓漢式單例和懶漢式單例。
一、餓漢式單例
// 餓漢式單例
public class HungrySingleton {
// 構造函數私有化
private HungrySingleton() {}
private static final HungrySingleton singleton = new HungrySingleton();
// 提供一個全局的訪問點
public static HungrySingleton getInstance(){
return singleton;
}
}
餓漢式單例是在類載入的時候就立即初始化，並且創建了單例對象。在上述程式碼中，當HungrySingleton類在被類載入器載入時，它的實例對象singleton就已經創建完成了；並且根據類的載入機制，我們明白：singleton作為HungrySingleton類中的一個靜態的聲明對象，在HungrySingleton類第一次被類載入器載入時就已經創建完成，並且只會創建這一次。這就保證了無論getInstance()方法被調用多少次，返回的都是同一個singleton實例；保證了執行緒的絕對安全，不會出現訪問安全的問題。
但也正式因為singleton實例在HungrySingleton類第一次被類載入器載入時就已經創建完成，若getInstance()方法不被任何地方調用，那麼singleton實例就會一直占著記憶體空間，白白浪費了資源。所以引申出了另一種構建單例模式的方式：懶漢式單例
二、懶漢式單例
懶漢式單例的特點是只有在類的全局訪問點被訪問的時候，類的實例化對象才會創建。
// 懶漢式單例
public class LazySingleton {
// 構造函數私有化
private LazySingleton() {}
private static LazySingleton lazySingleton = null;
// 全局訪問點
public static LazySingleton getInstance(){
if (lazySingleton == null){
lazySingleton = new LazySingleton();
}
return lazySingleton;
}
}
在上述程式碼中，只有當getInstance()方法被調用時，才會去創建lazySingleton實例。這樣就解決了餓漢式模式中的資源佔用問題，但同樣引申出了另一個問題：執行緒安全問題。
我們先來創建一個屬於我們自己的執行緒類LazyThread：
// 執行緒
public class LazyThread implements Runnable {
@Override
public void run() {
LazySingleton instance = LazySingleton.getInstance();
// 列印 執行緒名字 和 instance實例的記憶體地址
System.out.println(Thread.currentThread().getName() + "：" +instance);
}
}
調用：
// 創建兩個執行緒
public static void main(String[] args) {
Thread thread1 = new Thread(new LazyThread());
Thread thread2 = new Thread(new LazyThread());
thread1.start();
thread2.start();
}
我們採用debug模式調試一下，先和下圖一般，在LazySingleton類中打一個斷點。
再用滑鼠右鍵點擊斷點的位置（紅色圓點的位置），打開如下圖的框之後，先選擇紅框中的Thread模式，再點擊藍框中的Done按鈕。
做完上述的操作之後，我們來用debug模式運行一下main方法
上圖紅框中內容就是我們所創建的兩個執行緒，目前是Thread-0執行緒在運行。我們將Thread-0執行緒運行到lazySingleton = new LazySingleton()這行程式碼的位置（圖1），然後切換為Thread-1執行緒，並將Thread-1執行緒同樣運行到此位置（圖2）：
圖1：
圖2：
最後：切換回Thread-0執行緒，並全部放開，讓程式碼一直運行下去；並對Thread-1做出同樣的操作。列印出結果：
通過結果可以看出，兩個執行緒獲得的lazySingleton實例所對應的記憶體地址不相同，顯然不符合單例模式中的只有一個實例的原則。
那有什麼辦法可以保證懶漢式模式在執行緒環境下安全呢？有，而且很簡單，加鎖。我們來給getInstance()方法加上鎖：
// 懶漢式
public class LazySingleton {
// 私有化構造函數
private LazySingleton() {}
private static LazySingleton lazySingleton = null;
// 加鎖
public synchronized static LazySingleton getInstance(){
if (lazySingleton == null){
lazySingleton = new LazySingleton();
}
return lazySingleton;
}
}
我們再用上述的方式來debug調試一下：
在執行緒Thread-1進入getInstance()方法內部的時候，執行緒Thread-0處於MONITOR鎖監控的狀態。將執行緒Thread-1運行完後，Thread-0進入getInstance()方法內部，狀態更新為RUNNING運行狀態。
而此時我們可以看出lazySingleton已經有值了，所以我們將執行緒Thread-0運行完後，兩個執行緒會列印出一樣的結果：
由結果我們可以看出，在給getInstance()方法加上鎖之後，執行緒安全的問題便解決了。但依然可以繼續來優化這段懶漢式單例模式的程式碼。
// 懶漢式
public class LazySingleton {
// 私有化構造函數
private LazySingleton() {}
// volatile 關鍵字 解決重排序的問題
private volatile static LazySingleton lazySingleton = null;
public static LazySingleton getInstance(){
if (lazySingleton == null){
// 鎖程式碼塊
synchronized (LazySingleton.class) {
if (lazySingleton == null){
lazySingleton = new LazySingleton();
}
}
}
return lazySingleton;
}
}
這種方式被稱為雙重檢查鎖，它有著以下兩點的好處：
- 執行緒由基於
LazySingleton整個類的阻塞變為在getInstance()方法內部的阻塞。鎖的顆粒度變得更細，鎖的程式碼塊變得更小了。 - 第一重的
if判斷，直接分流了一部分在lazySingleton實例化後在進入getInstance()方法的執行緒，提高了效率。
但是，只要涉及到加鎖的問題，對程式的性能或多或少都有影響，那麼有沒有不加鎖的方式呢？當然也是有的，那就是以類的初始化角度來考慮，使用內部類的方式。
三、靜態內部類實現單例模式
// 懶漢式模式 和 餓漢式模式 兼顧
public class InnerClassSingleton {
// 私有化構造函數
private InnerClassSingleton(){}
public static InnerClassSingleton getInstance(){
return SingletonHolder.singleton;
}
// 靜態內部類
private static class SingletonHolder{
private static final InnerClassSingleton singleton = new InnerClassSingleton();
}
}
這種方式兼顧了懶漢式模式和餓漢式模式，根據類的載入機制來說，靜態內部類SingletonHolder不會隨著外部類InnerClassSingleton的載入而載入，只會在被調用時才會載入。
這裡外部類InnerClassSingleton在被類載入器載入後，並不會去進一步載入SingletonHolder類，從而也不會去實例化singleton，也就避免了資源浪費的情況。而在getInstance()方法第一次被調用時，內部類SingletonHolder才會載入，SingletonHolder類中聲明的靜態對象singleton才會被實例化；後面每一次調用getInstance()方法時，返回的都是此singleton對象，保證了只有一個實例化對象的原則。
四、用反射的方式來破壞單例
講完單例模式的幾種實現方式之後，我們來講一講破壞單例的方式；雖然日常開發中不會怎麼用到，但對面試來說，可以說是一個必考點。多了解了解，總會有意想不到的用處。
public static void main(String[] args) {
try {
// 用反射獲得 InnerClassSingleton 類的實例
Class clazz = InnerClassSingleton.class;
Constructor constructor = clazz.getDeclaredConstructor(null);
// 強制訪問
constructor.setAccessible(true);
InnerClassSingleton instance1 = (InnerClassSingleton)constructor.newInstance();
// 單例模式獲取
InnerClassSingleton instance2 = InnerClassSingleton.getInstance();
System.out.println("利用反射得到的實例對象："+instance1);
System.out.println("單例模式的實例對象："+instance2);
}catch (Exception e){
e.printStackTrace();
}
}
上述的測試程式碼，我分別用反射的方式和單例的方式來獲得InnerClassSingleton類的實例，最後列印出來，看一看結果：
可以看出，兩次創建的InnerClassSingleton類的實例又不相同了。那怎麼杜絕這種辦法呢？我們可以來優化一下上述的靜態內部類的程式碼：
// 懶漢式模式 和 餓漢式模式 兼顧
public class InnerClassSingleton {
// 私有化構造函數
private InnerClassSingleton(){
if (SingletonHolder.singleton != null){
throw new RuntimeException("不能以這種方式來獲得實例對象......");
}
}
public static InnerClassSingleton getInstance(){
return SingletonHolder.singleton;
}
// 靜態內部類
private static class SingletonHolder{
private static final InnerClassSingleton singleton = new InnerClassSingleton();
}
}
主要看私有構造函數中的程式碼，我們將這裡做了限制，當被外界調用時，直接拋出異常！測試的結果也如我們所願：
五、用序列化的方式破壞單例
除了反射之外，用序列化的方式也能破壞單例，達到創建不一樣的類的實例的效果。
先將InnerClassSingleton類實現序列化介面：
// 懶漢式模式 和 餓漢式模式 兼顧
public class InnerClassSingleton implements Serializable {
// ....... 中間的程式碼查看上面的程式碼
}
編寫測試程式碼：
public static void main(String[] args) {
try {
InnerClassSingleton instance1 = InnerClassSingleton.getInstance();
FileOutputStream fos = new FileOutputStream("singleton.obj");
ObjectOutputStream objectOutputStream = new ObjectOutputStream(fos);
objectOutputStream.writeObject(instance1);
objectOutputStream.flush();
objectOutputStream.close();
fos.close();
FileInputStream fis = new FileInputStream("singleton.obj");
ObjectInputStream objectInputStream = new ObjectInputStream(fis);
InnerClassSingleton instance2 = (InnerClassSingleton)objectInputStream.readObject();
objectInputStream.close();
fis.close();
System.out.println("利用單例獲得實例："+instance1);
System.out.println("利用序列化獲取的實例："+instance2);
}catch (Exception e){
e.printStackTrace();
}
}
在上面的程式碼中，我們先獲得InnerClassSingleton類的實例instance1，再將instance1寫入singleton.obj文件當中；然後再從中取出來，轉化為實例instance2；最後將instance1和instance2列印出來：
可以看出，兩次創建的InnerClassSingleton類的實例又不相同了。那麼這種方式的解決方案是什麼呢？也不難，只需要加上一個方法就好了：
public class InnerClassSingleton implements Serializable {
// ....... 程式碼省略
// 加上 readResolve() 方法
private Object readResolve(){
return SingletonHolder.singleton;
}
// 靜態內部類
private static class SingletonHolder{
private static final InnerClassSingleton singleton = new InnerClassSingleton();
}
}
再加上readResolve()之後，再來測試一下：
可以看出，兩次創建的實例完全相同，完美的解決了序列化的問題。那麼為什麼加上readResolve()就會解決這個問題呢？這裡和JDK的源碼有關，我這裡就不貼源碼了，不便於觀看，我這裡畫了一個時序圖，大家可以跟著這個時序圖來對照JDK源碼進行查看，了解內情。
1、先從編寫的測試程式碼裡面進入ObjectInputStream類中的readObject()方法
2、實序圖
以實序圖來看，其實方法內部還是創建了一次InnerClassSingleton類的實例，不過是後面用調用readResolve()方法獲得的InnerClassSingleton類的實例將它替換掉了，所以列印出的結果依舊是相同的。總體來說，還是白白消耗了記憶體，那麼再來看另一種創建單例的方式。
六、註冊式單例
註冊式單例又被稱為登記式單例，大體分為枚舉登記和容器快取兩種。
6.1 枚舉登記
public enum EnumSingleton {
INSTANCE;
// 用來測試對象是否相同
private Object data;
public Object getData() {
return data;
}
public void setData(Object data) {
this.data = data;
}
public static EnumSingleton getInstance(){
return INSTANCE;
}
}
6.1.1 序列化破壞
將上面的測試程式碼稍微更改一下：
public static void main(String[] args) {
try {
EnumSingleton instance1 = EnumSingleton.getInstance();
instance1.setData(new Object());
// ....... 查看 五、用序列化的方式破壞單例 的測試程式碼
EnumSingleton instance2 = (EnumSingleton)objectInputStream.readObject();
objectInputStream.close();
fis.close();
System.out.println("利用單例獲得實例："+instance1.getData());
System.out.println("利用序列化獲取的實例："+instance2.getData());
}catch (Exception e){
e.printStackTrace();
}
}
結果：
由結果可以看出是可行的，那麼原理是什麼呢？通過上述實序圖的方式查看源碼：
1、ObjectInputStream類中的readObject0()方法：
private Object readObject0(boolean unshared) throws IOException {
// ...... 省略程式碼
// 如果是枚舉類
case TC_ENUM:
return checkResolve(readEnum(unshared));
// ......
}
2、readEnum()方法
private Enum<?> readEnum(boolean unshared) throws IOException {
// ......
if (cl != null) {
try {
// 通過Class對象 c1 和 類名 name 來獲得唯一的枚舉對象
@SuppressWarnings("unchecked")
Enum<?> en = Enum.valueOf((Class)cl, name);
result = en;
} catch (IllegalArgumentException ex) {
throw (IOException) new InvalidObjectException(
"enum constant " + name + " does not exist in " +
cl).initCause(ex);
}
if (!unshared) {
handles.setObject(enumHandle, result);
}
}
// ......
}
通過查看源碼發現，枚舉類型其實通過Class 對象類和類名找到一個唯一的枚舉對象；因此，枚舉對象不可能被類載入器載入多次。
6.1.2 反射破壞
測試程式碼：
public static void main(String[] args) {
try {
Class clazz = EnumSingleton.class;
Constructor constructor = clazz.getDeclaredConstructor(null);
// 強制訪問
constructor.setAccessible(true);
EnumSingleton instance1 = (EnumSingleton)constructor.newInstance();
EnumSingleton instance2 = EnumSingleton.getInstance();
System.out.println("利用反射得到的實例對象："+instance1);
System.out.println("單例模式的實例對象："+instance2);
}catch (Exception e){
e.printStackTrace();
}
}
結果：
它竟然報出java.lang.NoSuchMethodException，意思是沒有找到對應的無參的構造函數，這是為什麼呢？不急，讓我們將EnumSingleton.class這個文件反編譯一下（這裡使用的是jad反編譯工具，不會的同學去網上搜教程，這裡不詳細講解了），得到一個EnumSingleton.jad文件，打開文件後發現這麼一段程式碼：
// .....
private EnumSingleton(String s, int i){
super(s, i);
}
// .....
static {
INSTANCE = new EnumSingleton("INSTANCE", 0);
$VALUES = (new EnumSingleton[] {
INSTANCE
});
}
原來jvm在編譯EnumSingleton枚舉類時，給它創建了一個有參的構造函數，並再靜態程式碼塊裡面實例化了INSTANCE對象。那這裡，我們再將測試程式碼修改一下，強制傳入兩個參數會怎麼樣：
public static void main(String[] args) {
try {
Class clazz = EnumSingleton.class;
// 設置兩個參數的類型
Constructor constructor = clazz.getDeclaredConstructor(String.class,int.class);
// 強制訪問
constructor.setAccessible(true);
// 傳入兩個參數
EnumSingleton instance1 = (EnumSingleton)constructor.newInstance("test",111);
EnumSingleton instance2 = EnumSingleton.getInstance();
System.out.println("利用反射得到的實例對象："+instance1);
System.out.println("單例模式的實例對象："+instance2);
}catch (Exception e){
e.printStackTrace();
}
}
結果：
還是報錯，不過這次的錯誤換成了Cannot reflectively create enum objects，不允許創建枚舉類的對象。我們來看看JDK的源碼：
從constructor.newInstance("test",111)這行程式碼進入Constructor類中的newInstance()方法我們發現，這裡有個判斷，如果是對枚舉類進行操作，那麼直接報出錯誤；這麼看來，是JDK源碼幫助我們去攔截了來自反射技術的破壞，那麼就可以放寬心了。
6.2 容器快取
容器快取最經典的例子就是Spring框架中的IOC容器，我們來模擬一下：
// 容器快取
public class ContainerSingleton {
// 私有化構造函數
private ContainerSingleton(){}
private static Map<String,Object> iocMap = new ConcurrentHashMap<>();
// 傳入 類名參數
public static Object getBean(String className){
if (className == null || "".equals(className)){
return null;
}
synchronized (iocMap){
// 判斷容器中是否有該屬性
if (!iocMap.containsKey(className)){
Object object = null;
try {
object = Class.forName(className).newInstance();
iocMap.put(className,object);
}catch (Exception e){
e.printStackTrace();
}
return object;
} else {
return iocMap.get(className);
}
}
}
}
iocMap中的key存的是類名，value存的是該類的實例化對象，通過這種方式來保證每次獲得的都是一個類的相同實例。
七、ThreadLocal執行緒單例
以ThreadLocal方式創建的單例對象是最為特殊的，因為它是一個偽單例，它只能保證同一個執行緒內創建的類的實例是相同的，有著天生的執行緒安全；但不能保證創建的類的實例是全局唯一的；先來看看程式碼：
public class ThreadLocalSingleton {
public ThreadLocalSingleton() {}
private static final ThreadLocal<ThreadLocalSingleton> threadLocal = new ThreadLocal(){
@Override
protected Object initialValue() {
return new ThreadLocalSingleton();
}
};
public static ThreadLocalSingleton getInstance(){
return threadLocal.get();
}
}
執行緒程式碼：
public class LazyThread implements Runnable {
@Override
public void run() {
ThreadLocalSingleton instance = ThreadLocalSingleton.getInstance();
System.out.println(Thread.currentThread().getName() + "：" +instance);
}
}
測試程式碼：
public static void main(String[] args) {
System.out.println(Thread.currentThread().getName() + "：" +ThreadLocalSingleton.getInstance());
System.out.println(Thread.currentThread().getName() + "：" +ThreadLocalSingleton.getInstance());
System.out.println(Thread.currentThread().getName() + "：" +ThreadLocalSingleton.getInstance());
System.out.println("————————————————————————————————————————");
Thread thread1 = new Thread(new LazyThread());
Thread thread2 = new Thread(new LazyThread());
thread1.start();
thread2.start();
}
結果：
從結果可以看出，再主執行緒main中，無論我們調用多少次getInstance()方法，獲得的ThreadLocalSingleton的實例都是相同的。而兩個子執行緒Thread-0和Thread-1都獲得了不同的實例。那麼這是怎麼做到了呢？
通過查看源碼（別問我為啥不貼源碼，問就是看不到，它的底層不是用Java寫的【流淚】，感興趣的小夥伴可以百度，有大神，我也是百度的，yyds！！！）我們發現，ThreadLocal將ThreadLocalSingleton類的實例對象全部放在了ThreadLocalMap中，為每一個執行緒提供了對象，實際上是以空間換時間來實現執行緒隔離的。這也使ThreadLocal技術頻繁的使用了於用戶登陸時，存儲用戶的登錄資訊方面。甚至於Mybatis中多個數據源切換的技術也是用它實現的。
最後
如果這篇文章對你有幫助的話，麻煩動動小手，點個贊，萬分感謝！！！
如果有小夥伴發現文章裡面有錯誤，歡迎來指正，不勝感激！！！
