如果一个对象有多个线程访问,但是多线程访问的时间是错开的(没有竞争),那么可以使用轻量级锁来优化。
synchronized (this){ //todo }
当执行同步代码块时,会创建锁记录对象,每个线程的栈帧中包含一个锁记录的结构,
锁记录中Object reference指向锁对象,并尝试用cas替换Object的mark word,将mark word的值存入所记录。
1、加锁
(1)如果cas成功,对象头中存储了锁记录地址和状态00,表示由该线程给对象加锁。
(2)cas失败
i)如果其他线程已经持有了该Object的轻量级锁,表明出现竞争,进入锁膨胀。
ii)如果是自己执行锁重入,那么再添加一条锁记录作为重入的计数
2、解锁
(1)当退出同步代码块时,如果有锁记录的值为null,则表明出现了重入,这时重置锁记录
(2)当退出同步代码块时,如果锁记录的值不为null,这时使用cas将mark word的值恢复给对象头。
cas成功,则解锁成功,cas失败,说明轻量级锁进行了锁膨胀或者升级为重量级锁,此时需要进入重量级锁解锁过程。
当thread-1进行轻量级加锁,但是Thread-0已经对该对象加了轻量级锁。
Thread-1加轻量级锁失败,进入锁膨胀流程
(1)为锁对象申请重量级(Monitor)锁,让对象指向重量级锁。
(2)Thread-1自己进入Monitor的EntryList 阻塞队列中。
注意:
Thread-0在退出同步代码块时,使用cas将mark word的值恢复给对象头失败了,这时会进入重量级解锁流程,即找到Monitor对象,设置Monitor对象的Owner为null,唤醒EntryList中的阻塞线程。
重量级锁在竞争中的时候,还可以使用自旋来进行优化,如果当前线程自旋成功,此时当前线程避免进入阻塞。
在jdk6之前,自旋是自适应的,比如,对象刚刚有过一次自旋操作成功过,那么认为这次自旋成功的可能性会高,就会多自旋几次,反之会少自旋几次。
轻量级锁在无竞争时,每次都需要cas操作,jdk6引入了偏向锁来做进一步的优化
第一次使用cas将线程id设置到对象头的mark word头上,之后在加锁发现这个线程id是自己的,则认为没有竞争,不使用cas。
一个对象创建时,偏向锁是默认开启的,对象的mark word的后3位为101,这时thread,epoch,age都为0
偏向锁默认是延迟的,不会在程序启动时立即生效,如果避免延迟可以加jvm参数:-XX:BiasedLockingStartupDelay=0来禁用延迟。
如果没有开启偏向锁,那么对象创建后,markword的值的最后3位001,hashcode,age都为0,第一次使用hashcode时才会赋值。
偏向锁的撤销
(1)调用锁对象的hashcode,会禁用偏向锁,原因是hashcode占用31位,在偏向状态下无法存入,只能撤销偏向状态。
轻量级锁下,调用hashcode不会导致轻量级状态失效,因为hashcode保存在栈帧的所记录里,等到解锁时会再次赋值到marword里。
同理重量级锁调用hashcode,也不会导致重量级状态失效,因为hashcode保存在monitor的对象里,解锁后,会被重置到锁对象的mark word里。
(2)当有其他线程使用偏向锁对象时,会将偏向锁对象状态撤销,同时锁升级为轻量级锁。
(3)调用wait和notify会导致偏向锁失效,同时锁升级为重量级锁,因为wait和notify只有重量级锁有。
如果对象虽然被多个线程访问,但是没有竞争,这时偏向对象的线程id有机会重新偏向给线程id2,jvm对这种线程之间偏向锁的撤销做了优化,即当偏向锁阈值超过20次后,jvm会将这些偏向锁对象的线程id重新赋值为当前线程id。
当撤销偏向锁阈值超过40次后,jvm会禁用偏向锁,即会出现所膨胀。