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资源。