关于Synchronized竟然被面试者给怼趴下了

落日映苍穹つ 2022-11-27 00:49 337阅读 0赞

# Synchronized 是什么 #

来咱们先聊聊 Synchronized 是什么，你用过吗？

Synchronized 用过的，简单的说是用来控制线程同步的。

为了解决多线程下线程对资源的读写发生混乱，例如不同线程读写发生不一致的情况，所以需要给这些资源加上锁，保证资源读写的原子性。

Synchronized 大致可以分为 2 类，一种是锁住对象，一种是锁住类：

*  1.锁对象:
 *   *  同步代码块，Synchronized(o)
 *   *  同步方法，相当于 Synchronized(this)
 *  2.锁类：
 *   *  Synchronized(Object.class)
 *   *  同步静态方法,相当于 Synchronized(Class)

## 最好不要不要锁基础类型以及其包装类 ##

那 Synchronized 可以用来锁 Integer 类型吗？

最好不要这样使用。

因为 JDK1.5 之后 Integer 范围在\[-128-127\]之间的数据，会直接使用 IntegerCache 缓存起来，而不会产生新的对象，这样其他人如果要使用这个数字的时候需要等待你释放锁，可能降低效率，也可能和你预期的结果不一样。 同样的 Long、String 也是一样的道理，Long 也有缓存，String 是直接存在常量池中的，实际使用的时候最好别用。

## Synchronized 锁升级 ##

你前面说了 Synchronized 可以锁对象，锁类，确定他一定会发生锁这个操作吗？

要看怎么理解“锁”这个概念，如果说发生在操作系统级别的话，Synchronized 不是直接进行锁定的，他有一个锁升级的过程。 简单的说就是四个阶段：普通对象（匿名偏向）、偏向锁、轻量锁、重量锁。

## 锁升级过程 ##

你能详细的说一下他们的锁升级过程吗？

首先在未开启偏向锁的时候，刚刚创建出来的对象是普通对象。

如果进入被 Synchronized 修饰的代码中，对象会变成偏向锁。

当发生线程竞争的时候，偏向锁升级成为轻量锁。

当竞争加剧，出现十次自旋或者竞争线程数超过二分之一 CPU 核数时，轻量锁升级成为重量锁。

当然如果在 JVM 已经开启偏向锁的情况下，创建出来的对象是匿名偏向对象。

JVM 默认会设置一个偏向锁延迟开启，默认延迟 4 秒,通过-XX:BiasedLockingStartupDelay=0 这个参数来调节。

这样吧，我画一个锁升级的流程图：

![format_png][]

## markword ##

那你刚刚那张流程图，那些 CAS，自旋之类的操作具体是指什么？

这个就需要看一下对象头信息（markword）的结构了，因为 JVM 是通过更新 markword 信息实现 Synchronized 的。 我来画一张图，看下对象头包含了哪些东西。

![format_png 1][]

### 1.markword 三位控制锁状态 ###

简单的来说对象头中，最后三位用来控制锁的状态，其中 1 位用来表示是否偏向锁，2 位用来表示是什么状态的锁，当发生锁升级的时候会更新对象头信息。

### 2.一般来说进入同步区域就是偏向锁 ###

我们结合上面那个流程图，当普通对象进入同步区的时候（未调用 hashCode），对象头会保存一个当前线程的地址指针（相当于打了个标记，这条线程正在使用这个锁对象），并且在当前线程的 LR 栈中压入一条记录，此时进入偏向锁状态。

### 3.二次进入同步区域，原线程重入使用，发生竞争升级轻量锁 ###

第二次有线程进入此同步区域的时候，取出 markword 中的线程指针和当前线程对比，如果是同一个，重入次数+1，继续往 LR 栈中压入一条 LR 记录（退出的时候弹出，数量为 0 时说明完全释放了锁），执行同步区域内的代码。

如果第二次 markword 中的线程指针和当前线程地址不同，那么进行**偏向锁撤销**并升级为轻量锁。 使用 CAS 方式将 markword 中的头 62 位更新为指向当前线程中的 LR 地址，谁更新成功了，谁就获得了锁，其他的线程则采用自旋的方式继续尝试获取锁。

### 4.竞争激烈升级为重量级锁 ###

如果自旋的次数超过 10 次（JDK1.6 可以开启自适应自旋，统计代码的执行过程，自动调整自旋频次）或者竞争的线程数超过了 1/2CPU 核数，则升级为重量级锁，向操作系统申请。

当然如果调用了 wait 方法，会直接升级为重量级锁发生阻塞。

### 5.调用 hashCode 方法的对象进入同步区域直接升级成为轻量锁 ###

前面说了，是未调用 hashCode 方法的对象会升级为偏向锁， **如果计算过对象的 hashCode，则对象无法进入偏向状态！**

> 此处的 hashCode 是指没有被覆盖实现的 hashCode 方法，产生的 hashCode 是系统唯一编号 identityHashCode，同个对象每次调用一定是相同的，自己覆盖实现的 hashCode 不在此列。 原因是偏向锁的 markword 需要存储，线程指针以及 Epoch，hashcode 就没地方放了。

轻量级锁 hashCode 存在线程栈的 LR 中，不需要保存在对象头内，所以调用过 hashCode 方法会直接升级成为轻量锁。

> 重量级锁的 hashCode 存在 ObjectMonitor 的成员中

总结一下重点：

*  1.偏向锁、轻量锁都会生成 LockRecord
 *  2.轻量锁是 CAS+自旋的过程实现的
 *  3.自旋超过 10 次、二分之一 CPU 核数或者调用了 wait 方法升级为重量级锁
 *  4.偏向、轻量锁的重入会创建新的 LR 记录并压入 LR 栈内，重量级锁的重入应该是记录在 ObjectMonitor 中

# 底层实现 #

既然你说了这么多，那你知道 Synchronized 底层到底怎么实现的吗？

这个要看是从哪个层面说了。

*  **代码层面**自然不用说，使用 Synchronized 关键字。
 *  **JAVA 字节码层面**的话，同步方法用的是 monitor\_acc 修饰的方法定义，同步代码块使用 monitor\_enter,monitor\_exit 两个指令实现。
 *  **JVM 层面**就是之前说的那个锁升级过程，当中使用了 Atomic::cmpxchg\_ptr 之类的 CAS 操作调用了一些操作系统的指令 LOCK\_IF\_MP。
 *  **操作系统层面**是调用了汇编指令 lock cmpxchg，通过 lock 保证后面的命令（cmpxchg）只能一个线程执行。
 *  **硬件层面**，是锁住了一个北桥的信号量。

# 其他关键点 #

小伙子有两把刷子阿，到了这里我觉得这个小伙子 Synchronized 掌握的还不错，所以我觉得再考验他一下。

## 锁消除 ##

你知道锁消除吗？

说白了就是，绝对不需要用锁的情况，就把他消除掉。

锁消除是 JVM 在即时编译器在运行期间，检测到当前锁只会在线程安全的情况下执行，JVM 会自动消除该代码的锁。

定义一个 StringBuffer 为局部变量，不能被其他线程引用，JVM 会自动消除 Stringbuffer 内部的锁。

public void add(String str1,String str2){
             StringBuffer sb = new StringBuffer();
             sb.append(str1).append(str2);
    }

## 锁粗化 ##

那锁粗化听过吗？

说白了就是，连续多次使用同个对象锁，直接扩大范围，加一次锁就够了。

JVM 会检测到这样一连串的操作都对同一个对象加锁（while 循环内 100 次执行 append，没有锁粗化的就要进行 100 次加锁/解锁），此时 JVM 就会将加锁的范围粗化到这一连串的操作的外部（比如 while 虚幻体外），使得这一连串操作只需要加一次锁即可。

public String test(String str){
    
           int i = 0;
           StringBuffer sb = new StringBuffer():
           while(i < 100){
               sb.append(str);
               i++;
           }
           return sb.toString():
    }

## Epoch ##

你刚刚说偏向锁 markword 中有一个 Epoch，这个用来干嘛的？

面试者皱着眉头，我看得出他很不舒服，估计是佩服我能问出如此刁钻的问题吧。

简单的说，Epoch 是用来定义当前偏向锁属于哪一代的，发生**批量重偏向**的时候 class 中的 epoch + 1，淘汰老一代的 epoch。

额，还有更加清楚的说法吗？

### 偏向锁撤销 ###

这个就要从偏向锁撤销开始聊了。

一条线程，对一个 class 创建了大量的对象来作为偏向锁，当他退出同步代码块或者升级为轻量锁时，需要对这一大堆对象进行撤销，这个时候非常的浪费资源。

能想到解决办法有 2 个，1 是不撤销，2 是直接使用轻量锁。

这两个办法对应了 2 个概念，1 批量重偏向，2 批量撤销：

*  批量重偏向（bulk rebias）机制是为了解决：一个线程创建了大量对象并执行了初始的同步操作，后来另一个线程也来将这些对象作为锁对象进行操作，升级为轻量锁，这样会导致大量的偏向锁撤销操作。
 *  批量撤销（bulk revoke）机制是为了解决：在明显多线程竞争剧烈的场景下使用偏向锁是不合适的。

### 批量重偏向 ###

class 中维护了一个统计撤销次数的属性（不是 epoch），每次对象发生一次锁撤销，统计数量累加 1。 当这个累计数量达到了 20 的时候，说明这个锁有大量的撤销对象，需要进行批量重偏向。

class 中也有一个 epoch，假设此时为 0，发生批量重偏向的时候，将 class 中的 epoch 加 1，此时 markword 中的 epoch 仍然为 0，不需要再对锁进行撤销了。

下一次有线程需要获取偏向锁，只要对比当前对象的 epoch 是否等于 class 中的 epoch，如果不相等，说明 class 升级了一代，旧一代被淘汰了，可以直接更新 markword 中的线程指针为当前线程的指针，从而获得锁。（节约了大量锁撤销的资源）

备注：当有新的对象产生时，epoch（代数）会与 class 中的 epoch 保持一致。

但是此时该 class 还有一些正在使用中的对象，所以 JVM 会遍历每一个线程栈，找到该 class 的实例，将实例中 markword 的 epoch 也加 1。

### 批量撤销（不可偏向） ###

当达到重偏向阈值后，假设该 class 计数器继续增长，当其达到批量撤销的阈值后（默认 40），JVM 就认为该 class 的使用场景存在多线程竞争，会标记该 class 为不可偏向，之后，对于该 class 的锁，直接走轻量级锁的逻辑。

# CAS #

前面你说了其中使用了 CAS，说一下你对 CAS 怎么理解的。

CAS 英文全称是 Compare And Swap (Compare And Exchange)

简单的说是比较然后交换。

cas 一般有三个参数 cas(v,a,b)

*  v：需要更改的变量
 *  a：期望值（读取的旧值）
 *  b：当前值（当前内存中的值）

读取 a，计算之后得到 v， 再把内存中的 a 更新成为 v

先拿 a 去与内存中的值(b)比较,如果相等说明，a 没有被其他线程更新过，可以更新为 v。

如果 a 与 b 不等，则说明内存中的值已经发生变化，更新失败，重新拿到内存中的 b 再更新。

![format_png 2][]

\#\# ABA 问题 CAS 会发生什么问题吗？比如 ABA 问题了解过吗？

ABA 是指，中间某个线程，把 a 的值改变了，另外一个线程又把他改回成为 a 了，这个时候当前线程去比较 a 与 内存中的值的时候，也是相等的，可以更新成功。

在 integer 之类的基础类型，其实不需要关心，更新值成功就行了。

某些场景下，需要解决 ABA 问题，加上版本号就行了。（不要比较值，比较版本号）

\#\#CAS 底层实现 前面也提到过 CAS 底层实现

*  java 源码层 使用了 Unsafe 类中的 compareAndSwap 方法
 *  JVM 层 使用了 LOCK\_IF\_MP，多线程下加锁
 *  操作系统汇编层： lock cmpxchg
 *  硬件层面： 锁北桥信号

[format_png]: /images/20221124/d1fb7789324f47eab6cdc4cfc31f6126.png
[format_png 1]: /images/20221124/a2fd22b17e0c45dcb2251cfdedd5bd92.png
[format_png 2]: /images/20221124/493cbe5fc8254ec88abe8a8fe694a828.png