面试官：听说你精通多线程，那我就考考你吧
面试官：不用慌尽管说，错了也没关系😊。。。
以贴近现实的【面试官面试】形式来分享技术，本期是《多线程系列》，感兴趣就关注我吧❤️
面试官：知道可重入锁有哪些吗
嗯嗯知道的。
我了解的主要有ReentrantLock、sychronized都是可重入锁。
面试官：你先说说synchronized的实现原理
好的，synchronized的实现是基于monitor的。
是这样，任何对象都有一个monitor与之关联，当monitor被持有后，对象就会处于锁定状态。
而在同步代码块的开始位置，在编译期间会被插入monitor’enter指令。
当线程执行到monitorenter指令时，就会尝试获取monitor的所有权，获取得到则获得锁资源。
面试官思考中…
面试官：那synchronized有什么缺点
缺点是资源消耗是比较大，因为它是属于重量级锁。
-
synchronized需要频繁的获得锁、释放锁，这会带来了不少性能消耗。
-
另外没有获得锁的线程会被操作系统进行挂起阻塞、唤醒。
而唤醒操作需要保存当前线程状态，切换到下一个线程，也就是进行上下文切换。
上下文切换是很耗费资源的一种操作。
面试官思考中…
面试官：为什么上下文切换要保存当前线程状态？
emmm就跟读英文课文时查字典一样，我们要先记住课文里的页数，查完字典好回到英文课文。
而CPU需要保存当前线程的状态，来保证可以切换到上一个线程的状态。
面试官：可以怎么解决synchronized资源消耗吗
哦哦，JDK在这方面是引入了偏向锁、轻量级锁、重量级锁，也就是锁升级。
多线程环境其实有各种不同的场景，这三种锁就是为了适应各种不同场景，来使并发的效率最高。
-
只有一个线程访问同步代码块的场景的话，会进入偏向锁状态。
偏向锁会偏向访问它的线程，使其加锁、解锁不需要额外的消耗。
-
有少量线程竞争的场景的话，偏向锁会升级为轻量级锁。
而轻量级使用CAS操作来获得锁，CAS操作不需要获得锁、释放锁，减少了像synchronized带来的上下文切换资源消耗
面试官思考中…
面试官：那轻量级锁没有缺点吗
有的，没有获得锁的线程会自旋，这需要消耗CPU的。
另外如果自旋10次失败的话，为了减少CPU的消耗，轻量级锁会升级为重量级锁，也就是回到了类似synchronized重量级锁的同步场景。
面试官抓抓脑袋，继续看你的简历…
得想想考点你不懂的😰
未完待续。。。。。。
好了，今天的分享就先到这，我们下期【多线程系列】继续。
创作不易，不妨点赞、收藏、关注支持一下，各位的支持就是我创作的最大动力❤️
