JRockit使用了一種Lazy-Locking（也叫做Reservation Lock）的技術(shù)
?-XXlazyUnlocking
我當初是在一個日本IBM實驗室的一篇2004年的博士論文上看到的概念，保留鎖提出的背景是針對Java Synchronized時候，某個Java對象被1+個線程Aquired Lock的序列通常是某個線程占多的現(xiàn)象，后來發(fā)現(xiàn)這是一個普遍現(xiàn)象，可能幾乎超過75%的鎖爭奪都是發(fā)生在某個線程上（包括遞歸鎖），從鎖獲取的序列上看，大部分可能是：
T1 T1 T1 T1 T1 T1 T1 T1 T3 T1 T1 T1 T1 T2 T2 T1 T1 T1 T1
(T1, T2, T3是嘗試獲取Java Lock)
也就是，針對這種鎖現(xiàn)象，JVM設(shè)計人員開始采用Lazy-UnLocking的想法，即通過改變鎖設(shè)計，允許T1獲得鎖的時候，不需要CAS（Compare and Swap）原子性操作，這也是Lock Reservation(保留給T1)的由來；
而T3需要獲取當前Java鎖的時候，需要一個代價較為昂貴Cancel T1 Reservation的動作才能獲得鎖。
Java線程如果沒有頻繁Contention發(fā)生的時候，鎖延遲意味著不需要原子性操作便獲得對象，大大降低Java Lock在OS上的開銷。
Sun也有類似的技術(shù)，其實是在JDK 5.0之后便引入
-XX:+UseBiasedLocking
Enables a technique for improving the performance of uncontended synchronization. An object is "biased" toward the thread which first acquires its monitor via a
monitorenter bytecode or synchronized method invocation; subsequent monitor-related operations performed by that thread are relatively much faster on multiprocessor machines. Some applications with significant amounts of uncontended synchronization may attain significant speedups with this flag enabled; some applications with certain patterns of locking may see slowdowns, though attempts have been made to minimize the negative impact.?
實際上，Sun采用的
UseBiasedLocking是Initail Locker的方式，即第一個獲取鎖的線程，JVM會為它保留鎖(不需要原子性操作)，從而，在其后，該線程獲取鎖等同于uncontended synchronization的效果。
BEA JRockit R27.5提供的lazyUnlocking技術(shù)據(jù)說可以提升鎖性能超過1倍以上，從而簡直提高JVM性能達10%以上。
延遲鎖（或者保留鎖）都是忌諱頻繁的多線程競爭鎖的情形，比如，如果一個Java對象按照下面的序列被T1,T2,T3線程獲取，則保留鎖的效果是很差的。
T1，T2, T1, T2, T3, T1, T4, T3, T2......
我個人非常喜歡保留鎖，可能是我有所偏見，事實上我接觸的公司內(nèi)部的關(guān)于JRockit統(tǒng)計報告，都表明：
1，大量的Java應(yīng)用不會發(fā)生鎖競爭
2，Java鎖一般都符合保留鎖的條件，即大部分情況下，在某個時間片內(nèi)，都是鎖都是被某個線程獨占。