synchronized优化原理
轻量级锁
如果一个对象有多个线程访问,但多线程访问的时间是错开的(没有竞争),可以用轻量级锁优化
@Slf4j(topic = "c.ExerciseTransfer")
public class Test {
static final Object obj = new Object();
public static void main(String[] args) throws InterruptedException {
synchronized (obj){
method();
}
}
public static void method(){
synchronized (obj){
}
}
}
让锁记录中 Object reference 指向锁对象,并尝试用 cas 替换 Object 的 Mark Word,将 Mark Word 的值存 入锁记录
如果 cas 替换成功,对象头中存储了 锁记录地址和状态 00 ,表示由该线程给对象加锁,这时图示如下。
如果 cas 失败,有两种情况
-
如果是其它线程已经持有了该 Object 的轻量级锁,这时表明有竞争,进入锁膨胀过程
-
如果是自己执行了 synchronized 锁重入,那么再添加一条 Lock Record 作为重入的计数
当退出 synchronized 代码块(解锁时)如果有取值为 null 的锁记录,表示有重入,这时重置锁记录,表示重入计数减一。
当退出 synchronized 代码块(解锁时)锁记录的值不为 null,这时使用 cas 将 Mark Word 的值恢复给对象头
-
成功,则解锁成功
-
失败,说明轻量级锁进行了锁膨胀或已经升级为重量级锁,进入重量级锁解锁流程
锁膨胀
如果在尝试加轻量级锁的过程中,CAS 操作无法成功,这时一种情况就是有其它线程为此对象加上了轻量级锁(有 竞争),这时需要进行锁膨胀,将轻量级锁变为重量级锁。
这时 Thread-1 加轻量级锁失败,进入锁膨胀流程
-
即为 Object 对象申请 Monitor 锁,让 Object 指向重量级锁地址
-
然后自己进入 Monitor 的 EntryList BLOCKED
当 Thread-0 退出同步块解锁时,使用 cas 将 Mark Word 的值恢复给对象头,失败。这时会进入重量级解锁 流程,即按照 Monitor 地址找到 Monitor 对象,设置 Owner 为 null,唤醒 EntryList 中 BLOCKED 线程。
自旋优化
重量级锁竞争的时候,还可以使用自旋来进行优化,如果当前线程自旋成功(即这时候持锁线程已经退出了同步块,释放了锁),这时当前线程就可以避免阻塞。
偏向锁
轻量级锁在没有竞争时(就自己这个线程),每次重入仍然需要执行 CAS 操作。
Java 6 中引入了偏向锁来做进一步优化:只有第一次使用 CAS 将线程 ID 设置到对象的 Mark Word 头,之后发现这个线程 ID 是自己的就表示没有竞争,不用重新 CAS。以后只要不发生竞争,这个对象就归该线程所有。例如:
static final Object obj = new Object();
public static void m1() {
synchronized( obj ) {
// 同步块 A
m2();
}
}
public static void m2() {
synchronized( obj ) {
// 同步块 B
m3();
}
}
public static void m3() {
synchronized( obj ) {
// 同步块 C
}
}
偏向状态
之所以要用偏向锁是因为轻量级锁的锁重入每次都调用CAS进行对比,CAS是一个OS指令操作,速度很慢。所以偏向锁是把ThreadId直接赋值给markword,那么下次能直接在java上对比这个markword。
-
偏向锁带有延迟性,通常对象创建过一会才会生成
-
先生成偏向锁->轻量级锁->重量级锁
-
如果给临时区使用偏向锁,那么对应执行线程的id赋值给markword
-
如果使用了锁的hashcode,那么偏向锁就会被禁止,因为hashcode占用的bit太多。
-
轻量级在锁记录上记录hashcode,重量级在monitor上记录
-
如果两个线程用同一个偏向级锁,那么锁会变成不可偏向,升级为轻量级锁。