JRockit使用了一種Lazy-Locking（也叫做Reservation Lock）的技術(shù)
?-XXlazyUnlocking
我當(dāng)初是在一個(gè)日本IBM實(shí)驗(yàn)室的一篇2004年的博士論文上看到的概念，保留鎖提出的背景是針對(duì)Java Synchronized時(shí)候，某個(gè)Java對(duì)象被1+個(gè)線程Aquired Lock的序列通常是某個(gè)線程占多的現(xiàn)象，后來(lái)發(fā)現(xiàn)這是一個(gè)普遍現(xiàn)象，可能幾乎超過(guò)75%的鎖爭(zhēng)奪都是發(fā)生在某個(gè)線程上（包括遞歸鎖），從鎖獲取的序列上看，大部分可能是：
T1 T1 T1 T1 T1 T1 T1 T1 T3 T1 T1 T1 T1 T2 T2 T1 T1 T1 T1
(T1, T2, T3是嘗試獲取Java Lock)
也就是，針對(duì)這種鎖現(xiàn)象，JVM設(shè)計(jì)人員開始采用Lazy-UnLocking的想法，即通過(guò)改變鎖設(shè)計(jì)，允許T1獲得鎖的時(shí)候，不需要CAS（Compare and Swap）原子性操作，這也是Lock Reservation(保留給T1)的由來(lái)；
而T3需要獲取當(dāng)前Java鎖的時(shí)候，需要一個(gè)代價(jià)較為昂貴Cancel T1 Reservation的動(dòng)作才能獲得鎖。
Java線程如果沒有頻繁Contention發(fā)生的時(shí)候，鎖延遲意味著不需要原子性操作便獲得對(duì)象，大大降低Java Lock在OS上的開銷。
Sun也有類似的技術(shù)，其實(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.?
實(shí)際上，Sun采用的
UseBiasedLocking是Initail Locker的方式，即第一個(gè)獲取鎖的線程，JVM會(huì)為它保留鎖(不需要原子性操作)，從而，在其后，該線程獲取鎖等同于uncontended synchronization的效果。
BEA JRockit R27.5提供的lazyUnlocking技術(shù)據(jù)說(shuō)可以提升鎖性能超過(guò)1倍以上，從而簡(jiǎn)直提高JVM性能達(dá)10%以上。
延遲鎖（或者保留鎖）都是忌諱頻繁的多線程競(jìng)爭(zhēng)鎖的情形，比如，如果一個(gè)Java對(duì)象按照下面的序列被T1,T2,T3線程獲取，則保留鎖的效果是很差的。
T1，T2, T1, T2, T3, T1, T4, T3, T2......
我個(gè)人非常喜歡保留鎖，可能是我有所偏見，事實(shí)上我接觸的公司內(nèi)部的關(guān)于JRockit統(tǒng)計(jì)報(bào)告，都表明：
1，大量的Java應(yīng)用不會(huì)發(fā)生鎖競(jìng)爭(zhēng)
2，Java鎖一般都符合保留鎖的條件，即大部分情況下，在某個(gè)時(shí)間片內(nèi)，都是鎖都是被某個(gè)線程獨(dú)占。