JVM对Java的原生锁做了哪些优化?在Java之前，Monitor的实现完全依赖底层操作系统的互斥锁来实现，也就是我们刚才在问题二中所闻述的获取/释放锁的逻辑。
由于Java层面的线程与操作系统的原生线程有映射关系，如果要将一个线程进行阻塞或唤起都需要操作系统的协助，这就需要从用户态切换到内核态来执行，这种切换代价十分昂贵，很耗处理器时间，现代JDK中做了大量的优化。一种优化是使用自旋锁，即在把线程进行阻塞操作之前先让线程自旋等待一段时间，可能在等待期间其他线程已经解锁，这时就无再让线程执行阻塞操作，避免了用户态到内核态的切换。
再让线程执行阻塞操作，避免了用户态到内核态的切换。
现代JDK中还提供了三种不同的 Monitor实现，也就是三种不同的锁：
·偏向锁( Biased Locking)
·轻量级锁
·重量级锁
这三种锁使得JDK得以优化Synchronized的运行，当JM检测到不同的竞争状况时，会自动切换到适合的锁实现，这就是锁的升级、降级。
·当没有竞争出现时，默认会使用偏向锁。
JVM会利用CAS操作，在对象头上的Mark Word部分设置线程ID，以表示这个对象偏向于当前线程，所以并不涉及真正的互斥锁，因为在很多应用场景中，大部分对象生命周期中最多会被一个线程锁定，使用偏斜锁可以降低无竞争开销。
·如果有另一线程试图锁定某个被偏斜过的对象，JM就撤销偏斜锁，切换到轻量级锁实现。
·轻量级锁依赖CAS操作Mark Word来试图获取锁，如果重试成功，就使用普通的轻量级锁;否则，进一步升级为重量级锁。
网友评论