單例模式是面向物件的編程語言23種設計模式之一，屬于創建型設計模式，主要用于解決物件的頻繁創建與銷毀問題，因為單例模式保證一個類僅會有一個實體，大部分對單例模式應該都知道一些，但面試的時候可能回答不會很完整，不能給自己加分，甚至扣分，
單一的知識點并不能對自己在面試的時候帶來加分，而系統的知識樹則會讓面試官另眼相看，而本文會系統的介紹單例模式的基礎版本與完美版本，基本上將單例模式的內容完全包括，如果認為有不同的意見可以留言交流，
原始碼已收錄github 查看原始碼
單例模式最重要的就是保證一個類只會出現一個實體，那么超過一個就不能被稱為是單例，所有其代碼構成如下特點，
- 私有化構造器，禁止從外部創建單例物件，
- 提供一個全域的訪問點獲取單例物件，
什么是全域訪問點？ 好吧，上面的話語太文鄒鄒了，如果我說公共的靜態方法呢？
餓漢、懶漢
主要分為餓漢模式和懶漢模式，那何為餓漢？何為懶漢？
小麗的爸爸從小生活很艱苦，經歷了饑荒年代，所以對食物非常緊張，當小麗去上學的時候，不管小麗是否需要，都會給小麗準備很多的零食，
而小明的爸爸則是一個非常懶惰的人，所有的事情都會到最后才去做，所有事情只有當有別人來叫他的時候，他才會把事情做完 這樣就引出了我們對餓漢模式和懶漢模式的定義：
餓漢模式：不管單例物件是否被使用，都會先創建出一個物件，餓漢模式存在資源浪費的問題，因為很有可能物件創建出來只會永遠都不會被使用到，
代碼如下：
package demo.single;
/**
* 餓漢模式
*/
public class HungrySingle {
/**
* 餓漢模式，不管hungrySingle物件是否有使用到，都會先創建出來
* 由于餓漢模式在物件使用之前就已經被創建，所以是不會存在執行緒安全問題
*/
private static HungrySingle hungrySingle = new HungrySingle();
/**
* 私有化構造器，禁止外部創建
*/
private HungrySingle(){
}
/**
* 提供獲取實體的方法
*/
public static HungrySingle getInstance(){
return hungrySingle;
}
}
懶漢模式：不會先將物件創建出來，而是等到有人使用的時候才會創建，相比餓漢模式，懶漢模式不會存在資源浪費的情況，所以基本都會選擇懶漢模式，
代碼如下：
package demo.single;
/**
* 懶漢模式
*/
public class LazySingle {
/**
* 懶漢模式，不會先創建物件，而是在呼叫的時候才會創建物件
*/
private static LazySingle lazySingle = null;
private LazySingle() {
}
/**
* 呼叫的時候創建物件并回傳
*/
public static LazySingle getInstance(){
if(lazySingle == null){
lazySingle = new LazySingle();
}
return lazySingle;
}
}
小李：面試官，您看我這樣的解釋可還行，
面試官：單執行緒下是挺好的，如果在多執行緒環境下呢？
小李：這個我知道，加鎖啊！
面試官：出門左轉電梯直達！
其實加鎖也沒答錯，關鍵問題在于如何加鎖！
直接將獲取實體的方法內容寫入同步代碼塊中，解決了多執行緒安全的問題，但是并發效率的問題又暴露了出來，你想啊，現在鎖住了這方法，而無論單例的物件是否創建，都會經過獲取鎖、釋放鎖的程序，這樣的性能顯然是不能接受的，
小李：我想想啊~~~！ Emmmmm...! 有了，我們可以在同步代碼塊外層加一個判斷，如果物件已經創建則直接回傳，
面試官：這樣解決了一部分的并發效率問題，但是如果在創建的時候同時有很多的執行緒訪問，是不是也會有并發的效率問題呢？再優化優化，
小李一想，確實是這樣，如果物件還沒有創建出來的時候，就有很多的執行緒來訪問，也會出現問題，假設有兩個執行緒同時訪問，當A執行緒優先爭搶到鎖，A進入同步代碼塊執行，此時B沒有爭搶到鎖，將處于等待狀態，而當A執行緒執行完成后釋放鎖，B進入同步代碼塊執行，此時B執行緒同樣會創建出一個物件，破壞了單例，
小李：面試官，我明白了，可以在同步代碼塊中再加一層if判斷，如果物件已經創建，就直接回傳即可，
Double Check
上面最后的結果就是我們常說的Double Check,即雙重鎖檢查，雙重鎖檢查在很多地方都被運用到，代碼如下，
package demo.single;
/**
* 懶漢模式
*/
public class LazySingle {
/**
* 懶漢模式，不會先創建物件，而是在呼叫的時候才會創建物件
*/
private static LazySingle lazySingle = null;
private LazySingle() {
}
/**
* 呼叫的時候創建物件并回傳
*/
public static LazySingle getInstance(){
//first check
if(lazySingle == null){
synchronized (LazySingle.class){
//double check
if(lazySingle == null){
lazySingle = new LazySingle();
}
}
}
return lazySingle;
}
}
面試官：小李，你多執行緒運行一下代碼看看呢，
小李：好勒！ 好像挺正常啊，等等， 好像不對， 這里還是出現了多個物件！！！啊~~，這是為什么啊，我都懵了，這完全超出了我的能力范圍，
面試官：哈哈，小子，這下知道誰是大佬了吧？我來給你好好解釋一下，其實，這和我們的代碼沒有關系，正常來講，應該不會出現這樣的問題，但是我們都知道，代碼在運行程序中，會被編譯成一條一條的指令運行，而JVM在運行時，在保證單執行緒最終結果不會受影響的情況下，對指令進行優化，就有可能對指令進行重排序，同樣會破壞單例，
lazySingle = new LazySingle();
//這樣一段代碼在運行時會生成3條指令，即： 1\. 分配記憶體空間 2\. 創建物件 3\. 指向參考
//正常情況下是會按照1 2 3順序執行，但JVM優化器進行指令重排后，則可能變為：1\. 分配記憶體空間 3\. 指向參考 2\. 創建物件
//在單執行緒下，這樣的優化沒有問題，但是多執行緒下，執行緒是在爭搶CPU時間碎片的，假設A剛剛執行完 1 3 //條指令，此時B爭搶到時間碎片，發現物件不為空了，就直接回傳，但此時物件還沒有真正被創建，B呼叫
//此物件就會拋出例外
//而volatile關鍵字修飾的變數可以禁止指令重排序，則可以保證指令會是1 2 3順序執行，
//加上volatile修飾
private volatile static LazySingle lazySingle = null;
小李： 終于解決了，好難啊，一個簡單的單例模式居然有這么多的細節，
面試官：你以為這就完了？
內部類的單例
使用內部類的方式可以非常完美的完成單例模式，而實作代碼也非常簡單，
package demo.single;
/**
* 內部類的方式實作單例
*/
public class InnerSingle {
/**
* 私有化構造器
*/
private InnerSingle(){
}
/**
* 私有內部類
*/
private static class Inner{
//Jingtai內部類持有外部類的物件
public static final InnerSingle SINGLE = new InnerSingle();
}
/**
* 回傳靜態內部類持有的物件
*/
public static InnerSingle getInstance(){
return Inner.SINGLE;
}
}
可以看到，代碼中并沒有出現同步方法或者同步代碼塊，那么靜態內部類的方式是如何做到安全的單例模式呢？
- 外部類加載的時候，不會立即加載內部類，而是在呼叫的時候會加載內部類，
- 不管多少執行緒訪問，JVM一定會保證類被正確的初始化，即靜態內部類的方式是在JVM層面保證了執行緒安全
當然，這樣也有一些缺點，那就是在創建單例物件的時候，如果需要傳參，那么靜態內部類的方式會非常麻煩，
破壞單例
那么，上面的單例已經完美了嗎？并沒有，看我如何將單例給破壞掉，
反射破壞
反射可以繞過私有構造器的限制，創建物件，當然正常的呼叫是不會發生單例被破壞的情況，但是如果偏偏有人不走尋常路呢，比如下面的呼叫，
package demo.single;
import java.lang.reflect.Constructor;
/**
* 反射破壞單例
*/
public class RefBreakSingleTest {
public static void main(String[] args) throws Exception {
//獲取類物件
Class<LazySingle> lazySingleClass = LazySingle.class;
//獲取構造器
Constructor<LazySingle> constructor = lazySingleClass.getDeclaredConstructor(null);
constructor.setAccessible(true);
//創建物件
LazySingle lazySingle = constructor.newInstance(null);
System.out.println(lazySingle);
System.out.println(LazySingle.getInstance());
System.out.println(lazySingle == LazySingle.getInstance());
}
}
image
<figcaption>測驗結果</figcaption>
很明顯看到出現了兩個不同的兌現，顯然，單例被破壞了！ 對于這樣的情況該如何禁止呢？在網上查閱了很多資料，大部分是使用變數控制法，即在類中添加一個變數用于判斷單例類的構造器是否有被呼叫，代碼如下，
//添加變數控制,防止反射破壞
private static boolean isInstance = false;
private volatile static LazySingle lazySingle = null;
private LazySingle() throws Exception {
if(isInstance){
throw new Exception("the Constructor has be used");
}
isInstance = true;
}
再次呼叫測驗代碼，發現不能再創建多個單例物件，程式拋出了例外，
image
<figcaption></figcaption>
但是別忘了，屬性也是可以通過反射修改的(count、instance的判斷反射都能繞過)，
public class RefBreakSingleTest {
public static void main(String[] args) throws Exception {
//獲取類物件
Class<LazySingle> lazySingleClass = LazySingle.class;
//獲取構造器
Constructor<LazySingle> constructor = lazySingleClass.getDeclaredConstructor(null);
constructor.setAccessible(true);
//創建物件
LazySingle lazySingle = constructor.newInstance(null);
System.out.println(lazySingle);
Field isInstance = lazySingleClass.getDeclaredField("isInstance");
isInstance.setAccessible(true);
isInstance.set(null,false);
System.out.println(LazySingle.getInstance());
System.out.println(lazySingle == LazySingle.getInstance());
}
}
image
<figcaption></figcaption>
單例再次被破壞，感覺是不是已經快崩潰了，一個單例咋這么多事呢！！既然私有屬性、私有方法在外部都能通過反射獲取，那有沒有反射不能獲取的呢？我在網上也找到了另外一種寫法，即私有內部類的來持有實體控制變數，而我也通過測驗，發現反射同樣能夠繞過從而破壞單例，
package demo.pattren.single;
import java.lang.reflect.Constructor;
import java.lang.reflect.Method;
public class BreakInnerTest {
public static void main(String[] args) throws Exception {
Class<LazySingle> lazySingleClass = LazySingle.class;
// //獲取構造器
Constructor<LazySingle> constructor = lazySingleClass.getDeclaredConstructor(null);
constructor.setAccessible(true);
//創建物件
LazySingle lazySingle = constructor.newInstance(null);
//獲取內部類的類物件
Class<?> aClass = Class.forName("demo.pattren.single.LazySingle$InnerClass");
Method[] methods = aClass.getMethods();
Constructor<?>[] declaredConstructors = aClass.getDeclaredConstructors();
System.out.println(declaredConstructors);
Constructor<?> declaredConstructor = declaredConstructors[0];
declaredConstructor.setAccessible(true);
//創建內部類需要傳入一個外部類的物件
Object o = declaredConstructor.newInstance(lazySingle);
//成功繞過
methods[0].invoke(o);
}
}
目前網上基本都是這兩種，但是反射都是能夠繞過判斷進行破壞，可以這樣認為，這種方式反射是可以破壞的，不能100%保證單例不被破壞，歡迎各位提供完美的示例，
序列化破壞
Java的IO提供了物件流，用來將物件寫入磁盤、從磁盤讀取物件的功能，這也成為了單例的破壞點，
public static void main(String[] args) throws Exception {
//正常的方式獲取單例物件
InnerSingle instance = InnerSingle.getInstance();
//寫入磁盤
FileOutputStream fos = new FileOutputStream("d:/single");
ObjectOutputStream oos = new ObjectOutputStream(fos);
oos.writeObject(instance);
oos.close();
fos.close();
//從磁盤讀取物件
FileInputStream fis = new FileInputStream("d:/single");
ObjectInputStream ois = new ObjectInputStream(fis);
InnerSingle innerSingle = (InnerSingle) ois.readObject();
System.out.println(instance);
System.out.println(innerSingle);
System.out.println(innerSingle == instance);
}
image
<figcaption></figcaption>
而序列化的方式JVM提供了一種機制，可以防止單例被破壞，即在單例類中添加readResovle方法，
//在反序列化時，readResolve方法，則直接回傳該方法指定的物件
private Object readResolve(){
return getInstance();
}
測驗結果：
image
<figcaption></figcaption>
序列化沒有再破壞單例，而這一切JDK是如何處理的呢？
public final Object readObject()
throws IOException, ClassNotFoundException
{
if (enableOverride) {
return readObjectOverride();
}
int outerHandle = passHandle;
try {
//關鍵代碼，最侄訓傳的是此方法回傳的物件
Object obj = readObject0(false);
handles.markDependency(outerHandle, passHandle);
ClassNotFoundException ex = handles.lookupException(passHandle);
//more code but not importent
繼續深入,發現readObject0方法的關鍵代碼如下
byte tc;
//取出檔案的一個位元組，判斷讀取的物件型別
while ((tc = bin.peekByte()) == TC_RESET) {
bin.readByte();
handleReset();
}
depth++;
totalObjectRefs++;
try {
switch (tc) {
case TC_NULL:
return readNull();
case TC_ENUM:
return checkResolve(readEnum(unshared));
//判斷為物件類
case TC_OBJECT:
return checkResolve(readOrdinaryObject(unshared));
//more othrer case
繼續追蹤readOrdinaryObject方法，發現readReslove的關鍵代碼
//判斷是否有readReslove方法(desc.hasReadResolveMethod())
if (obj != null &&
handles.lookupException(passHandle) == null &&
desc.hasReadResolveMethod())
{
//執行readReslove
Object rep = desc.invokeReadResolve(obj);
if (unshared && rep.getClass().isArray()) {
rep = cloneArray(rep);
}
if (rep != obj) {
// Filter the replacement object
if (rep != null) {
if (rep.getClass().isArray()) {
filterCheck(rep.getClass(), Array.getLength(rep));
} else {
filterCheck(rep.getClass(), -1);
}
}
//最侄訓傳readReslove方法的執行結果
handles.setObject(passHandle, obj = rep);
}
}
return obj;
列舉單例 - 最完美的單例模式
大神Josh Bloch在《Effective Java》中極力推薦使用列舉的方式來實作單例，
package demo.single;
public enum EnumSingle {
SINGLE;
public void doJob(){
System.out.println("doJob");
}
}
列舉型別是單例模式的最佳選擇，主要得益于JVM對于列舉型別的支持：
- JVM保證列舉型別的每個實體僅存在一份
- 列舉型別的序列化與反序列化不會破壞其單例的特性(上面的原始碼大家可以去找一找)
- 反射也不能破壞列舉單例
可以說，列舉天然就是單例的，那么你會選擇列舉作為單例嗎？
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/6166.html
標籤：其他
上一篇：恕我直言，90% 的程式員都扛不住這波JVM的面試題！
下一篇：dubbo學習之事件通知實踐