【多线程系列】你先说说synchronized的实现原理

时间:2024-03-29 21:47:07

在这里插入图片描述

面试官:听说你精通多线程,那我就考考你吧


面试官:不用慌尽管说,错了也没关系????。。。


以贴近现实的【面试官面试】形式来分享技术,本期是《多线程系列》,感兴趣就关注我吧❤️

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

嗯嗯知道的。

我了解的主要有ReentrantLock、sychronized都是可重入锁。

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

好的,synchronized的实现是基于monitor的。

是这样,任何对象都有一个monitor与之关联,当monitor被持有后,对象就会处于锁定状态

而在同步代码块的开始位置,在编译期间会被插入monitor’enter指令

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


面试官思考中…


面试官:那synchronized有什么缺点

缺点是资源消耗是比较大,因为它是属于重量级锁

  1. synchronized需要频繁的获得锁、释放锁,这会带来了不少性能消耗。

  2. 另外没有获得锁的线程会被操作系统进行挂起阻塞、唤醒。

    唤醒操作需要保存当前线程状态,切换到下一个线程,也就是进行上下文切换

    上下文切换是很耗费资源的一种操作。


面试官思考中…


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

emmm就跟读英文课文时查字典一样,我们要先记住课文里的页数,查完字典好回到英文课文。

而CPU需要保存当前线程的状态,来保证可以切换到上一个线程的状态。

在这里插入图片描述

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

哦哦,JDK在这方面是引入了偏向锁、轻量级锁、重量级锁,也就是锁升级

多线程环境其实有各种不同的场景,这三种锁就是为了适应各种不同场景,来使并发的效率最高。

  1. 只有一个线程访问同步代码块的场景的话,会进入偏向锁状态。

    偏向锁会偏向访问它的线程,使其加锁、解锁不需要额外的消耗。

  2. 少量线程竞争的场景的话,偏向锁会升级为轻量级锁

    而轻量级使用CAS操作来获得锁,CAS操作不需要获得锁、释放锁,减少了像synchronized带来的上下文切换资源消耗


面试官思考中…


面试官:那轻量级锁没有缺点吗

有的,没有获得锁的线程会自旋,这需要消耗CPU的。

另外如果自旋10次失败的话,为了减少CPU的消耗,轻量级锁会升级为重量级锁,也就是回到了类似synchronized重量级锁的同步场景。

面试官抓抓脑袋,继续看你的简历…


得想想考点你不懂的????

未完待续。。。。。。

好了,今天的分享就先到这,我们下期【多线程系列】继续。

创作不易,不妨点赞、收藏、关注支持一下,各位的支持就是我创作的最大动力❤️