Java 多線程同步 鎖機制與synchronized深入解析
打個比方:一個object就像一個大房子,大門永遠打開。房子里有很多房間(也就是方法)。這些房間有上鎖的(synchronized方法), 和不上鎖之分(普通方法)。房門口放著一把鑰匙(key),這把鑰匙可以打開所有上鎖的房間。另外我把所有想調(diào)用該對象方法的線程比喻成想進入這房子某個 房間的人。所有的東西就這么多了,下面我們看看這些東西之間如何作用的。
在此我們先來明確一下我們的前提條件。該對象至少有一個synchronized方法,否則這個key還有啥意義。當(dāng)然也就不會有我們的這個主題了。
一個人想進入某間上了鎖的房間,他來到房子門口,看見鑰匙在那兒(說明暫時還沒有其他人要使用上鎖的房間)。于是他走上去拿到了鑰匙,并且按照自己 的計劃使用那些房間。注意一點,他每次使用完一次上鎖的房間后會馬上把鑰匙還回去。即使他要連續(xù)使用兩間上鎖的房間,中間他也要把鑰匙還回去,再取回來。
因此,普通情況下鑰匙的使用原則是:“隨用隨借,用完即還?!?/P>
這時其他人可以不受限制的使用那些不上鎖的房間,一個人用一間可以,兩個人用一間也可以,沒限制。但是如果當(dāng)某個人想要進入上鎖的房間,他就要跑到大門口去看看了。有鑰匙當(dāng)然拿了就走,沒有的話,就只能等了。
要是很多人在等這把鑰匙,等鑰匙還回來以后,誰會優(yōu)先得到鑰匙?Not guaranteed。象前面例子里那個想連續(xù)使用兩個上鎖房間的家伙,他中間還鑰匙的時候如果還有其他人在等鑰匙,那么沒有任何保證這家伙能再次拿到。 (JAVA規(guī)范在很多地方都明確說明不保證,象Thread.sleep()休息后多久會返回運行,相同優(yōu)先權(quán)的線程那個首先被執(zhí)行,當(dāng)要訪問對象的鎖被 釋放后處于等待池的多個線程哪個會優(yōu)先得到,等等。我想最終的決定權(quán)是在JVM,之所以不保證,就是因為JVM在做出上述決定的時候,絕不是簡簡單單根據(jù) 一個條件來做出判斷,而是根據(jù)很多條。而由于判斷條件太多,如果說出來可能會影響JAVA的推廣,也可能是因為知識產(chǎn)權(quán)保護的原因吧。SUN給了個不保證 就混過去了。無可厚非。但我相信這些不確定,并非完全不確定。因為計算機這東西本身就是按指令運行的。即使看起來很隨機的現(xiàn)象,其實都是有規(guī)律可尋。學(xué)過 計算機的都知道,計算機里隨機數(shù)的學(xué)名是偽隨機數(shù),是人運用一定的方法寫出來的,看上去隨機罷了。另外,或許是因為要想弄的確定太費事,也沒多大意義,所 以不確定就不確定了吧。)
再來看看同步代碼塊。和同步方法有小小的不同。
1.從尺寸上講,同步代碼塊比同步方法小。你可以把同步代碼塊看成是沒上鎖房間里的一塊用帶鎖的屏風(fēng)隔開的空間。
2.同步代碼塊還可以人為的指定獲得某個其它對象的key。就像是指定用哪一把鑰匙才能開這個屏風(fēng)的鎖,你可以用本房的鑰匙;你也可以指定用另一個房子的鑰匙才能開,這樣的話,你要跑到另一棟房子那兒把那個鑰匙拿來,并用那個房子的鑰匙來打開這個房子的帶鎖的屏風(fēng)。
記住你獲得的那另一棟房子的鑰匙,并不影響其他人進入那棟房子沒有鎖的房間。
為什么要使用同步代碼塊呢?我想應(yīng)該是這樣的:首先對程序來講同步的部分很影響運行效率,而一個方法通常是先創(chuàng)建一些局部變量,再對這些變量做一些 操作,如運算,顯示等等;而同步所覆蓋的代碼越多,對效率的影響就越嚴(yán)重。因此我們通常盡量縮小其影響范圍。如何做?同步代碼塊。我們只把一個方法中該同 步的地方同步,比如運算。
另外,同步代碼塊可以指定鑰匙這一特點有個額外的好處,是可以在一定時期內(nèi)霸占某個對象的key。還記得前面說過普通情況下鑰匙的使用原則嗎?,F(xiàn)在不是普通情況了。你所取得的那把鑰匙不是永遠不還,而是在退出同步代碼塊時才還。
還用前面那個想連續(xù)用兩個上鎖房間的家伙打比方。怎樣才能在用完一間以后,繼續(xù)使用另一間呢。用同步代碼塊吧。先創(chuàng)建另外一個線程,做一個同步代碼 塊,把那個代碼塊的鎖指向這個房子的鑰匙。然后啟動那個線程。只要你能在進入那個代碼塊時抓到這房子的鑰匙,你就可以一直保留到退出那個代碼塊。也就是說 你甚至可以對本房內(nèi)所有上鎖的房間遍歷,甚至再sleep(10*60*1000),而房門口卻還有1000個線程在等這把鑰匙呢。很過癮吧。
在此對sleep()方法和鑰匙的關(guān)聯(lián)性講一下。一個線程在拿到key后,且沒有完成同步的內(nèi)容時,如果被強制sleep()了,那key還一直在 它那兒。直到它再次運行,做完所有同步內(nèi)容,才會歸還key。記住,那家伙只是干活干累了,去休息一下,他并沒干完他要干的事。為了避免別人進入那個房間 把里面搞的一團糟,即使在睡覺的時候他也要把那唯一的鑰匙戴在身上。
最后,也許有人會問,為什么要一把鑰匙通開,而不是一個鑰匙一個門呢?我想這純粹是因為復(fù)雜性問題。一個鑰匙一個門當(dāng)然更安全,但是會牽扯好多問題。鑰匙的產(chǎn)生,保管,獲得,歸還等等。其復(fù)雜性有可能隨同步方法的增加呈幾何級數(shù)增加,嚴(yán)重影響效率。這也算是一個權(quán)衡的問題吧。為了增加一點點安全性,導(dǎo)致效率大大降低,是多么不可取啊。
- Java 中 synchronized的用法詳解(四種用法)
- 深入理解java中的synchronized關(guān)鍵字
- Java中Synchronized的用法解析
- java多線程編程之使用Synchronized塊同步變量
- Java synchronized鎖升級jol過程詳解
- 詳解Java中synchronized關(guān)鍵字的死鎖和內(nèi)存占用問題
- Java中synchronized關(guān)鍵字修飾方法同步的用法詳解
- Java中synchronized的幾種使用方法
- Java 同步鎖(synchronized)詳解及實例
- 淺談Java并發(fā)編程之synchronized有序性誤區(qū)
相關(guān)文章
Java?Stream?API與函數(shù)式編程的實戰(zhàn)詳解
Java?8引入的Stream?API和函數(shù)式編程特性,徹底改變了Java開發(fā)者編寫代碼的方式,本文將深入探討Java?Stream?API與函數(shù)式編程的核心概念,最佳實踐以及性能優(yōu)化技巧,感興趣的小伙伴可以了解下2025-06-06
Springboot之@Controller注解不生效問題及解決
這篇文章主要介紹了Springboot之@Controller注解不生效問題及解決方案,具有很好的參考價值,希望對大家有所幫助,如有錯誤或未考慮完全的地方,望不吝賜教2023-10-10
Java使用Spire.PDF for Java實現(xiàn)輕松替換PDF文本
在數(shù)字化辦公日益普及的今天,PDF 文檔因其跨平臺、內(nèi)容固定的特性,成為企業(yè)合同、報告、發(fā)票等各類文檔的首選格式,本文將聚焦于如何利用 Java結(jié)合Spire.PDF for Java實現(xiàn) PDF 文檔中文本的自動化替換2025-11-11
Java中關(guān)于Collections集合工具類的詳細介紹
Java提供了一個操作Set、List和Map等集合的工具類:Collections,該工具提供了大量方法對集合元素進行排序、查詢和修改等操作,還提供了將集合對象設(shè)置為不可變、對集合對象實現(xiàn)同步控制等方法2021-09-09
容器環(huán)境的JVM內(nèi)存設(shè)置實踐記錄
Docker和K8S的興起,很多服務(wù)已經(jīng)運行在容器環(huán)境,對于java程序,JVM設(shè)置是一個重要的環(huán)節(jié),這里總結(jié)下我們項目里的最佳實踐,對容器環(huán)境的JVM內(nèi)存相關(guān)知識感興趣的朋友一起看看吧2022-03-03
Java中文件創(chuàng)建于寫入內(nèi)容的常見方法
在日常開發(fā)中,肯定離不開要和文件打交道,今天就簡單羅列一下平時比較常用的創(chuàng)建文件并向文件中寫入數(shù)據(jù)的幾種方式,希望對大家有一定的幫助2023-10-10

