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