David.Turing's blog

 

关于Lazy-UnLocking(Reservation Lock)对Java锁的性能优化

JRockit使用了一种Lazy-Locking(也叫做Reservation Lock)的技术
 -XXlazyUnlocking
我当初是在一个日本IBM实验室的一篇2004年的博士论文上看到的概念,保留锁提出的背景是针对Java Synchronized时候,某个Java对象被1+个线程Aquired Lock的序列通常是某个线程占多的现象,后来发现这是一个普遍现象,可能几乎超过75%的锁争夺都是发生在某个线程上(包括递归锁),从锁获取的序列上看,大部分可能是:
T1 T1 T1 T1 T1 T1 T1 T1 T3 T1 T1 T1 T1 T2 T2 T1 T1 T1 T1
(T1, T2, T3是尝试获取Java Lock)
也就是,针对这种锁现象,JVM设计人员开始采用Lazy-UnLocking的想法,即通过改变锁设计,允许T1获得锁的时候,不需要CAS(Compare and Swap)原子性操作,这也是Lock Reservation(保留给T1)的由来;
而T3需要获取当前Java锁的时候,需要一个代价较为昂贵Cancel T1 Reservation的动作才能获得锁。

Java线程如果没有频繁Contention发生的时候,锁延迟意味着不需要原子性操作便获得对象,大大降低Java Lock在OS上的开销。

Sun也有类似的技术,其实是在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技术据说可以提升锁性能超过1倍以上,从而简直提高JVM性能达10%以上。
延迟锁(或者保留锁)都是忌讳频繁的多线程竞争锁的情形,比如,如果一个Java对象按照下面的序列被T1,T2,T3线程获取,则保留锁的效果是很差的。
T1,T2, T1, T2, T3, T1, T4, T3, T2......

我个人非常喜欢保留锁,可能是我有所偏见,事实上我接触的公司内部的关于JRockit统计报告,都表明:
1,大量的Java应用不会发生锁竞争
2,Java锁一般都符合保留锁的条件,即大部分情况下,在某个时间片内,都是锁都是被某个线程独占。

posted on 2009-02-12 14:40 david.turing 阅读(4297) 评论(0)  编辑  收藏


只有注册用户登录后才能发表评论。


网站导航:
 

导航

统计

公告


常用链接

留言簿(107)

我参与的团队

随笔分类(126)

随笔档案(155)

文章分类(9)

文章档案(19)

相册

搜索

积分与排名

最新随笔

最新评论

阅读排行榜

评论排行榜