面试官让我讲synchronized,老汪用一间厕所给我整明白了
“synchronized这我熟。项目里天天用。”面试官眼皮都没抬。“行。那你先说说synchronized锁的是什么东西”小强嘴角微微上扬。“锁的是对象。每个Java对象都可以作为锁。”“还有吗”“嗯……还能锁类比如synchronized加在静态方法上锁的就是Class对象。”“还有吗”小强愣了一下。“就……就这些吧”面试官把简历翻了一页。“那你讲讲一个线程拿到锁之后JVM内部是怎么记录这个状态的”小强开始有点磕巴。“呃……对象头里有个……mark word会存锁的状态。”“mark word里具体存了什么”“线程ID……还有……分代年龄……”“还有吗”“还有……”小强额头开始冒汗“好像跟偏向锁、轻量级锁有关具体怎么变的我不太确定。”面试官终于抬起头看了他一眼。“那你说说重量级锁底层是怎么实现的”小强感觉后背发凉。“ObjectMonitor……WaitSet……EntryList……”“这些数据结构之间是怎么协作的线程从阻塞到拿到锁经历了哪些状态流转”小强彻底蒙圈了。“这个……平时都是看网上文章没仔细研究过源码。”面试官把简历合上面无表情。“回去等通知吧。”小强从会议室出来感觉脚底下踩的是棉花。楼下长椅上老汪正在眯着眼睛晒太阳。“小强怎么了脸都绿了。”小强一屁股坐在老汪旁边竹筒倒豆子似的把刚才的问题复述了一遍。“老汪你说这面试官是不是故意刁难我synchronized不就是个锁吗会用不就行了”老汪慢悠悠地喝了口保温杯里的枸杞水。“他不是刁难你。他是想看你到底有没有搞懂并发编程的底层逻辑。”“这玩意儿说白了就是个排队上厕所的问题。”小强眼睛瞪大了。“厕所”老汪把保温杯放下比划起来。“你看synchronized锁的对象就好比厕所那扇门。门上的牌子就是mark word。”“没人上厕所的时候牌子显示‘空’。这就是无锁状态。”“一个人进去了牌子翻成‘有人’。这就是偏向锁。为啥叫偏向因为这个厕所现在偏向于刚才进去的那个人。他要是还想上第二次不用重新排队直接推门就进。”小强插嘴“那轻量级锁呢”“别急。这时候来了第二个人也想用这个厕所。他一看牌子占着呢。但他不死心就在门口转悠隔一会儿推一下门试试。这就是自旋。这时候mark word的状态就变成轻量级锁了。”老汪继续比划。“自旋的人多了门口转悠了十几个厕所还是没空。这时候管理员就该出来管事了。”“管理员就是操作系统。他会把门口转悠的人都轰走让他们去大厅等着。这就是重量级锁。大厅里的椅子就是EntryList。谁先来谁坐前面这叫公平排队。”小强若有所思“那WaitSet又是什么”“WaitSet是另一种情况。你上厕所上到一半发现没纸了。你就蹲那儿等着谁叫也不出去必须等有人给你送纸来。这时候你就是wait状态被挪到WaitSet里。送纸的人用完厕所出来喊一声notify你才能从WaitSet挪回EntryList重新排队。”“听懂了吗mark word的状态变化就是牌子上写的字从‘空’到‘有人’到‘请排队’。这个变化过程JVM帮你管了你不用操心。”小强挠挠头。“那我该怎么记清楚这些状态变化啊”老汪从兜里掏出手机翻出一张截图。“回去看HotSpot源码文件名叫synchronizer.cpp。重点看ObjectMonitor这个结构体里面的_owner、_EntryList、_WaitSet这些字段对应我刚才说的管理员、排队队伍、等纸队伍。”“再去看《Java并发编程的艺术》第三章讲锁的内存语义那部分。不是让你背是让你理解为什么要有这几种锁状态——一句话就是小气。能省则省实在不行再找管理员。”小强好奇地问“你刚才说小气是什么意思”老汪笑了笑。“这就是面试官问你这个题的真实意图。他根本不是考你会不会用synchronized。他是想看你对JVM的性能优化有没有概念。”“为什么要有偏向锁因为大部分时候一个锁根本没人抢。你让管理员每次来管太浪费了。JVM是出了名的小气鬼能自己搞定的绝不麻烦操作系统。”“轻量级锁就是小气到极致——哪怕有人在门口等只要等的时间不长也不叫管理员。自旋就是在那儿干等着赌你马上出来。”“实在不行等的人太多了操作系统介入才升级成重量级锁。这叫锁膨胀。”小强追问“那无锁和偏向锁之间呢还有什么批量重偏向、批量撤销”老汪满意地点点头。“这就问到点上了。JVM不光对单个锁小气对整个系统也小气。如果发现一个类的大部分对象都在频繁撤销偏向锁JVM会觉得‘这个类不配用偏向锁’直接给它禁掉。这就是批量撤销。”“你回去做个实验。用JOL工具打印对象头看锁状态变化。启动的时候加个JVM参数-XX:BiasedLockingStartupDelay0把偏向锁延迟关了。你会发现一个刚new出来的对象mark word最后三位是101这就是偏向锁的标记。”小强掏出手机记了下来。“老汪那你遇到过因为没搞懂这个原理导致的生产事故吗”老汪叹了口气。“多了去了。去年有个项目上线之后CPU直接飙到95%。”“查了半天发现有个接口几十个线程同时更新一个ConcurrentHashMap里的值。他们以为ConcurrentHashMap是线程安全的就没事了结果在值上面加了synchronized块。”“问题是这段代码的执行时间特别短可能就十几毫秒。这就导致大量线程都在自旋等锁。自旋是消耗CPU的。几十个线程一起自旋CPU能不飙吗”“解决办法很简单。要么把synchronized去掉用AtomicInteger的CAS操作。要么降低锁的粒度让线程不要扎堆。”小强倒吸一口凉气“这么细节的问题……”老汪站起来拍了拍小强的肩膀。“还有一次线上服务频繁Full GC。查出来有人在一个synchronized方法里对同一个对象反复调wait和notify。每次notify都会把等待线程从WaitSet挪到EntryList然后又要重新竞争锁产生大量短命对象。”“说到底就是你得明白你这个锁在JVM眼里到底干了啥。是偏向锁在那儿舒舒服服待着呢还是已经膨胀成重量级锁了操作系统在那儿忙活。”“面试官问你是不是只停留在表面就是看你有没有意识到这一个小小的synchronized背后是一整套锁升级策略、内存屏障、系统调用。”“回去先啃synchronizer.cpp的源码再看JOL工具的实验数据。搞懂了下次面试你就能反问他您是想听偏向锁撤销的阈值参数呢还是想听ObjectMonitor的底层AQS设计”小强站起来感觉刚才面试的阴霾一扫而空。虽然还是有点犯怵但至少知道路在哪了。“行老汪。我先回去看源码了。”走出两步他又回过头。“那个……synchronizer.cpp大概多少行”老汪眯着眼睛慢悠悠地拧开保温杯。“不多了。也就一万六千行。”小强腿一软差点跪在草坪上。
本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:http://www.coloradmin.cn/o/2580638.html
如若内容造成侵权/违法违规/事实不符,请联系多彩编程网进行投诉反馈,一经查实,立即删除!