常见面试题之线程中并发锁（一）

野性酷女 2024-03-17 13:31 51阅读 0赞

### 1. 讲一下synchronized关键字的底层原理？ ###

#### 1.1. 基本使用 ####

如下抢票的代码，如果不加锁，就会出现超卖或者一张票卖给多个人

`Synchronized`【对象锁】采用互斥的方式让同一时刻至多只有一个线程能持有【对象锁】，其它线程再想获取这个【对象锁】时就会阻塞住

public class TicketDemo {
        
    
        static Object lock = new Object();
        int ticketNum = 10;
    
    
        public synchronized void getTicket() {
        
            synchronized (this) {
        
                if (ticketNum <= 0) {
        
                    return;
                }
                System.out.println(Thread.currentThread().getName() + "抢到一张票,剩余:" + ticketNum);
                // 非原子性操作
                ticketNum--;
            }
        }
    
        public static void main(String[] args) {
        
            TicketDemo ticketDemo = new TicketDemo();
            for (int i = 0; i < 20; i++) {
        
                new Thread(() -> {
        
                    ticketDemo.getTicket();
                }).start();
            }
        }
    
    
    }

#### 1.2. `Monitor` ####

`Monitor`被翻译为监视器，是由`jvm`提供，`c++`语言实现

在代码中想要体现`monitor`需要借助`javap`命令查看`clsss`的字节码，比如以下代码：

public class SyncTest {
        
    
        static final Object lock = new Object();
        static int counter = 0;
        public static void main(String[] args) {
        
            synchronized (lock) {
        
                counter++;
            }
        }
    }

找到这个类的`class`文件，在`class`文件目录下执行`javap -v SyncTest.class`，反编译效果如下：

![在这里插入图片描述][a1d917248db042b89dafd797e4b50085.png_pic_center]

>  *  `monitorenter` 上锁开始的地方
>  *  `monitorexit` 解锁的地方
>  *  其中被`monitorenter`和`monitorexit`包围住的指令就是上锁的代码
>  *  有两个`monitorexit`的原因，第二个`monitorexit`是为了防止锁住的代码抛异常后不能及时释放锁

在使用了`synchornized`代码块时需要指定一个对象，所以`synchornized`也被称为对象锁

`monitor`主要就是跟这个对象产生关联，如下图

![在这里插入图片描述][351918fe483e45e4b84b21d687f74f5f.png_pic_center]

`Monitor`内部具体的存储结构：

*  `Owner`：存储当前获取锁的线程的，只能有一个线程可以获取
 *  `EntryList`：关联没有抢到锁的线程，处于`Blocked`状态的线程
 *  `WaitSet`：关联调用了wait方法的线程，处于`Waiting`状态的线程

具体的流程：

*  代码进入`synchorized`代码块，先让`lock`（对象锁）关联的`monitor`，然后判断`Owner`是否有线程持有
 *  如果没有线程持有，则让当前线程持有，表示该线程获取锁成功
 *  如果有线程持有，则让当前线程进入`entryList`进行阻塞，如果`Owner`持有的线程已经释放了锁，在`EntryList`中的线程去竞争锁的持有权（非公平）
 *  如果代码块中调用了`wait()`方法，则会进去`WaitSet`中进行等待

参考回答：

*  `Synchronized`【对象锁】采用互斥的方式让同一时刻至多只有一个线程能持有【对象锁】
 *  它的底层由`monitor`实现的，`monitor`是`jvm`级别的对象（`C++`实现），线程获得锁需要使用对象（锁）关联`monitor`
 *  在`monitor`内部有三个属性，分别是`owner`、`entrylist`、`waitset`
 *  其中`owner`是关联的获得锁的线程，并且只能关联一个线程；`entrylist`关联的是处于阻塞状态的线程；`waitset`关联的是处于Waiting状态的线程

### 2. `synchronized`关键字的底层原理-进阶 ###

`Monitor`实现的锁属于重量级锁，你了解过锁升级吗？

*  `Monitor`实现的锁属于重量级锁，里面涉及到了用户态和内核态的切换、进程的上下文切换，成本较高，性能比较低。
 *  在`JDK 1.6`引入了两种新型锁机制：偏向锁和轻量级锁，它们的引入是为了解决在没有多线程竞争或基本没有竞争的场景下因使用传统锁机制带来的性能开销问题。

#### 2.1. 对象的内存结构 ####

在`HotSpot`虚拟机中，对象在内存中存储的布局可分为3块区域：对象头（`Header`）、实例数据（`Instance Data`）和对齐填充

![在这里插入图片描述][1b07ff095e354ac192f9efa8b1c6bcc9.png_pic_center]

我们需要重点分析`MarkWord`对象头

#### 2.2. `MarkWord` ####

![在这里插入图片描述][aaa6cb608fc74066a83d93294028896b.png_pic_center]

>  *  `hashcode`：25位的对象标识`Hash`码
>  *  `age`：对象分代年龄占4位
>  *  `biased_lock`：偏向锁标识，占1位 ，0表示没有开始偏向锁，1表示开启了偏向锁
>  *  `thread`：持有偏向锁的线程`ID`，占23位
>  *  `epoch`：偏向时间戳，占2位
>  *  `ptr_to_lock_record`：轻量级锁状态下，指向栈中锁记录的指针，占30位
>  *  `ptr_to_heavyweight_monitor`：重量级锁状态下，指向对象监视器`Monitor`的指针，占30位

我们可以通过`lock`的标识，来判断是哪一种锁的等级

*  后三位是001表示无锁
 *  后三位是101表示偏向锁
 *  后两位是00表示轻量级锁
 *  后两位是10表示重量级锁

#### 2.3. 再说`Monitor`重量级锁 ####

每个 `Java`对象都可以关联一个`Monitor`对象，如果使用`synchronized`给对象上锁（重量级）之后，**该对象头的`Mark Word`中就被设置指向`Monitor`对象的指针**

![在这里插入图片描述][b4e1683ec856414ababca994745cbec7.png_pic_center]

简单说就是：每个对象的对象头都可以设置`monoitor`的指针，让对象与`monitor`产生关联

#### 2.4. 轻量级锁 ####

在很多的情况下，在`Java`程序运行时，同步块中的代码都是不存在竞争的，不同的线程交替的执行同步块中的代码。这种情况下，用重量级锁是没必要的。因此`JVM`引入了轻量级锁的概念。

static final Object obj = new Object();
    
    public static void method1() {
        
        synchronized (obj) {
        
            // 同步块 A
            method2();
        }
    }
    
    public static void method2() {
        
        synchronized (obj) {
        
            // 同步块 B
        }
    }

**加锁的流程**

1.在线程栈中创建一个`Lock Record`，将其`obj`字段指向锁对象。

![在这里插入图片描述][88830257d0aa49609f5963405f11be0a.png_pic_center]

2.通过`CAS`指令将`Lock Record`的地址存储在对象头的`mark word`中（数据进行交换），如果对象处于无锁状态则修改成功，代表该线程获得了轻量级锁。

![在这里插入图片描述][7166071ca42c4c8394dba0741f6cb7b0.png_pic_center]

3.如果是当前线程已经持有该锁了，代表这是一次锁重入。设置`Lock Record`第一部分为`null`，起到了一个重入计数器的作用。

![在这里插入图片描述][6d81644d6f454f1fa04d285d1da5369f.png_pic_center]

4.如果`CAS`修改失败，说明发生了竞争，需要膨胀为重量级锁。

**解锁过程**

1.遍历线程栈,找到所有`obj`字段等于当前锁对象的`Lock Record`。

2.如果`Lock Record`的`Mark Word`为`null`，代表这是一次重入，将`obj`设置为`null`后`continue`。

![在这里插入图片描述][a7ec19bd1a3140a7bdd7627d56800a7b.png_pic_center]

3.如果`Lock Record`的`Mark Word`不为`null`，则利用`CAS`指令将对象头的`mark word`恢复成为无锁状态。如果失败则膨胀为重量级锁。

![在这里插入图片描述][a9ce1a9c1ad341dcb0f159d6f6012aba.png_pic_center]

#### 2.5. 偏向锁 ####

轻量级锁在没有竞争时（就自己这个线程），每次重入仍然需要执行`CAS`操作。

`Java 6`中引入了偏向锁来做进一步优化：只有第一次使用`CAS`将线程`ID`设置到对象的`Mark Word`头，之后发现

这个线程`ID`是自己的就表示没有竞争，不用重新`CAS`。以后只要不发生竞争，这个对象就归该线程所有

static final Object obj = new Object();
    
    public static void m1() {
        
        synchronized (obj) {
        
            // 同步块 A
            m2();
        }
    }
    
    public static void m2() {
        
        synchronized (obj) {
        
            // 同步块 B
            m3();
        }
    }
    
    public static void m3() {
        
        synchronized (obj) {
        
    
        }
    }

**加锁的流程**

1.在线程栈中创建一个`Lock Record`，将其`obj`字段指向锁对象。

![在这里插入图片描述][5e064491c99941898959785d99272f3e.png_pic_center]

2.通过`CAS`指令将`Lock Record`的\*\*线程`id`\*\*存储在对象头的`mark word`中，同时也设置偏向锁的标识为101，如果对象处于无锁状态则修改成功，代表该线程获得了偏向锁。

![在这里插入图片描述][61ef9d3062c44eccb85c5591c45178bc.png_pic_center]

3.如果是当前线程已经持有该锁了，代表这是一次锁重入。设置`Lock Record`第一部分为`null`，起到了一个重入计数器的作用。与轻量级锁不同的时，这里不会再次进行`cas`操作，只是判断对象头中的线程`id`是否是自己，因为缺少了`cas`操作，性能相对轻量级锁更好一些

![在这里插入图片描述][b75c4b0599514aadbae1a385a5ad0a25.png_pic_center]

解锁流程参考轻量级锁

#### 2.6. 参考回答 ####

`Java`中的`synchronized`有偏向锁、轻量级锁、重量级锁三种形式，分别对应了锁只被一个线程持有、不同线程交替持有锁、多线程竞争锁三种情况。

<table> 
 <thead> 
  <tr> 
   <th></th> 
   <th><strong>描述</strong></th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>重量级锁</td> 
   <td>底层使用的<code>Monitor</code>实现，里面涉及到了用户态和内核态的切换、进程的上下文切换，成本较高，性能比较低。</td> 
  </tr> 
  <tr> 
   <td>轻量级锁</td> 
   <td>线程加锁的时间是错开的（也就是没有竞争），可以使用轻量级锁来优化。轻量级修改了对象头的锁标志，相对重量级锁性能提升很多。每次修改都是<code>CAS</code>操作，保证原子性</td> 
  </tr> 
  <tr> 
   <td>偏向锁</td> 
   <td>一段很长的时间内都只被一个线程使用锁，可以使用了偏向锁，在第一次获得锁时，会有一个<code>CAS</code>操作，之后该线程再获取锁，只需要判断<code>mark word</code>中是否是自己的线程id即可，而不是开销相对较大的<code>CAS</code>命令</td> 
  </tr> 
 </tbody> 
</table>

**一旦锁发生了竞争，都会升级为重量级锁**

### 3. 你谈谈`JMM`（`Java`内存模型） ###

`JMM`(`Java Memory Model`) `Java`内存模型，是`java`虚拟机规范中所定义的一种内存模型。

`Java`内存模型(`Java Memory Model`)描述了`Java`程序中各种变量(线程共享变量)的访问规则，以及在`JVM`中将变量存储到内存和从内存中读取变量这样的底层细节。

![在这里插入图片描述][fb580da4f8214a20b1f972ca4448bdd3.png_pic_center]

特点：

1.  所有的共享变量都存储于主内存(计算机的`RAM`)这里所说的变量指的是实例变量和类变量。不包含局部变量，因为局部变量是线程私有的，因此不存在竞争问题。
2.  每一个线程还存在自己的工作内存，线程的工作内存，保留了被线程使用的变量的工作副本。
3.  线程对变量的所有的操作(读，写)都必须在工作内存中完成，而不能直接读写主内存中的变量，不同线程之间也不能直接访问对方工作内存中的变量，线程间变量的值的传递需要通过主内存完成。

### 4. `CAS`你知道吗？ ###

#### 4.1. 概述及基本工作流程 ####

`CAS`的全称是： `Compare And Swap`(比较再交换)，它体现的一种乐观锁的思想，在无锁情况下保证线程操作共享数据的原子性。

在`JUC`（`java.util.concurrent`）包下实现的很多类都用到了`CAS`操作

*  `AbstractQueuedSynchronizer`（`AQS`框架）
 *  `AtomicXXX`类

例子：

我们还是基于刚才介绍过的`JMM`内存模型进行说明

*  线程1与线程2都从主内存中获取变量`int a = 100`，同时放到各个线程的工作内存中

![在这里插入图片描述][6702045467304d3f98006143c94b7306.png_pic_center]

> 一个当前内存值`V`、旧的预期值`A`、即将更新的值`B`，当且仅当旧的预期值`A`和内存值`V`相同时，将内存值修改为`B`并返回`true`，否则什么都不做，并返回`false`。如果`CAS`操作失败，通过自旋的方式等待并再次尝试，直到成功

*  线程1操作：`V`：`int a = 100`，`A`：`int a = 100`，`B`：修改后的值：`int a = 101 (a++)`
    
     *  线程1拿`A`的值与主内存`V`的值进行比较，判断是否相等
     *  如果相等，则把`B`的值101更新到主内存中

![在这里插入图片描述][b6520434d64b44c5b69423908ca6046e.png_pic_center]

*  线程2操作：`V`：`int a = 100`，`A`：`int a = 100`，`B`：修改后的值：`int a = 99(a--)`
    
     *  线程2拿`A`的值与主内存`V`的值进行比较，判断是否相等(目前不相等，因为线程1已更新`V`的值99)
     *  不相等，则线程2更新失败

![在这里插入图片描述][0946b79fd0b04d50bfcd64f49a1a3eeb.png_pic_center]

*  自旋锁操作
    
     *  因为没有加锁，所以线程不会陷入阻塞，效率较高
     *  如果竞争激烈，重试频繁发生，效率会受影响

![在这里插入图片描述][18a1406ddda9470c8ab0d2260494bcc7.png_pic_center]

需要不断尝试获取共享内存V中最新的值，然后再在新的值的基础上进行更新操作，如果失败就继续尝试获取新的值，直到更新成功

#### 4.2. `CAS`底层实现 ####

`CAS`底层依赖于一个`Unsafe`类来直接调用操作系统底层的`CAS`指令

![在这里插入图片描述][10e4a3850ae64533bd3d1a3d599567c4.png_pic_center]

都是`native`修饰的方法，由系统提供的接口执行，并非`java`代码实现，一般的思路也都是自旋锁实现

![在这里插入图片描述][35400e10f8b74ee987f77f89165fde85.png_pic_center]

在`java`中比较常见使用有很多，比如`ReentrantLock`和`Atomic`开头的线程安全类，都调用了`Unsafe`中的方法

*  `ReentrantLock`中的一段`CAS`代码

![在这里插入图片描述][431557ba127d4a19995f64c39da8bb56.png_pic_center]

#### 4.3. 乐观锁和悲观锁 ####

*  `CAS`是基于乐观锁的思想：最乐观的估计，不怕别的线程来修改共享变量，就算改了也没关系，我吃亏点再重试呗。
 *  `synchronized`是基于悲观锁的思想：最悲观的估计，得防着其它线程来修改共享变量，我上了锁你们都别想改，我改完了解开锁，你们才有机会。

### 5. 请谈谈你对`volatile`的理解？ ###

一旦一个共享变量（类的成员变量、类的静态成员变量）被`volatile`修饰之后，那么就具备了两层语义：

#### 5.1. 保证线程间的可见性 ####

保证了不同线程对这个变量进行操作时的可见性，即一个线程修改了某个变量的值，这新值对其他线程来说是立即可见的，`volatile`关键字会强制将修改的值立即写入主存。

一个典型的例子：永不停止的循环

package com.dcxuexi.basic;
    
    // 可见性例子
    // -Xint
    public class ForeverLoop {
        
        static boolean stop = false;
    
        public static void main(String[] args) {
        
            new Thread(() -> {
        
                try {
        
                    Thread.sleep(100);
                } catch (InterruptedException e) {
        
                    e.printStackTrace();
                }
                stop = true;
                System.out.println("modify stop to true...");
            }).start();
            foo();
        }
    
        static void foo() {
        
            int i = 0;
            while (!stop) {
        
                i++;
            }
            System.out.println("stopped... c:"+ i);
        }
    }

当执行上述代码的时候，发现`foo()`方法中的循环是结束不了的，也就说读取不到共享变量的值结束循环。

主要是因为在`JVM`虚拟机中有一个`JIT`（即时编辑器）给代码做了优化。

> 上述代码
> 
>     while (!stop) {
>          
>     i++;
>     }
> 
> 在很短的时间内，这个代码执行的次数太多了，当达到了一个阈值，`JIT`就会优化此代码，如下：
> 
>     while (true) {
>          
>     i++;
>     }
> 
> 当把代码优化成这样子以后，及时`stop`变量改变为了`false`也依然停止不了循环

解决方案：

第一：

在程序运行的时候加入`vm`参数`-Xint`表示禁用即时编辑器，不推荐，得不偿失（其他程序还要使用）

第二：

在修饰`stop`变量的时候加上`volatile`,表示当前代码禁用了即时编辑器，问题就可以解决，代码如下：

static volatile boolean stop = false;

#### 5.2. 禁止进行指令重排序 ####

用`volatile`修饰共享变量会在读、写共享变量时加入不同的屏障，阻止其他读写操作越过屏障，从而达到阻止重排序的效果

![在这里插入图片描述][ed93319c63934ef08e30a72a55643bd0.png_pic_center]

在去获取上面的结果的时候，有可能会出现4种情况

情况一：先执行`actor2`获取结果`--->0`，0(正常)

情况二：先执行`actor1`中的第一行代码，然后执行`actor2`获取结果`--->0`，1(正常)

情况三：先执行`actor1`中所有代码，然后执行`actor2`获取结果`--->1`，1(正常)

情况四：先执行`actor1`中第二行代码，然后执行`actor2`获取结果`--->1`，0(发生了指令重排序，影响结果)

**解决方案**

在变量上添加`volatile`，禁止指令重排序，则可以解决问题

![在这里插入图片描述][23fd46a5e47d4b16839cc3228c144417.png_pic_center]

屏障添加的示意图

![在这里插入图片描述][31e7071834f04a489f392c72e5807ff5.png_pic_center]

*  写操作加的屏障是阻止上方其它写操作越过屏障排到`volatile`变量写之下
 *  读操作加的屏障是阻止下方其它读操作越过屏障排到`volatile`变量读之上

**其他补充**

我们上面的解决方案是把`volatile`加在了`int y`这个变量上，我们能不能把它加在`int x`这个变量上呢？

下面代码使用`volatile`修饰了`x`变量

![在这里插入图片描述][d8e0ac1d35a94da79da7fa6c4270f78f.png_pic_center]

屏障添加的示意图

![在这里插入图片描述][3c7fb6a33a214a56a698ac868babe082.png_pic_center]

这样显然是不行的，主要是因为下面两个原则：

*  写操作加的屏障是阻止上方其它写操作越过屏障排到`volatile`变量写之下
 *  读操作加的屏障是阻止下方其它读操作越过屏障排到`volatile`变量读之上

[a1d917248db042b89dafd797e4b50085.png_pic_center]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/15/8ab9ead754a44968b345ce0c7f244eac.png
[351918fe483e45e4b84b21d687f74f5f.png_pic_center]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/15/a76bd59dde9b4880af643bee06d3a89f.png
[1b07ff095e354ac192f9efa8b1c6bcc9.png_pic_center]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/15/28b118adfef345dd8071cdf56324478b.png
[aaa6cb608fc74066a83d93294028896b.png_pic_center]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/15/38190a8e1b84445f980b87aa5ffc3903.png
[b4e1683ec856414ababca994745cbec7.png_pic_center]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/15/175f31d0d064412d83f7473172509c9b.png
[88830257d0aa49609f5963405f11be0a.png_pic_center]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/15/36b2088820b249b9a416b9d7e02793d6.png
[7166071ca42c4c8394dba0741f6cb7b0.png_pic_center]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/15/7ab7dc761a9d4162b6db646afc52fb40.png
[6d81644d6f454f1fa04d285d1da5369f.png_pic_center]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/15/d5084ab776f641dfaefc102231227f1d.png
[a7ec19bd1a3140a7bdd7627d56800a7b.png_pic_center]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/15/84307799b04448f9bd6026a3f3d8ce0d.png
[a9ce1a9c1ad341dcb0f159d6f6012aba.png_pic_center]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/15/98d724d83eec40dd8da503de53e2fa70.png
[5e064491c99941898959785d99272f3e.png_pic_center]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/15/16a3c72714ef4895bd1e7ebcf25c6f0b.png
[61ef9d3062c44eccb85c5591c45178bc.png_pic_center]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/15/dc0328e35f2042f586733acc9edab756.png
[b75c4b0599514aadbae1a385a5ad0a25.png_pic_center]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/15/f19309330f774a0880b41de4839a76c6.png
[fb580da4f8214a20b1f972ca4448bdd3.png_pic_center]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/15/bf71cbdaa2c0475e8412f7b64ee7c722.png
[6702045467304d3f98006143c94b7306.png_pic_center]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/15/b3ff37cac6094fad974cdd22218b7955.png
[b6520434d64b44c5b69423908ca6046e.png_pic_center]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/15/002f704a0ccb48cc91c7d4bfb2944289.png
[0946b79fd0b04d50bfcd64f49a1a3eeb.png_pic_center]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/15/60a9e47d3b2e4168bd1534929b0e473a.png
[18a1406ddda9470c8ab0d2260494bcc7.png_pic_center]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/15/571c0612fd734e5bb6210ddf909904d5.png
[10e4a3850ae64533bd3d1a3d599567c4.png_pic_center]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/15/7698af243584471eaa5fad85f7332caf.png
[35400e10f8b74ee987f77f89165fde85.png_pic_center]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/15/057cc2d64b5149b0a0591f00e9e0eb50.png
[431557ba127d4a19995f64c39da8bb56.png_pic_center]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/15/57ddb157d0e544dbb354ba196405f090.png
[ed93319c63934ef08e30a72a55643bd0.png_pic_center]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/15/625116eb50ea4efb888dcc275cb7aca4.png
[23fd46a5e47d4b16839cc3228c144417.png_pic_center]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/15/9630714f09a24183a49012609ca68e1a.png
[31e7071834f04a489f392c72e5807ff5.png_pic_center]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/15/af8c9af9345d46e8b15afc532d846e41.png
[d8e0ac1d35a94da79da7fa6c4270f78f.png_pic_center]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/15/a74ccfd907f6410abeab752fbfe2977c.png
[3c7fb6a33a214a56a698ac868babe082.png_pic_center]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/15/8b9cdce5f79a462ba7b1ed15bc53ad53.png