起因

最近找工作被面試官問到了設(shè)計模式方面的問題，而我一直只會寫點(diǎn)簡單的代碼，從來沒認(rèn)真學(xué)過啥設(shè)計模式，然后氣氛直接就尷尬了。。。
隨后急中生智，以前看別人代碼 getInstance用的挺多的，應(yīng)該是叫單例模式吧。所以就回答單例模式。
追問1: 如何解決單例模式的線程安全問題？
好吧，又是一個知識盲區(qū)，但是線程安全問題肯定要加鎖啊，感覺這一問應(yīng)該是可以糊弄過去。
追問2: 有沒有更好的辦法？
這一問把我問沉默了，當(dāng)時確實(shí)第一次面試，有點(diǎn)緊張，所以沒有答上來。后來一想，這問題真是TTM簡單了好吧。我不把實(shí)例化過程放在運(yùn)行時不就好了，一開始實(shí)例化好了不就不用再考慮多線程重復(fù)實(shí)例化了？然而當(dāng)時因?yàn)榫o張，沒有說出來。

但是后來一想，然后看了一些單例模式的資料后，發(fā)現(xiàn)對這個單例有一些自己的想法。

關(guān)于餓漢 單例模式

不知道為什么，人們普遍把一開始就實(shí)例化的單例模式叫餓漢模式，可能是因?yàn)镴VM太餓了，不管用不用的上，先實(shí)例化一個再說。
餓漢單例模式確實(shí)比加鎖的懶漢模式在多線程的時候表現(xiàn)更好一些，但是
疑問1： 會不會存在整個運(yùn)行過程中不調(diào)用該實(shí)例，而使餓漢模式不由分說直接實(shí)例化的行為變成一種對資源的浪費(fèi)的情況？
也就是說：你實(shí)例化那么早干什么，我還沒說要不要用你呢，你杵在那干啥，凈占地方！

疑問2： 存不存在要求單例可定制的情況？有沒有必要出現(xiàn)一種“多例”模式？
單例解決的是在多個不同地方對同一個類的調(diào)用時，該類重復(fù)實(shí)例化的問題。默認(rèn)這個類實(shí)例化的時候是不傳遞構(gòu)造參數(shù)的，也就是說 單例模式的實(shí)例不可定制。這保證了類可以一開始就 public static instance = new Class，但是同時也限制了自由。
比如一種場景：
我要建立一個Table類，它從單個文件中加載一些數(shù)據(jù)，然后供其它對象調(diào)用。但是實(shí)際上數(shù)據(jù)很多，分了好多文件保存，而我每一次運(yùn)行時只需要查詢其中幾個個文件的數(shù)據(jù)，如果有這種情況，我應(yīng)該如何用單例模式做到？
設(shè)想：多例模式?
對此我就想，可不可以用一種結(jié)構(gòu)實(shí)現(xiàn)更靈活的可定制的“多例”模式？
即：在類中維持一個實(shí)例集合，這個集合中有多個實(shí)例，每個實(shí)例有一個Key索引。比如我要查詢第4個文件的數(shù)據(jù)，則調(diào)用 getInstance(4)，如果發(fā)現(xiàn)沒有相應(yīng)實(shí)例，則Table類在實(shí)例集合中實(shí)例化一個構(gòu)造參數(shù)為4個Table對象。如此實(shí)現(xiàn)一個類似于緩沖的效果？
一個類根據(jù)不同參數(shù)，產(chǎn)生多個不同的實(shí)例，以適應(yīng)不同的調(diào)用。在保證只有同一個類的基礎(chǔ)上，實(shí)現(xiàn)實(shí)例的多樣化和自動管理。

這個多例模式我覺得是挺可行的，剛學(xué)設(shè)計模式，或許應(yīng)該有更好的辦法可以解決上面說道的Table的問題，或許我這個Table情景只是極特殊情況，根本沒有實(shí)際價值。。。

PS：好吧，繼續(xù)學(xué)習(xí)后發(fā)現(xiàn)，其實(shí)已經(jīng)有多例模式了，我能想到的人家早就想到了，還想得比我完善[淚]，看完不要罵我。

總結(jié)

以上是生活随笔為你收集整理的关于Java单例模式的思考的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。