Synchronized 问题求助
Synchronized的锁升级过程分为 偏向锁，轻量级，重量级
偏向锁是进行cas threadid
轻量级锁在线程栈之中创建一个lock Record 然后进行cas
问题：
轻量级锁在线程栈创建lockRecord的作用是什么？不创建行不行（网上见到有的说法是 需要维护到底有哪些线程竞争过这个锁，等重量级锁释放时进行唤醒，但是在没有锁升级的时候Synchronizd是怎么做的？而且重量级锁的对象头重不是通过entryList和waitSet已经维护了么）？
轻量级锁和偏向锁都是基于cas来判断冲突的，是否可以使用偏向锁代替轻量级锁？或者来说轻量级锁一定要存在的价值是什么？
回答：
首先帮你理清两者的关系：偏向锁是对轻量锁的补充，轻量锁才是主角。而到现在，偏向锁的设计已经过时了，将会被取消。
其次是纠正对偏向锁的理解。上面有段话描述了偏向锁设计的目的：
It aims to avoid executing a compare-and-swap atomic operation when acquiring a monitor by assuming that a monitor remains owned by a given thread until a different thread tries to acquire it.
也就是说偏向锁相对于轻量锁而言是没有CAS过程的，为什么，因为获取锁的线程和已经持有锁的线程就是同一个啊。
最后是关于“轻量锁的价值”：它其实是对重量锁的补充。轻量锁和重量锁的区别是什么？是后者调用了操作系统指令，而前者没有。调用操作系统指令开销是很大的，所以如果可以不调用，那么就属于使用轻量锁的场景，否则就是重量锁。
总结起来就是，当线程“我”去获取一个锁时，会有三个级别的场景：
- 我已经持有该锁：使用偏向锁；
- 我没有持有该锁，但也没有其他线程持有该锁：使用轻量锁；
- 我没有持有该锁，同时有其他线程持有或尝试获得该锁：升级到重量锁。
所以对锁的理解，应该先理解总体上的场景区分，再去理解每个场景中使用了哪些数据结构，这些数据结构是如何将不同场景串起来的。关于这些细节，推荐看看这篇文章。
以上是 Synchronized 问题求助 的全部内容， 来源链接： utcz.com/p/944137.html
