为什么监视器(object monitor)锁需要可重入呢? 这好像是一个默认的事实, 笔者以前也没有思考过.前段时间被问到这个问题,细细思索了一番,又翻阅一些文章.得出一个可能比较片面的结论: Java的OOP特性需要监视器锁是可重入的.所以监视器锁是可重入的.
下面举两个例子说明
前提知识
监视器锁的加解锁逻辑
监视器锁是对对象(实例对象,类对象)加锁
进入synchronized方法前,对此方法对应对象的监视器加锁,
退出(正常/异常)synchronized方法时,对此方法对应对象的监视器解锁
synchronize方法内部调用相同对象的另外一个synchronize方法
Son对象的doSomething() 方法内部调用了它的doAnotherThing()方法. 如果监视器锁不是可重入的,doSomething已经获取了监视器锁,并且还没有释放,doAnotherThing无法获取到监视器锁,这里就会死锁
public class Son extends Father {
@Override
public synchronized void doSomething() {
doAnotherThing();
}
public synchronized void doAnotherThing() {
//...
}
}
synchronize方法内部调用父类的synchronize方法
Son对象的doSomething() 方法内部调用了父类的同名方法,如果监视器锁不是可重入的,原因同上,这里也会死锁
@Override
public synchronized void doSomething() {
super.doSomething();
}
}
可重入的监视器锁
如果监视器锁不可重入,OOP特性就会被破坏,因此监视器锁是可重入的
监视器锁的可重入采用计数方法(概念层次)
每次加锁计数+1
每次解锁计数-1
计数为0表示无锁
再举个例子,上面两个例子的合体版
public class Son extends Father {
@Override
public synchronized void doSomething() {
doAnotherThing();
}
public synchronized void doAnotherThing() {
super.doSomething();
}
}
看一下线程堆栈,可以看到三次都对0x0000000787ae5490加锁,由于监视器锁可重入,因此不会出现问题
"main" #1 prio=5 os_prio=31 cpu=273.56ms elapsed=27.77s tid=0x00007fd46500d000 nid=0x2803 waiting on condition [0x000070000bdd0000]
java.lang.Thread.State: TIMED_WAITING (sleeping)
at java.lang.Thread.sleep(java.base@13.0.1/Native Method)
at com.github.alonwang.concurrent.Father.doSomething(Father.java:9)
- locked <0x0000000787ae5490> (a com.github.alonwang.concurrent.Son)
at com.github.alonwang.concurrent.Son.doAnotherThing(Son.java:13)
- locked <0x0000000787ae5490> (a com.github.alonwang.concurrent.Son)
at com.github.alonwang.concurrent.Son.doSomething(Son.java:10)
- locked <0x0000000787ae5490> (a com.github.alonwang.concurrent.Son)
at com.github.alonwang.concurrent.SynchronizeDemo.main(SynchronizeDemo.java:10)
总结
片面的说,OOP需要监视器锁是可重入的.
