接著說我們的單例故事。
想要解決上面的線程不安全問題，有很多種辦法，這里我們一一來探討。
第一種就是通過synchronized來控制線程安全，將synchronized加在getInstance方法上，
public static synchronized SingleFactory getInstance()
運(yùn)行下之前的main方法，是不是發(fā)現(xiàn)hashCode都一樣了？開心吧，這么嚴(yán)重的問題一下子就解決了。
~~~~
再來一盆冷水：
這種做法其實(shí)效率很低。因?yàn)樵谌魏螘r(shí)候只能有一個(gè)線程調(diào)用該方法，其余的需要加入等待，阻塞程度可想而知，如何解決這個(gè)問題呢？
我們來分析下，一般這種單例模式都會(huì)用在什么場合？是不是初始化的時(shí)候？
好的，我們姑且就認(rèn)為是初始化的時(shí)候，即第一次調(diào)用的時(shí)候創(chuàng)建對(duì)象，后續(xù)只存在調(diào)用的操作。那么就印出來我們之前提到的雙重檢驗(yàn)
鎖。

雙重檢驗(yàn)鎖
雙重檢驗(yàn)鎖（double checked locking pattern），是一種使用同步塊加鎖的方法。之所以稱之為雙重檢驗(yàn)鎖，是
因?yàn)闀?huì)有兩次檢驗(yàn) instance == null 的操作。一次是在同步塊外面，一次是在里面。
先來上代碼：

public static SingleFactory getInstance() {
    if (instance == null) {
        synchronized (SingleFactory.class) {
            if (instance == null) {
                instance = new SingleFactory();
            }
        }
    }
    return instance;
}

運(yùn)行后是不是發(fā)現(xiàn)也ok？
好了，我們來說一下為什么要在同步塊外面一次，里面又來一次。
因?yàn)楫?dāng)我們第一次初始化的時(shí)候，可能會(huì)有多個(gè)線程同時(shí)進(jìn)入外部的if判斷中，如果這個(gè)時(shí)候沒有對(duì)當(dāng)前類進(jìn)行同步塊加鎖，則很容易就出現(xiàn)多
個(gè)實(shí)例的狀態(tài)。因此我們需要在外面做次判斷，然后判斷里面加上一個(gè)同步塊。

~~~~
再來一盆冷水。
為啥？上面的代碼看起來很嚴(yán)謹(jǐn)，很完美啊，為什么還是不對(duì)？