單例模式作為一種創建型模式，在日常開發中用處極廣，我們先來看一一段代碼：
// 建構式
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 = https://www.cnblogs.com/caimm/p/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中多個資料源切換的技術也是用它實作的，
最后
如果這篇文章對你有幫助的話，麻煩動動小手，點個贊，萬分感謝！！！
如果有小伙伴發現文章里面有錯誤，歡迎來指正，不勝感激！！！
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/288420.html
標籤：Java