前言
博主个人社区：开发与算法学习社区
博主个人主页：Killing Vibe的博客
欢迎大家加入，一起交流学习~~
一、基本特点
结合多线程锁的策略, 我们就可以总结出, Synchronized 具有以下特性(只考虑 JDK 1.8):
- 开始时是乐观锁, 如果锁冲突频繁, 就转换为悲观锁.
- 开始是轻量级锁实现, 如果锁被持有的时间较长, 就转换成重量级锁.
- 实现轻量级锁的时候大概率用到的自旋锁策略
- 是一种不公平锁
- 是一种可重入锁
- 不是读写锁
JVM为Java程序员操碎了心，看起来都用的synchronized关键字，背后到底是啥锁，JVM来进行处理，会根据竞争的激烈程度动态选择锁的实现。
二、加锁过程
图解如下：
(1) 无锁
没有任何线程进入同步方法，此时对象就是无锁状态，没有任何线程尝试获取该锁
synchronized void increase(){val++;}
(2) 偏向锁
当有第一个线程（t1）尝试获取该锁时，JVM分配偏向锁给该线程（t1），当这个线程t1再次获取锁时（重入或者是再次执行），没有加锁和解锁过程，就验证一下锁的持有线程是否为t1，若是直接放行。
偏向锁不是真的加锁, 而只是在锁的对象头中记录一个标记(记录该锁所属的线程). 如果没有其他线程参与竞争锁, 那么就不会真正执行加锁操作, 从而降低程序开销. 一旦真的涉及到其他的线程竞争, 再取消偏向锁状态, 进入轻量级锁状态.
偏向锁本质上相当于 “延迟加锁” . 能不加锁就不加锁, 尽量来避免不必要的加锁开销.
但是该做的标记还是得做的, 否则无法区分何时需要真正加锁
(3) 轻量级锁
当有第二个线程 （t2） 在 t1 执行之后尝试获取锁，JVM就会取消偏向锁的状态，将锁升级为轻量级锁。
使用CAS（自旋锁）来进行轻量级锁的获取，有加锁和解锁的过程，就是通过自旋来进行的。
t2线程尝试通过自旋的方式来获取轻量级锁
还有其他线程t3 ， t4 在t2 还没结束的时候尝试获取锁，都在自旋等待t2执行结束。
自旋操作是一直让 CPU 空转, 比较浪费 CPU 资源.
因此此处的自旋不会一直持续进行, 而是达到一定的时间/重试次数, 就不再自旋了.
也就是所谓的 “自适应
(4) 重量级锁
当竞争非常激烈，多个线程同时在竞争轻量级锁（一般来说就是当前线程数为CPU核数一半），就会将轻量级锁膨胀为重量级锁 或者 自旋次数超过10次（默认值）以上，就会将轻量级锁膨胀为重量级锁（竞争比较激烈，为了避免CPU空跑，就将线程阻塞）
具体如下：
- 执行加锁操作, 先进入内核态.
- 在内核态判定当前锁是否已经被占用
- 如果该锁没有占用, 则加锁成功, 并切换回用户态.
- 如果该锁被占用, 则加锁失败. 此时线程进入锁的等待队列, 挂起. 等待被操作系统唤醒.
- 经历了一系列的沧海桑田, 这个锁被其他线程释放了, 操作系统也想起了这个挂起的线程, 于是唤醒这个线程, 尝试重新获取锁.
拓展：
- 重量级锁依赖操作系统提供的mutex来实现（用户态切换到内核态），开销比较大
- 只要程序中调用了Object.wait()方法，直接会将锁膨胀为重量级锁，无论当前竞争激烈与否，wait方法实际上需要对象monitor实现。
总结
编译器+JVM 还在背后做了很多策略优化，例如“锁消除”和“锁粗化”，感兴趣的铁子可以自行去了解一下，如果对各位有帮助的话，别忘了点赞+关注+收藏 哦~~笔芯
我的博客即将同步至腾讯云开发者社区，邀请大家一同入驻：https://cloud.tencent.com/developer/support-plan?invite_code=2hvub9qutack8
点我一起入驻
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 举报，一经查实，本站将立刻删除。
文章由极客之音整理，本文链接：https://www.bmabk.com/index.php/post/115462.html
