前言：昨天公司計劃把項目中的部分功能做出sdk的形式，供其他公司的産品使用，是以不得不重新研究一下單例模式。
為什麼單例
1、在記憶體中隻有一個對象，節省記憶體空間。避免頻繁的建立銷毀對象，可以提高性能。避免對共享資源的多重占用。可以全局通路。
2、確定一個類隻有一個執行個體，自行執行個體化并向系統提供這個執行個體
單例需要注意的問題
1、線程安全問題
2、資源使用問題
實際上本文就是在讨論這兩個問題
優點：在未調用getinstance() 之前，執行個體就已經建立了，天生線程安全 缺點：如果一直沒有調用getinstance() , 但是已經建立了執行個體，造成了資源浪費。
優點：get() 方法被調用的時候，才建立執行個體，節省資源。 缺點：線程不安全。
這種模式，可以做到單例模式，但是隻是在單線程中是單例的，如果在多線程中操作，可能出現多個執行個體。
測試：啟動20個線程，然後線上程中列印 person 執行個體的記憶體位址
結果：可以看到出現了兩個執行個體
造成的原因：
線程a希望使用person，調用get()方法。因為是第一次調用，a就發現 person 是null的，于是它開始建立執行個體，就在這個時候，cpu發生時間片切換，線程b開始執行，它要使用 person ，調用get()方法，同樣檢測到 person 是null——注意，這是在a檢測完之後切換的，也就是說a并沒有來得及建立對象——是以b開始建立。b建立完成後，切換到a繼續執行，因為它已經檢測完了，是以a不會再檢測一遍，它會直接建立對象。這樣，線程a和b各自擁有一個 person 的對象——單例失敗！
總結：1、可以實作單線程單例
2、多線單例無法保證
改進：1、加鎖
經過測試，已經可以滿足多線程的安全問題了，synchronized修飾的同步塊可是要比一般的代碼段慢上幾倍的！如果存在很多次get()的調用，那性能問題就不得不考慮了！
優點：
1、滿足單線程的單例
2、滿足多線程的單例
缺點：
1、性能差
首先判斷person 是不是為null，如果為null，加鎖初始化；如果不為null，直接傳回 person 。整個設計，進行了雙重校驗。
1、滿足單線程單例
2、滿足多線程單例
3、性能問題得以優化
缺點：第一次加載時反應不快，由于java記憶體模型一些原因偶爾失敗
假設沒有關鍵字volatile的情況下，兩個線程a、b，都是第一次調用該單例方法，線程a先執行 person = new person()，該構造方法是一個非原子操作，編譯後生成多條位元組碼指令，由于java的指令重排序，可能會先執行 person 的指派操作，該操作實際隻是在記憶體中開辟一片存儲對象的區域後直接傳回記憶體的引用，之後 person 便不為空了，但是實際的初始化操作卻還沒有執行，如果就在此時線程b進入，就會看到一個不為空的但是不完整 （沒有完成初始化）的 person對象，是以需要加入volatile關鍵字，禁止指令重排序優化，進而安全的實作單例。
補充：看了圖檔加載架構 glide (3.7.0版) 源碼，發現glide 也是使用volatile 關鍵字的雙重校驗實作的單例，可見這種方法是值得信賴的。
優點：
1、資源使用率高，不執行getinstance()不被執行個體，可以執行該類其他靜态方法
使用
擷取執行個體對象：singleton.instance
調用其他方法：singleton.instance.show();
測試
結果：
可以看到用20個線程去通路對象的記憶體位址， 記憶體位址都是一樣的，保證了線程的安全性。
總結：
1、上面的7中方法，都實作了某種程度的單例，各有利弊，根據使用的場景不同，需要滿足的特性不同，選取合适的單例方法才是正道。
2、對線程要求嚴格，對資源要求不嚴格的推薦使用：1 餓漢式
3、對線程要求不嚴格，對資源要求嚴格的推薦使用：2 懶漢式
4、對線程要求稍微嚴格，對資源要求嚴格的推薦使用：4 雙重加鎖
5、同時對線程、資源要求非常嚴格的推薦使用：5 、 6