前言
Java 中的 synchronized 关键字可以在多线程环境下用来作为线程安全的同步锁. 本文不讨论 synchronized 的具体使用, 而是研究下 synchronized 底层的锁机制, 以及这些锁分别的优缺点.
一 synchronized 机制
synchronized 关键字是 JAVA 中常用的同步功能, 提供了简单易用的锁功能.
synchronized 有三种用法, 分别为:
用在普通方法上, 能够锁住当前对象.
用在静态方法上, 能够锁住类
用在代码块上, 锁住的是 synchronized()里的对象
在 JDK6 之前, synchronized 使用的是重量级锁制, 在之后 synchronized 加入了锁膨胀机制, 显著提升了 synchronized 关键字的效率.
基于 synchronized 关键字, 我们来了解下几种类别的锁, 并且讲解 synchronized 的锁膨胀机制.
synchronized 锁是非公平锁. 并且一个被 synchronized 锁住的对象或类, 就是一把锁.
另外一提, 所有锁都是存储在 Java 对象头里的, Java 对象头里的 Mark Word 里默认存储对象的 HashCode, 分代年龄和锁标记位. 也就是说 Mark Word 记录了锁的状态
二 锁膨胀机制与几类锁
锁膨胀是不可逆的
2.1 偏向锁
synchronized 在 JDK1.6 以后默认开启偏向锁, synchronized 最初都是偏向锁
表现: 一个线程获取锁成功后, 会在对象头里记录线程 ID, 以后该线程获取和释放锁都没有任何花费.(因为该锁已经被绑定在该线程上了, 且在膨胀前不会改变), 如果其他线程尝试获取这个锁, 偏向锁将会膨胀为轻量锁.
优点: 在只有一个线程使用锁的时候获取和退出锁没有任何花费
缺点: 锁竞争激烈会很快升级为轻量锁, 那么维持偏向锁的过程就是在浪费计算机资源.(不过因为偏向锁本身就很轻量, 因此浪费的资源并不多)
小结: 只有一个线程使用锁的情况下, synchronized 使用的锁为偏向锁.
如果锁竞争激烈, 可以通过配置 JDK 禁用偏向锁.
2.2 轻量锁
一把锁不止一个线程使用, 则偏向锁膨胀为轻量锁
表现: 线程获取轻量锁时, 会直接用 CAS 修改对象头里锁的记录, 如果修改失败, 代表此时锁存在多个线程的竞争, 轻量锁将会膨胀为重量锁.
优点: 在线程之间使用锁不存在竞争时, 一次 CAS 操作就能获取和退出锁
缺点: 与偏向锁类似
小结: 只要一把锁不止一个线程获取过, 偏向锁就会膨胀为轻量锁.
2.3 重量锁
一把锁存在多线程竞争, 则轻量锁开始自旋, 自旋一定次数后仍没获取锁, 则膨胀为重量锁(存在竞争时, 轻量锁虽然会先自旋, 但是最终往往都会膨胀为重量锁)
表现: 线程获取重量锁时, 如果获取失败(即锁已被其他线程获取), 则使用自适应自旋锁, 自旋一定次数后仍没获取锁, 则进入阻塞队列等待.
优点: 未获取到的锁进入阻塞队列, 节约 CPU 资源.(好吧感觉其实是没有啥优点)
缺点: 重量锁是通过对象内部的监视器 (monitor) 实现, 其中 monitor 的本质是依赖于底层操作系统的 Mutex Lock 实现, 操作系统实现线程之间的切换需要从用户态到内核态的切换, 切换成本非常高.
小结: 只要一把锁存在多线程竞争, 轻量锁就会膨胀为重量锁.
自旋锁
synchronized 的轻量锁, 重量锁, 使用了自适应自旋锁进行性能优化
首先介绍自旋锁
表现: 线程获取锁失败后, 不会进入阻塞等待, 而是再次尝试去获取锁, 如此反复, 直到获取到锁, 或者自旋结束那么会阻塞等待.
解决问题: 在某些场景下, 线程持有锁的时间非常短. 在线程获取锁失败后, 如果线程进入阻塞将会带来线程上下文的切换, 上下文切换的时间可能反而高于线程反复尝试获取锁的时间.
此时线程原地等待去重复获取锁. 反而在性能上更有优势.
缺点:
单核 CPU 没有线程并行, 反复尝试会导致进程无法继续运行.
重复尝试导致了 CPU 的占用, 如果 CPU 资源紧张的话反而会性能下降
如果锁的竞争时间过长, 不仅没有性能提升, 还浪费了大量 CPU 资源.
优化: 使用自适应自旋锁. 自适应自旋锁会根据之前的锁获取记录, 优化调整自旋时间, 避免造成不必要的自旋.
三 具体 synchronized 流程
来源: https://www.cnblogs.com/taojinxuan/p/11139398.html