JVM对Java的原生锁做了哪些优化?在Java之前，Monitor的实现完全依赖底层操作系统的互斥锁来实现，也就是我们刚才在问题二中所闻述的获取/释放锁的逻辑。
由于Java层面的线程与操作系统的原生线程有映射关系，如果要将一个线程进行阻塞或唤起都需要操作系统的协助，这就需要从用户态切换到内核态来执行，这种切换代价十分昂贵，很耗处理器时间，现代JDK中做了大量的优化。一种优化是使用自旋锁，即在把线程进行阻塞操作之前先让线程自旋等待一段时间，可能在等待期间其他线程已经解锁，这时就无再让线程执行阻塞操作，避免了用户态到内核态的切换。
再让线程执行阻塞操作，避免了用户态到内核态的切换。
现代JDK中还提供了三种不同的 Monitor实现，也就是三种不同的锁：
偏向锁( Biased Locking)
轻量级锁
重量级锁
这三种锁使得JDK得以优化Synchronized的运行，当JM检测到不同的竞争状况时，会自动切换到适合的锁实现，这就是锁的升级、降级。
当没有竞争出现时，默认会使用偏向锁。
JVM会利用CAS操作，在对象头上的Mark Word部分设置线程ID，以表示这个对象偏向于当前线程，所以并不涉及真正的互斥锁，因为在很多应用场景中，大部分对象生命周期中最多会被一个线程锁定，使用偏斜锁可以降低无竞争开销。
如果有另一线程试图锁定某个被偏斜过的对象，JM就撤销偏斜锁，切换到轻量级锁实现。
轻量级锁依赖CAS操作Mark Word来试图获取锁，如果重试成功，就使用普通的轻量级锁;否则，进一步升级为重量级锁。
【免责声明：本文图片及文字信息均由千锋重庆Java培训小编转载自网络，旨在分享提供阅读，版权归原作者所有，如有侵权请联系我们进行删除。】
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 [email protected] 举报，一经查实，本站将立刻删除。
