單例應該考慮的一些問題

2021-08-30 18:19:33 字數 985 閱讀 5630

說到單例模式可能大家都不陌生,都會用,但是如何才能寫出乙個健壯的單例模式,並擴充套件成適合專案的單例模式其實也是需要仔細思考的問題.通常我們實現單例的方式有幾種,在初始化的時候建立物件,另一種方式則是通過方法判斷是否為空,並建立物件返回。貌似看上去沒什麼太大差距,但事實上通過初始化時建立物件是執行緒安全的,通過方法獲得物件是需要考慮相稱安全的。

說到這裡,不得不說一下關於執行緒的問題,其實在最早的單核cpu時代,我們是不需要考慮建立物件的執行緒安全的,畢竟cpu在同一時間點只能做一件事情,但是在這個擁有雙核,四核的時代,我們不得不考慮這個問題.所以說我們不得不在判斷以及建立物件的時候對其進行同步,但是僅僅在此同步就ok了嘛,當然不是。因為就其本身也會存在同步的問題,用乙個例子來說明這一點,假如我們現在有1臺32位的雙核pc,當其處理64位long型資料時,其實是會將其分為高32位,與第32位兩部分來處理的,如果在非執行緒安全的情況下,則有機率導致一些髒資料.也因此出現了volatile來保證其原子性,並在jdk1.5以後出現了concurrent的基本型別.(-.-廢話多了點兒)

所以,如果不想在一開始就建立物件占用空間的話,那麼最好採用懶載入的方式,在初始化的時候將物件設定為靜態私有成員變數,並保持其原子性,並在呼叫方法判斷並建立物件時對其進行同步,以保證建立出唯一的物件.到此,我們才能真正保證其唯一性。

但是,往往我們的使用場景不是僅此而已,我們還會遇到序列化與反序列化的問題,我們還需要保證其序列化與反序列化是同一物件,所以我們必須對readsolve方法。

這樣我們基本就能建立出乙個健壯的單例物件了。

現在我們雖然能建立健壯的單例物件了,但是又有新的問題值得我們去思考了,什麼時候我們應該使用單例?

這還用說麼,什麼connection,factory等等,都是我們使用的場景.但是你覺得這真的就合適嗎?就我個人而言,我覺得乙個物件是否應該是單例通常都是由我們的使用場景所決定的,所以說像這樣硬編碼一開始就決定物件是單例,往往是不太科學的,其應該由容器所決定,是可配置的,這樣才能更加靈活。

從而也衍生出了變種的多例,及執行緒池,連線池等等.

關於c 中單例模式的一些問題

本文主要介紹了關於單例模式的一些問題,想學習c 單例模式的同學們可以看一看,還是有些幫助 c 中的單例模式 單例模式是指在設計乙個類時,保證在執行期間只有乙個例項物件,因為過多相同的例項物件會占用記憶體空間。舉個例子 1.宣告乙個靜態的class1類的變數來引用唯一的物件。2.創造私有的無參構造方法...

String 一些問題

前言 等號 對於基本型別,比較的是值,對於引用型別,比較的是記憶體位址。1.在物件池中建立,如果常量池中已經存在則返回常量池中已經有的。private static void test1 結果 true 2.乙個在string pool中,乙個在堆中。private static void test...

C 一些問題

1 if else語句和switch case語句的效率分析對比 switch效率高。switch的效率與分支數無關,當只有分支比較少的時候,if效率比switch高,因為switch有跳轉表。分支比較多,那當然是switch 根據大量的實際程式測試 不考慮不同的編譯器優化程度差異,假設都是最好的優...