建站
咨詢
售后
建站咨詢
新聞中心
單例可以說是最簡(jiǎn)單的一個(gè)設(shè)計(jì)模式了，單例模式要求只能創(chuàng)建一個(gè)對(duì)象實(shí)例。通常的寫法是聲明私有的構(gòu)造函數(shù)，提供靜態(tài)方法獲取單例的對(duì)象實(shí)例。
成都創(chuàng)新互聯(lián)是一家專注網(wǎng)站建設(shè)、網(wǎng)絡(luò)營銷策劃、微信小程序、電子商務(wù)建設(shè)、網(wǎng)絡(luò)推廣、移動(dòng)互聯(lián)開發(fā)、研究、服務(wù)為一體的技術(shù)型公司。公司成立十載以來，已經(jīng)為千余家成都火鍋店設(shè)計(jì)各業(yè)的企業(yè)公司提供互聯(lián)網(wǎng)服務(wù)。現(xiàn)在，服務(wù)的千余家客戶與我們一路同行，見證我們的成長；未來，我們一起分享成功的喜悅。
常見的單例寫法就是餓漢式、懶漢式、雙重加鎖驗(yàn)證、靜態(tài)內(nèi)部類和枚舉的方式，寫法可能大家都知道，不過針對(duì)不同的寫法還是有可以繼續(xù)深挖一下的地方，讓我們從最簡(jiǎn)單的幾種寫法開始回顧單例，不想看前面的話直接往后翻好了。
回顧幾種實(shí)現(xiàn)方式
餓漢式
餓漢式的寫法通常靜態(tài)成員變量已經(jīng)是初始化好的，優(yōu)點(diǎn)是可以不加鎖就獲取到對(duì)象實(shí)例，線程安全，主要的缺點(diǎn)在于不是延加載，稍微存在內(nèi)存的浪費(fèi)，因?yàn)槿绻跏蓟倪壿嬢^為復(fù)雜，比如存在網(wǎng)絡(luò)請(qǐng)求或者一些復(fù)雜的邏輯在內(nèi)，就會(huì)產(chǎn)生內(nèi)存的浪費(fèi)。
懶漢式
懶漢式的寫法解決了餓漢式浪費(fèi)內(nèi)存的問題，在真正需要獲取實(shí)例對(duì)象的才去執(zhí)行初始化。
通常一般來說可能會(huì)有兩種方式，第一種就是不加鎖的寫法，很顯然這樣是肯定不行的，正常的方式一般都是通過同步鎖的方式加鎖獲取實(shí)例對(duì)象。
但是這種實(shí)現(xiàn)方式在之前的JDK版本synchronized沒有鎖優(yōu)化的情況每次獲取單例對(duì)象性能存在很大的問題，于是乎有了DCL的寫法。
雙重加鎖驗(yàn)證DCL
于是為了解決懶漢式性能的問題，雙重加鎖驗(yàn)證的寫法誕生了，先判斷一次空，真的為空再執(zhí)行加鎖，然后再判斷一次。
這樣的話，只有在實(shí)例對(duì)象是空的情況才會(huì)去加鎖創(chuàng)建對(duì)象，性能問題得到了一定程度上的解決，也不會(huì)和餓漢一樣有內(nèi)存浪費(fèi)的問題。
但是，這個(gè)寫法也存在問題，就是會(huì)拿到未初始化完全的對(duì)象，我之前的一篇文章中也提到這個(gè)方式的問題，具體請(qǐng)看一次群聊引發(fā)的血案。
讓我這里復(fù)用一下我寫過的東西。
- 從CPU的角度來看，instance = new Instance()可以分為分為幾個(gè)步驟：
- 分配對(duì)象內(nèi)存空間
- 執(zhí)行構(gòu)造方法，對(duì)象初始化
instance指向分配的內(nèi)存地址
實(shí)際上，由于指令重排的問題，2、3的步驟可能會(huì)發(fā)生重排序，那么問題就發(fā)生了。
instance先被指向內(nèi)存地址，然后再執(zhí)行初始化，如果此時(shí)另外一個(gè)線程來訪問getInstance方法，就會(huì)拿到instance不是null，最后拿到的將是一個(gè)沒有被完全初始化的對(duì)象!
現(xiàn)在也有很多人說這個(gè)問題在高版本的JDK中已經(jīng)解決了，但是我是沒發(fā)現(xiàn)有什么直接證據(jù)，如果你知道，請(qǐng)你告訴我。
靜態(tài)內(nèi)部類
這個(gè)通過JVM來保證創(chuàng)建單例對(duì)象的線程安全和唯一性，是比較好的辦法。
Singleton類加載的時(shí)候，SingletonHolder不會(huì)加載，只有在調(diào)用getInstance方法的時(shí)候才會(huì)執(zhí)行初始化，這樣既起到了懶加載的作用，同時(shí)又使用到了JVM類加載機(jī)制，保證了單例對(duì)象初始化的線程安全。
這種方式也是目前比較推薦的一種方式。
枚舉
通過枚舉來實(shí)現(xiàn)單例是Effective Java作者 Josh Bloch 提倡的方式，也是單例模式的最佳實(shí)現(xiàn)方式。
為了看清楚枚舉怎么實(shí)現(xiàn)單例模式的，我們來編譯一下枚舉生成的最終字節(jié)碼。
執(zhí)行javac Singleton.java生成class文件，接著執(zhí)行javap -p Singleton.class，得到如下內(nèi)容：
為了看到更詳細(xì)的內(nèi)容，我們執(zhí)行 javap -c Singleton。
通過最終生成的字節(jié)碼，我們其實(shí)發(fā)現(xiàn)本質(zhì)上枚舉的初始化通過static代碼塊來進(jìn)行初始化。
考慮下類加載的幾個(gè)步驟，加載->驗(yàn)證->準(zhǔn)備->解析->初始化，最終初始化就是執(zhí)行static代碼塊，而static代碼塊是絕對(duì)線程安全的，只能由JVM來調(diào)度，這樣保證了線程安全。
枚舉的實(shí)現(xiàn)方式好處還不止于此，除了一目了然的實(shí)現(xiàn)簡(jiǎn)單之外，還能防止其他幾種實(shí)現(xiàn)方式避免不了的幾個(gè)問題。
再說幾種方式的問題
反射破壞單例
除了枚舉之外，其他的幾種方式都可以通過反射的方式達(dá)到破壞單例的目的，就隨便以一個(gè)實(shí)現(xiàn)方式來舉例，這里最終的輸出結(jié)果是false。
如果拿去嘗試反射創(chuàng)建枚舉對(duì)象的話，則是會(huì)報(bào)錯(cuò)，可以自己動(dòng)手嘗試一下。
為什么會(huì)報(bào)錯(cuò)，可以直接看一下newInstance的源碼，有一段特殊的關(guān)于枚舉類型的判斷，下圖中我紅色標(biāo)記的部分。
序列化
除了眾所周知的使用反射來破壞單例之外，還有另外一種能破壞單例的方式就是序列化。
對(duì)上面的餓漢方法實(shí)現(xiàn)序列化，然后得到的結(jié)果是false，序列化前后對(duì)象發(fā)生了改變。
其實(shí)關(guān)鍵的部分在于ois.readObject方法，一路跟蹤最后找到一段代碼如下：
所以很明顯我們發(fā)現(xiàn)了最終實(shí)際上這里通過反射創(chuàng)建了一個(gè)新的對(duì)象，isInstantiable實(shí)際代表的應(yīng)該是類或者屬性是序列化的，那么久就返回true，我們這里肯定是true，所以最終產(chǎn)生了一個(gè)新的對(duì)象。
枚舉為啥可以防止這個(gè)問題?枚舉的實(shí)現(xiàn)方式不太一樣而已，同樣跟蹤到枚舉部分的實(shí)現(xiàn)邏輯。
下圖中紅框標(biāo)注的部分就是枚舉類型去實(shí)現(xiàn)反序列化的邏輯，最終只是通過valueOf方法查找枚舉，不存在新建一個(gè)對(duì)象的邏輯。
那么，怎么防止其他方式序列化對(duì)單例的破壞?再往下看看源碼，紅框標(biāo)注的意思只要有readResolve方法就可以解決問題了。
實(shí)際上，最終解決方案也很簡(jiǎn)單，單例類加上方法即可。
好了，打完收工。現(xiàn)在是北京時(shí)間4月15日凌晨1點(diǎn)整，困了，睡覺。
當(dāng)前名稱：一個(gè)單例還能寫出花來嗎？
轉(zhuǎn)載來于：http://www.dlmjj.cn/article/djsdeip.html
