Java锁的升级策略 偏向锁 轻量级锁 重量级锁

这三种锁是指锁的状态，并且是专门针对synchronized关键字。jdk 1.6 为了减少"重量级锁"的性能消耗，引入了“偏向锁”和“轻量级锁”，锁一共拥有4种状态：无锁状态、偏向锁、轻量级锁、重量级锁。锁状态是通过对象头的mark word来进行标记的：

锁可以升级但不能降级，意味着偏向锁升级成轻量级锁后不能降级成偏向锁，这种锁升级却不能降级的策略，是为了提高获得锁和释放锁的效率

1. 重量级锁：依赖于底层操作系统的mutex lock，线程会被阻塞住
   • 缺点：加锁和解锁需要从用户态切换到内核态，性能消耗较大
2. 轻量级锁：基于重量级锁进行了优化(避免上下文切换，提高了性能)，它假设多线程竞争是互相错开的，不会发生线程阻塞，呢么上下文切换就是多余的
   • 第一个特点：采用了cas操作加锁和解锁，由于轻量级锁的锁记录(lock record)是存放在对象头和线程空间里的，因此加锁和解锁不需要上下文切换，性能消耗较小
   • 第二个特点：一旦发生多线程竞争，首先基于“自旋锁”思想，自旋cpu循环等待一段时间，不会发生上下文切换，如果还是无法获得锁，就将锁升级为重量级锁
3. 偏向锁：基于轻量级锁进行了优化(减少多次的加锁和解锁，提高了性能)，它假设整个过程只有一个线程获得锁，呢么多次的加锁和解锁就是多余的
   • 特点：在第一次获得锁之后不会释放锁，它会一直持有锁，后续进入锁时只需检查一下锁状态和偏向线程id是否为自己，从而省去了多次的加锁和解锁

1.偏向锁

获取锁：

1. 检测对象头的mark word是否为可偏向状态(即是否为偏向锁1，锁标志位是否为01)，如果不是，尝试竞争锁：尝试cas操作将mark word的线程id设置为当前线程id，以表示线程获得锁，如果失败说明锁已被占用
2. 若为可偏向状态，则检查线程id是否为当前线程id，如果是则表示当前线程已经持有锁(锁的可重入)，否则说明锁已被占用
3. 如果锁已被占用，只能撤销偏向锁为无锁状态或轻量级锁

释放锁：（偏向锁使用了一种等到竞争出现才释放锁的机制，线程是不会主动释放偏向锁的，只有当其他线程竞争偏向锁时，持有偏向锁的线程才会释放锁）

1. 偏向锁的撤销需要等待全局安全点(在这个时间点没有正在执行的字节码)，暂停拥有偏向锁的线程，检查持有偏向锁的线程是否还活着
2. 如果线程挂了，则将对象头设置成无锁状态；如果线程仍然活着，则将对象头设置为轻量级锁(锁的升级)，最终轻量级锁一定会被释放

2.轻量级锁

获取锁：

1. 检测对象头的mark word是否为轻量级锁(锁标志位为00)，如果不是，尝试竞争锁：jvm首先在当前线程的栈帧中建立一个锁记录(lock record)，用于备份存储对象头的mark word(官方把这份拷贝加了一个displaced前缀，称为displaced mark word)，然后jvm尝试cas操作将mark word更新为指向lock record的指针，以表示线程获得锁，如果失败说明锁已被占用
2. 若为轻量级锁，判断对象头的mark word是否指向当前线程的栈帧的lock record，如果是则表示当前线程已经持有锁(锁的可重入)，否则说明锁已被占用
3. 如果锁已被占用，当前线程便尝试自旋cpu来获取锁，自旋一定次数后轻量级锁会膨胀为重量级锁(锁标志位变成10)，线程进入阻塞

释放锁：

1. 尝试cas操作将displaced mark word中替换回对象头，如果成功，说明轻量级锁释放成功
2. 如果cas操作失败，说明存在锁竞争，锁已经膨胀成重量级锁，需要在释放锁的同时唤醒那些被挂起的线程

3.重量级锁

重量级锁依赖于底层操作系统的mutex lock，所有线程都会被阻塞住，线程之间的切换需要从用户态到内核态，切换成本非常高。

总结：锁的优缺点对比

锁	优点	缺点	适用场景
偏向锁(biased lock)	加锁和解锁不需要额外的消耗，和执行非同步方法相比仅存在纳秒级的差距	如果线程间存在锁竞争，会带来额外的锁撤销	适用于只有一个线程访问
轻量级锁(lightweight lock)	竞争的线程不会阻塞，提高了程序的响应速度	对于得不到锁的线程，自旋会消耗cpu	追求响应时间，或者要求临界区简短，自旋不会占用cpu过久
重量级锁(heavyweight lock)	线程竞争不使用自旋，不会消耗cpu资源	线程阻塞，响应时间缓慢	追求吞吐量