作者回复: 多谢建议!
本文的讲解流程是从通用锁算法到针对特殊情况的锁算法来的。一开始monitorenter是用重型锁的,然后为了针对没有竞争锁的情况有了轻型锁,再然后为了针对只有一个线程持有某个锁的情况有了偏向锁。
作者回复: 不好意思哈,因为网上有很多图,忘了放个链接了。
你可以参考wiki.openjdk.java.net/display/HotSpot/Synchronization中的图。
作者回复: 对的!赞
作者回复: 哈,这个属于应用程序的问题,JVM只是观察到这种情况,并尝试做出优化。
有一种可能,就是很长一段时间内,只有一个线程频繁加锁,后面换成另外的线程,这样前面那段时间可以用偏向锁。
作者回复: 自旋本质是空转cpu等待,只有在别人拿着锁,自己请求锁的情况下发生。偏向锁无需此步骤,栈锁别人没有持有锁,也不需要自旋
作者回复: 1. 单向不可逆 针对一个对象的整个生命周期。
epoch+1发生在多次同一类型的实例的偏向锁撤销之后,存放在类型(Class)那里的。
2. 当频繁检测到某个类的实例出现撤销偏向锁的,就代表这个类不适合用来搞偏向锁。
作者回复: 默认情况下是的。以前有个延缓毫秒数-XX:BiasedLockingStartupDelay,一开始用轻量级锁,在启动四秒之后才开始用偏向锁。我记得Java 9还是10默认值改为0了。
作者回复: 这个说法有点歧义。
按我的理解,你应该在问是否为当前线程获得这把锁?那么答案是对的,一直是当前线程获得这把锁。
另外,锁是加在目标锁对象上的。
作者回复: 没有,方法有ACC_SYNCHRONIZED标志符