【面试官】知道synchronized锁升级吗

在这里插入图片描述

一座绵延在水上的美术馆——白鹭湾巧克力美术馆。它漂浮于绿水之上，宛如一条丝带轻盈地伸向远方

可重入锁
synchronized实现原理
synchronized缺点
保存线程状态
锁升级
锁升级优缺点

面试官：知道可重入锁有哪些吗?

可重入意味着获取锁的粒度是线程而不是调用，如果大家知道这个概念，会更容易理解可重入锁的作用。

既然获取锁的粒度是线程，意味着线程自己是可以获取自己的内部锁的，而如果获取锁的粒度是调用则每次经过同步代码块都需要重新获取锁。

举个例子。线程A获取了某个对象锁，但在线程代码的流程中仍需再次获取该对象锁，此时线程A可以继续执行不需要重新再获取该对象锁。另外线程如果要使用父类的同步方法，由于可重入锁也无需再次获取锁。

在Java中，可重入锁主要有ReentrantLock、synchronized。

面试官：你先说说synchronized的实现原理?

synchronized的实现是基于monitor的。任何对象都有一个monitor与之关联，当monitor被持有后，对象就会处于锁定状态。而在同步代码块的开始位置，在编译期间会被插入monitorenter指令。

当线程执行到monitorenter指令时，就会尝试获取monitor的所有权，如果获取得到则代表获得锁资源。

面试官：那synchronized有什么缺点？

在Java SE 1.6还没有对synchronized进行了各种优化前，很多人都会称synchronized为重量级锁，因为它对资源消耗是比较大的。

synchronized需要频繁的获得锁、释放锁，这会带来了不少性能消耗。
另外没有获得锁的线程会被操作系统进行挂起阻塞、唤醒。而唤醒操作需要保存当前线程状态，切换到下一个线程，也就是进行上下文切换。上下文切换是很耗费资源的一种操作。

面试官：为什么上下文切换要保存当前线程状态？

这就跟读英文课文时查字典一样，我们要先记住课文里的页数，查完字典好根据页数翻到英文课文原来的位置。

同理，CPU要保证可以切换到上一个线程的状态，就需要保存当前线程的状态。

面试官：可以怎么解决synchronized资源消耗吗？

上文我有提到Java SE 1.6对synchronized进行了各种优化，具体的实现是给synchronized引入了锁升级的概念。synchronized锁一共有四种状态，级别从低到高依次是无锁、偏向锁、轻量级锁、重量级锁。

大家思考下，其实多线程环境有着各种不同的场景，同一个锁状态并不能够适应所有的业务场景。而这四种锁状态就是为了适应各种不同场景来使得线程并发的效率最高。

没有任何线程访问同步代码块，此时synchronized是无锁状态。
只有一个线程访问同步代码块的场景的话，会进入偏向锁状态。偏向锁顾名思义会偏向访问它的线程，使其加锁、解锁不需要额外的消耗。
有少量线程竞争的场景的话，偏向锁会升级为轻量级锁。而轻量级采用CAS操作来获得锁，CAS操作不需要获得锁、释放锁，减少了像synchronized重量级锁带来的上下文切换资源消耗。
轻量级锁通过CAS自旋来获得锁，如果自旋10次失败，为了减少CPU的消耗则锁会膨胀为重量级锁。此时synchronized重量级锁就回归到了悲观锁的状态，其他获取不到锁的都会进入阻塞状态。

面试官：它们都有什么优缺点呢？

由于每个锁状态都有其不同的优缺点，也意味着有其不同的适应场景。

偏向锁的优点是加锁和解锁操作不需要额外的消耗；缺点是如果线程之间存在锁竞争，偏向锁会撤销，这也带来额外的撤销消耗；所以偏向锁适用的是只有一个线程的业务场景。
轻量级锁状态下，优点是线程不会阻塞，提高了程序执行效率；但如果始终获取不到锁的线程会进行自旋，而自旋动作是需要消耗CPU的；所以轻量级锁适用的是追求响应时间、同时同步代码块执行速度快的业务场景。
重量级锁的优点是不需要自旋消耗CPU；但缺点很明显，线程会阻塞、响应时间也慢；重量级锁更适用在同步代码块执行速度较长的业务场景。

本文收录在我开源的《Java学习面试指南》中，一份覆盖Java程序员所需掌握的Java核心知识、面试重点。希望收到大家的 ⭐ Star ⭐支持。GitHub地址：https://github.com/hdgaadd/JavaGetOffer，相信你看了一定不会后悔。