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