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