一起养成写作习惯！这是我参与「掘金日新计划 · 4 月更文挑战」的第2天，点击查看活动详情
系列
- 偏向锁理论太抽象，实战了解下偏向锁如何发生以及如何升级【实战篇】
- synchronized大boss终登场，核酸检测就是多线程并发有效的场景
- synchronized已经不在臃肿了，放下对他的成见之初识轻量级锁
前言
- 之前两篇文章我们分别介绍了偏向锁，轻量级锁。在最后轻量级的介绍中我们也透露了后续我们会开发重量级锁相关文章。所谓重量级锁就是全部按照要求来
- 偏向锁和轻量级锁实际上都是默许操作，剩下的靠线程自觉排队和争抢。就像我们现在疫情爆发情况下一样做核酸靠我们自己排队
- 相信大家也清楚自己排队时不可靠的。前阵子网络上就爆出很多检测核算时插队导致的矛盾冲突。这是因为我们基数大还靠我们自觉操作往往会是得其反。所以这个时候就诞生了我们维护秩序的一个角色
- 同样在线程等待中也是同样。当很多线程都在等待资源释放，如果我们不管理的话最终肯定会乱成一锅粥。还记得我们之前提到的AQS吗。他就是管理线程争抢的一种很好的方式。我们这里的重量级锁也可以这样理解。当线程等待资源释放时我们就将线程放到队列里等待管理。
- 到这里相信你也清楚，这里就是串型操作很耗费时间，这也是为什么我们叫做重量级锁的原因。
重量级锁
- 多个线程竞争同一个锁的时候，虚拟机会阻塞加锁失败的线程，并且在目标锁被释放的时候，唤醒这些线程；
- Java 线程的阻塞以及唤醒，都是依靠操作系统来完成的：os pthread_mutex_lock() ；
- 升级为重量级锁时，锁标志的状态值变为“10”，此时Mark Word中存储的是指向重量级锁的指针，此时等待锁的线程都会进入阻塞状态
- 重量级锁markword中存储的指针是C++中objecMonitor对象的指针。该对象结构如下
- 重量级锁和我之前分析的Lock对象的流程一致，都是挂起线程放到队列中等待唤醒。唤醒就涉及到CPU切换的问题，所以称之为重量级锁。
总结预告
- 重量级很不友好，这也是为什么synchronized得不到开发者的认可。但是在jdk8之后随着偏向锁和轻量级锁的加入已经慢慢的得到了改善了。我们应该放下成见接受他。关于synchronized相关的锁的介绍到这里基本上就结束了。但是学习永不止步。后面我们持续介绍如下内容
