Synchronized锁优化
(1)引言
在JDK1.5之前,synchronized的底层实现都是重量级的,借助操作系统底层实现,也称之为synchronized为重量级锁,在JDK1.5之后,对Synchronized进行了各种优化,实现的原理是锁升级的过程,有了偏向锁、轻量级锁和重量级锁的概念。
(2)Java对象的内存布局
在Java中,创建一个对象后,在JVM中,对象在内存中的存储布局,分为三块:
- 对象头区域: 存放锁信息、对象年龄等信息。
- 实例数据区域: 存储的是对象的真正有效的信息,比如对象中所有字段内容。
- 对齐填充区域: JVM规定对象的起始地址必须是
8字节
的整数倍,如果一个对象实际占用的内存大小不是8字节的整数倍,就“补位”到8字节的整数倍,对齐填充区域的大小不是固定的。
synchronized
用的锁是存在对象头里,如果对象是数组类型,对象头中还包含了数组长度。
如果是数组类型,则虚拟机使用3个字宽存储对象头,如果不是数组类型,则占用2个字宽存储对象头,在32位系统下,1字宽等于4字节即32bit位。
在Java对象头中Mark Word是默认存储对象的
hashcode
,分代年龄
和锁的标记位
。32位JVM中Mark Word默认存储的结构如下图所示:
在Java SE1.6中,锁一共存在4种状态,级别从低到高依次是:无锁状态、偏向锁状态、轻量级锁状态和重量级锁状态,这几个状态随着竞争的情况逐渐升级,锁是可以升级的但是不能降级,意味着偏向锁升级成轻量级锁再升级为重量级锁,目的是为了提高获取锁和释放锁的效率。
(3)偏向锁
偏向锁的操作是无需操作系统介入的,每个对象都有对象头,对象头中的Mark Word区域存储对象的锁信息。
该对象头先处于无锁状态,当有线程来访问,JVM使用CAS操作将线程ID记录到Mark Word中,修改偏向锁的标识位,当前线程就拥有了这把锁
🚀注意:将线程ID通过CAS记录,变更偏向锁标识为1。JVM不用和操作系统协商设置monitor,只需要记录下线程ID,就表示当前线程拥有这把锁,不用操作系统介入获取锁的线程就可以进入到程序代码块中执行,当线程再次执行时,JVM通过锁对象的Mark Word判断,如果当前线程ID还存在,就说明该线程还持有着这个对象的锁,就直接进入临界区执行,这个就是偏向锁,在没有别的线程竞争的时候,一直偏向当前的线程可以一直执行。
优点:只有一个线程执行同步块时进一步提高性能,适用于一个线程反复获取同一个锁的情况,偏向锁可以提高带有同步但无竞争的程序的性能。
(4)轻量级锁
如果在偏向锁中一个线程A一直执行过程中,此时又来了另一个线程B要进入代码块中执行,但是锁对象保存的是线程A的线程ID,还是偏向锁,这时候就导致线程B无法执行,这个时候就需要对偏向锁进行升级,变成一个轻量级锁。
JVM把锁对象恢复成无锁状态,在当前的两个线程的栈帧中各分配一个空间,叫做Lock Record,把锁对象的Mark Word在两个线程的栈帧中各复制一份,叫做Displaced Mark Word,将当前线程A的Lock Record的地址使用CAS放到锁对象的Mark Word当中,并且将锁的标识设置为00,意味着当前线程A获取到轻量级锁,可以进入到临界区执行。
线程B没有获取到锁,但不阻塞,JVM会让他自旋几次,等待一会儿,当线程A退出了临界区释放锁的时候,需要将Displaced Mark Word使用CAS复制回去,接下来线程B就可以通过CAS复制信息。这个时候两个线程就可以交替进入临界区,执行代码。偏向锁即使出现了竞争,想获取锁只要自旋几次,等待一会,锁就可以是释放,使用CAS和Lock Record就可以避免重量级锁的开销。
优点:绝大部分的锁在整个生命周期中都存在少量竞争,在多线程交替执行同步代码块是可以避免重量级锁引起的性能问题。
(5)重量级锁
轻量级锁在运行时,线程A正在持有锁,另一个线程B自旋了好多次,线程A还没有释放锁,这个时候JVM考虑自旋次数太多浪费CPU资源,就需要将锁升级为重量级锁,重量级锁需要操作系统的介入,依赖操作系统底层的mutex lock,JVM会创建一个monitor对象,把这个对象的地址信息更新到Mark Word中,并将锁标志置为10。
线程A还在持有锁运行,线程B直接挂起,线程进入阻塞,释放掉占用的CPU资源。
版权声明:本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 举报,一经查实,本站将立刻删除。
文章由极客之音整理,本文链接:https://www.bmabk.com/index.php/post/95484.html