關(guān)于JVM的Thin Lock, Fat Lock, SPIN Lock與Tasuki Lock
Java很多ThreadDump中,都可以看到Thin Lock, Fat Lock, Spin Lock,這些Lock都與Java語(yǔ)言、OS有密切的關(guān)系。回到一個(gè)簡(jiǎn)單的問題,在Java中,如何實(shí)現(xiàn)Synchronizd?
最簡(jiǎn)單的一種做法是,利用OS的mutex機(jī)制,把Java的同步(基于Object),翻譯成OS相關(guān)的monitor_enter和monitor_exit原語(yǔ)。
回到Java鎖本身,鎖在不同的應(yīng)用下有著不同的統(tǒng)計(jì)表現(xiàn),而大部分的統(tǒng)計(jì)數(shù)據(jù)表明,其實(shí)線程搶鎖,即鎖競(jìng)爭(zhēng),都是短暫的,在大部分的情況下,幾乎都不會(huì)發(fā)生鎖競(jìng)爭(zhēng)的現(xiàn)象。
也就是說,Java鎖,從安全性的角度來看,是有點(diǎn)累贅。
因此,大量的專家都在鎖上針對(duì)這樣的統(tǒng)計(jì)特性對(duì)Java鎖進(jìn)行優(yōu)化。
其中一種優(yōu)化方案是,我們對(duì)所有的鎖都需要monitor_enter和monitor_exit嗎?事實(shí)上不需要。
如果我們把monitor_enter/monitor_exit看成是Fat Lock方式,則可以把Thin Lock看成是一種基于CAS(Compare and Swap)的簡(jiǎn)易實(shí)現(xiàn)。
這兩種鎖,簡(jiǎn)單一點(diǎn)理解,就是:
而基于CAS方式的實(shí)現(xiàn),線程進(jìn)入競(jìng)爭(zhēng)狀態(tài)的,獲得鎖的線程,會(huì)讓其他線程處于自旋狀態(tài)(也稱之為Spin Mode,即自旋),這是一種while(Lock_release) doStuff()的Busy-Wait方式,是一種耗CPU的方式;而Fat Lock方式下,一個(gè)線程獲得鎖的時(shí)候,其他線程可以先sleep,等鎖釋放后,再喚醒(Notify)。
CAS的優(yōu)點(diǎn)是快,如果沒有線程競(jìng)爭(zhēng)的情況下,因?yàn)镃AS只需要一個(gè)指令便獲得鎖,所以稱之為Thin Lock,缺點(diǎn)也是很明顯的,即如果頻繁發(fā)生線程競(jìng)爭(zhēng),CAS是低效,主要表現(xiàn)為,排斥在鎖之外的線程是Busy Wait狀態(tài);而monitor_enter/monitor_exit/monitor_notify方式,則是重量級(jí)的,在線程產(chǎn)生競(jìng)爭(zhēng)的時(shí)候,F(xiàn)at Lock在OS mutex方式下,可以實(shí)現(xiàn)no busy-wait。
于是,JVM早期版本的做法是,如果T1, T2,T3,T4...產(chǎn)生線程競(jìng)爭(zhēng),則T1通過CAS獲得鎖(此時(shí)是Thin Lock方式),如果T1在CAS期間獲得鎖,則T2,T3進(jìn)入SPIN狀態(tài)直到T1釋放鎖;而第二個(gè)獲得鎖的線程,比如T2,會(huì)將鎖升級(jí)(Inflation)為Fat Lock,于是,以后嘗試獲得鎖的線程都使用Mutex方式獲得鎖。
這種設(shè)計(jì)為鎖提供了兩條路徑:Thin Lock路徑和Fat Lock路徑,大部分情況下,可能都是走Thin Lock路徑,而可能少部分情況,是走Fat Lock路徑,這種方式提供了鎖升級(jí),但是避免不了Busy Wait,而且Thin-Lock升級(jí)Fat-Lock之后,沒有辦法回退到Thin-Lock(性能比Fat-Lock更好)。
Tasuki鎖為這種方式做了2個(gè)優(yōu)化:
1) 避免CAS導(dǎo)致Busy wait
2)?Fat Lock可以deflate(與Inflate剛好相反)為Thin Lock(之前是Thin Lock變成Fat Lock之后便不能再回退)。
經(jīng)過這樣的改造后,鎖性能提高了10%以上。
目前,Oracle的BEA JRockit與IBM的JVM都實(shí)現(xiàn)了Tasuki鎖機(jī)制,唯一的不同是,在鎖實(shí)現(xiàn)上都做了不同啟發(fā)式的設(shè)計(jì),即根據(jù)運(yùn)行時(shí)采樣的數(shù)據(jù),動(dòng)態(tài)調(diào)整一些權(quán)值數(shù)據(jù),一邊左右Lock Inflation/Lock Defaltion的過程(一顆樹的兩個(gè)分支),獲取更好的鎖性能。
對(duì)JVM鎖有興趣的朋友可以與我聯(lián)系(mail:weblogic在vip.qq.com)
另外一種針對(duì)鎖的優(yōu)化手段,叫做Lazy-Unlocking,可以在Tasuki Lock之上構(gòu)造,可以參見我另外一篇隨筆
http://www.aygfsteel.com/security/archive/2009/02/12/Lazy_Java_Lock.html
posted on 2009-02-16 14:49 david.turing 閱讀(8404) 評(píng)論(3) 編輯 收藏 所屬分類: JVM