標籤:對象 多個 應該 兩種 windows 必須 之間 記憶體 訪問
Java Singleton模式主要作用是保證在Java應用程式中,一個類Class只有一個執行個體存在。 使用Singleton的好處還在於可以節省記憶體,因為它限制了執行個體的個數,有利於Java記憶體回收(garbage collection)。
我們在瀏覽BBS、SNS網站的時候,常常會看到“當前線上人數”這樣的一項內容。對於這樣的一項功能,我們通常的做法是把當前的線上人數存放到一個記憶體、檔案或者資料庫中,每次使用者登入的時候,就會馬上從記憶體、檔案或者資料庫中取出,在其基礎上加1後,作為當前的線上人數進行顯示,然後再把它儲存回記憶體、檔案或者資料庫裡,這樣後續登入的使用者看到的就是更新後的當前線上人數;同樣的道理,當使用者退出後,當前線上人數進行減1的工作。所以,對於這樣的一個需求,我們按照物件導向的設計思想,可以把它抽象為“線上計數器”這樣一個對象。
網站代碼中凡是用到計數器的地方,只要new一個計數器對象,然後就可以擷取、儲存、增加或者減少線上人數的數量。不過,我們的代碼實際的使用效果並不好。假如有多個使用者同時登入,那麼在這個時刻,通過計數器取到的線上人數是相同的,於是他們使用各自的計數器加1後存入檔案或者資料庫。這樣操作後續登陸的使用者得到的線上人數,與實際的線上人數並不一致。所以,把這個計數器設計為一個全域對象,所有人都共用同一份資料,就可以避免類似的問題,這就是我們所說的單例模式的其中的一種應用。
單例模式能夠保證一個類僅有唯一的執行個體,並提供一個全域訪問點。
我們是不是可以通過一個全域變數來實現單例模式的要求呢?我們只要仔細地想想看,全域變數確實可以提供一個全域訪問點,但是它不能防止別人執行個體化多個對象。通過外部程式來控制的對象的產生的個數,勢必會系統的增加管理成本,增大模組之間的耦合度。所以,最好的解決辦法就是讓類自己負責儲存它的唯一執行個體,並且讓這個類保證不會產生第二個執行個體,同時提供一個讓外部對象訪問該執行個體的方法。自己的事情自己辦,而不是由別人代辦,這非常符合物件導向的封裝原則。
單例模式主要有3個特點,:
1、單例類確保自己只有一個執行個體。
2、單例類必須自己建立自己的執行個體。
3、單例類必須為其他對象提供唯一的執行個體。
單例模式的實現方式:懶漢單例類和餓漢單例類
單例模式的實現有多種方法,常見的就有懶漢式單例類和餓漢式單例類。我們前面介紹的實現方法就屬於懶漢式單例類。
· 懶漢式單例類
對於懶漢模式,我們可以這樣理解:該單例類非常懶,只有在自身需要的時候才會行動,從來不知道及早做好準備。它在需要對象的時候,才判斷是否已有對象,如果沒有就立即建立一個對象,然後返回,如果已有對象就不再建立,立即返回。
懶漢模式只在外部對象第一次請求執行個體的時候才去建立。
· 餓漢式單例
對於餓漢模式,我們可以這樣理解:該單例類非常餓,迫切需要吃東西,所以它在類載入的時候就立即建立對象。
我們對比一下懶漢模式和餓漢模式的優缺點:
懶漢模式,它的特點是運行時獲得對象的速度比較慢,但載入類的時候比較快。它在整個應用的生命週期只有一部分時間在佔用資源。
餓漢模式,它的特點是載入類的時候比較慢,但運行時獲得對象的速度比較快。它從載入到應用結束會一直佔用資源。
這兩種模式對於初始化較快,佔用資源少的輕量級對象來說,沒有多大的效能差異,選擇懶漢式還是餓漢式都沒有問題。但是對於初始化慢,佔用資源多的重量級對象來說,就會有比較明顯的差別了。所以,對重量級對象應用餓漢模式,類載入時速度慢,但運行時速度快;懶漢模式則與之相反,類載入時速度快,但運行時第一次獲得對象的速度慢。
從使用者體驗的角度來說,我們應該首選餓漢模式。我們願意等待某個程式花較長的時間初始化,卻不喜歡在程式運行時等待太久,給人一種反應遲鈍的感覺,所以對於有重量級對象參與的單例模式,我們推薦使用餓漢模式。
而對於初始化較快的輕量級對象來說,選用哪種方法都可以。如果一個應用中使用了大量單例模式,我們就應該權衡兩種方法了。輕量級對象的單例採用懶漢模式,減輕載入時的負擔,縮短載入時間,提高載入效率;同時由於是輕量級對象,把這些對象的建立放在使用時進行,實際就是把建立單例對象所消耗的時間分攤到整個應用中去了,對於整個應用的運行效率沒有太大影響。
什麼情況下使用單例模式
單例模式也是一種比較常見的設計模式,它到底能帶給我們什麼好處呢?其實無非是三個方面的作用:
第一、控制資源的使用,通過線程同步來控制資源的並發訪問;
第二、控制執行個體產生的數量,達到節約資源的目的。
第三、作為通訊媒介使用,也就是資料共用,它可以在不建立直接關聯的條件下,讓多個不相關的兩個線程或者進程之間實現通訊。
比如,資料庫連接池的設計一般採用單例模式,資料庫連接是一種資料庫資源。軟體系統中使用資料庫連接池,主要是節省開啟或者關閉資料庫連接所引起的效率損耗,這種效率上的損耗還是非常昂貴的。當然,使用資料庫連接池還有很多其它的好處,可以屏蔽不同資料資料庫之間的差異,實現系統對資料庫的低度耦合,也可以被多個系統同時使用,具有高可複用性,還能方便對資料庫連接的管理等等。資料庫連接池屬於重量級資源,一個應用中只需要保留一份即可,既節省了資源又方便管理。所以資料庫連接池採用單例模式進行設計會是一個非常好的選擇。
在我們日常使用的在Windows中也有不少單例模式設計的組件,象常用的檔案管理工具。由於Windows作業系統是一個典型的多進程多線程系統,那麼在建立或者刪除某個檔案的時候,就不可避免地出現多個進程或線程同時操作一個檔案的現象。採用單例模式設計的檔案管理工具就可以完美的解決這個問題,所有的檔案操作都必須通過唯一的執行個體進行,這樣就不會產生混亂的現象。
再比如,每台電腦可以有若干個印表機,如果每一個進程或者線程都獨立地使用印表機資源的話,那麼我們列印出來的結果就有可能既包含這個列印任務的一部分,又包含另外一個列印任務的一部分。所以,大多數的作業系統最終為列印任務設計了一個單例模式的假離線服務Printer Spooler,所有的列印任務都需要通過假離線服務進行。
實際上,配置資訊類、管理類、控制類、門面類、代理類通常被設計為單例類。像Java的Struts、Spring架構,.Net的Spring.Net架構,以及Php的Zend架構都大量使用了單例模式。
詳細內容請參考:
使用單例模式最核心的一點是體現了物件導向封裝特性中的“單一職責”和“對象自治”原則。
很多時候我們要保證類的執行個體只有一個。我們可能在自己的代碼中判斷需要的類的執行個體有無,無就new一個。這樣看似不錯。問題是,你用到這個類的地方有n個,這樣你就需要n個判斷。為什麼不把這個職責交給類本身呢?然後讓類提供一個介面訪問。
【轉】Java中用單例模式有什麼好處