synchronized 关键字背后的锁升级流程

---

前言

博主个人社区：开发与算法学习社区

博主个人主页：Killing Vibe的博客

欢迎大家加入，一起交流学习~~

一、基本特点

结合多线程锁的策略, 我们就可以总结出, Synchronized 具有以下特性(只考虑 JDK 1.8):

1. 开始时是乐观锁, 如果锁冲突频繁, 就转换为悲观锁.
2. 开始是轻量级锁实现, 如果锁被持有的时间较长, 就转换成重量级锁.
3. 实现轻量级锁的时候大概率用到的自旋锁策略
4. 是一种不公平锁
5. 是一种可重入锁
6. 不是读写锁

JVM为Java程序员操碎了心，看起来都用的synchronized关键字，背后到底是啥锁，JVM来进行处理，会根据竞争的激烈程度动态选择锁的实现。

二、加锁过程

图解如下：

(1) 无锁

没有任何线程进入同步方法，此时对象就是无锁状态，没有任何线程尝试获取该锁

synchronized void increase(){val++;}
1

(2) 偏向锁

当有第一个线程（t1）尝试获取该锁时，JVM分配偏向锁给该线程（t1），当这个线程t1再次获取锁时（重入或者是再次执行），没有加锁和解锁过程，就验证一下锁的持有线程是否为t1，若是直接放行。

偏向锁不是真的加锁, 而只是在锁的对象头中记录一个标记(记录该锁所属的线程). 如果没有其他线程参与竞争锁, 那么就不会真正执行加锁操作, 从而降低程序开销. 一旦真的涉及到其他的线程竞争, 再取消偏向锁状态, 进入轻量级锁状态.

偏向锁本质上相当于 “延迟加锁” . 能不加锁就不加锁, 尽量来避免不必要的加锁开销.
但是该做的标记还是得做的, 否则无法区分何时需要真正加锁

(3) 轻量级锁

当有第二个线程 （t2） 在 t1 执行之后尝试获取锁，JVM就会取消偏向锁的状态，将锁升级为轻量级锁。

使用CAS（自旋锁）来进行轻量级锁的获取，有加锁和解锁的过程，就是通过自旋来进行的。

t2线程尝试通过自旋的方式来获取轻量级锁

还有其他线程t3 ， t4 在t2 还没结束的时候尝试获取锁，都在自旋等待t2执行结束。

自旋操作是一直让 CPU 空转, 比较浪费 CPU 资源.
因此此处的自旋不会一直持续进行, 而是达到一定的时间/重试次数, 就不再自旋了.
也就是所谓的 "自适应

(4) 重量级锁

当竞争非常激烈，多个线程同时在竞争轻量级锁（一般来说就是当前线程数为CPU核数一半），就会将轻量级锁膨胀为重量级锁 或者 自旋次数超过10次（默认值）以上，就会将轻量级锁膨胀为重量级锁（竞争比较激烈，为了避免CPU空跑，就将线程阻塞）

具体如下：

• 执行加锁操作, 先进入内核态.
• 在内核态判定当前锁是否已经被占用
• 如果该锁没有占用, 则加锁成功, 并切换回用户态.
• 如果该锁被占用, 则加锁失败. 此时线程进入锁的等待队列, 挂起. 等待被操作系统唤醒.
• 经历了一系列的沧海桑田, 这个锁被其他线程释放了, 操作系统也想起了这个挂起的线程, 于是唤醒这个线程, 尝试重新获取锁.

拓展：

1. 重量级锁依赖操作系统提供的mutex来实现（用户态切换到内核态），开销比较大
2. 只要程序中调用了Object.wait()方法，直接会将锁膨胀为重量级锁，无论当前竞争激烈与否，wait方法实际上需要对象monitor实现。

总结

编译器+JVM 还在背后做了很多策略优化，例如“锁消除”和“锁粗化”，感兴趣的铁子可以自行去了解一下，如果对各位有帮助的话，别忘了点赞+关注+收藏 哦~~笔芯

我的博客即将同步至腾讯云开发者社区，邀请大家一同入驻：https://cloud.tencent.com/developer/support-plan?invite_code=2hvub9qutack8

点我一起入驻