并发编程常见面试题汇总（一）

矫情吗；* 2023-09-24 19:03 131阅读 0赞

## 一、原子性问题： ##

### 1.1 Java中如何实现线程安全? ###

不安全的原因：多线程操作共享数据出现的问题。  
解决方式一：锁

*  悲观锁：synchronized，lock
 *  乐观锁：CAS

解决方式二：  
可以根据业务情况，选择ThreadLocal，让每个线程玩自己的数据。

### 1.2 CAS底层实现 ###

Java的角度，比较和交换：

*  先比较一下值是否与预期值一致，如果一致，交换，返回true
 *  先比较一下值是否与预期值一致，如果不一致，不交换，返回false

Unsafe类中提供的CAS操作

四个参数：哪个对象，哪个属性的内存偏移量，oldValue，newValue

![image.png][]

native是直接调用本地依赖库C++中的方法。

https://hg.openjdk.java.net/jdk8u/jdk8u/hotspot/file/69087d08d473/src/share/vm/prims/unsafe.cpp

![image.png][image.png 1]

https://hg.openjdk.java.net/jdk8u/jdk8u/hotspot/file/69087d08d473/src/os\_cpu/linux\_x86/vm/atomic\_linux\_x86.inline.hpp

在CAS底层，**如果是多核的操作系统，需要追加一个lock指令**

单核不需要加，因为**cmpxchg**是一行指令，不能再被拆分了

![image.png][image.png 2]

看到cmpxchg ，是汇编的指令，CPU硬件底层就支持 **比较和交换** （cmpxchg），cmpxchg并不保证原子性的。（cmpxchg的操作是不能再拆分的指令）

所以才会出现判断CPU是否是多核，如果是多核就追加lock指令。

lock指令：是CPU层面的锁，一般锁的粒度就是 **缓存行** 级别的锁，当然也有 **总线锁** ，但是成本太高，CPU会根据情况选择。

java查看硬件配置的方式

Runtime.getRuntime().availableProcessors()

### 1.3 CAS的常见问题 ###

**ABA：** ABA不一定是问题！因为一些只存在 ++，–的这种操作，即便出现ABA问题，也不影响结果！

线程A：期望将value从A1 - B2

线程B：期望将value从B2 - A3

线程C：期望将value从A1 - C4

按照原子性来说，无法保证线程安全。

解决：JUC下提供的AtomicStampedReference就可以实现。

![image.png][image.png 3]  
总结：在修改value的同时，指定好版本号。

**自旋次数过多：**

自旋次数过多，会额外的占用大量的CPU资源！浪费资源。

解决：

*  synchronized方向：从CAS几次失败后，就将线程挂起（WAITING），避免占用CPU过多的资源！
 *  LongAdder方向：这里是基于类似 **分段锁** 的形式去解决（要看业务，有限制的），传统的AtmoicLong是针对内存中唯一的一个值去++，LongAdder在内存中搞了好多个值，多个线程去加不同的值，当需要结果时，将所有值累加，返回。

**只针对一个属性保证原子性：** 处理方案，AQS。

ReentrantLock基于AQS实现，AQS基于CAS实现核心功能。

### 1.4 四种引用类型 ###

四种引用类型：

*  强引用：User xx = new User(); xx就是强引用，只要引用还在，GC就不会回收！
 *  软引用：用一个SofeReference引用的对象，就是软引用，**如果内存空间不足**，才会回收**只有软引用指向对象**。 **一般用于做缓存**。
    
        SoftwareReference xx = new SoftwareReference (new User);
        
        // user 不能被回收，它是强引用
        User user = xx.get();
 *  弱引用：WeakReference引用的对象，一般就是弱引用，**只要执行GC**，就会回收只有弱引用指向的对象。**可以解决内存泄漏的问题** ，看ThreadLocal即可
 *  虚引用：PhantomReference引用的对象，就是虚引用，拿不到虚引用指向的对象，**一般监听GC回收阶段，或者是回收堆外内存时使用。**

### 1.5 ThreadLocal的原理 ###

ThreadLocal可以理解为线程本地变量，他会在每个线程都创建一个副本，那么在线程之间访问内部副本变量就行了，做到了线程之间互相隔离，相比于synchronized的做法是用空间来换时间。

ThreadLocal有一个静态内部类ThreadLocalMap，ThreadLocalMap又包含了一个Entry数组，Entry本身是一个弱引用，他的key是指向ThreadLocal的弱引用，Entry具备了保存key value键值对的能力。

弱引用的目的是为了防止内存泄露，如果是强引用那么ThreadLocal对象除非线程结束否则始终无法被回收，弱引用则会在下一次GC的时候被回收。

但是这样还是会存在内存泄露的问题，假如key和ThreadLocal对象被回收之后，entry中就存在key为null，但是value有值的entry对象，但是永远没办法被访问到，同样除非线程结束运行。

但是只要ThreadLocal使用恰当，在使用完之后调用remove方法删除Entry对象，实际上是不会出现这个问题的。

![image.png][image.png 4]

## 二、可见性高频问题： ##

### 2.1 Java的内存模型 ###

在处理指令时，CPU会拉取数据，优先级是从L1到L2到L3，如果都没有，需要去主内存中拉取。

其中JMM（Java Memory Model）就是在 CPU 和 主内存 之间来协调，保证可见、有序性等操作。

![image.png][image.png 5]

![image.png][image.png 6]

*  CPU核心，就是CPU存储核心——寄存器，它是CPU内部的存储部件，与内存空间没有关系，设置寄存器的原因是为了减少CPU与内存交换数据的次数，以提高计算机的工作速度。
 *  缓存是CPU的缓存，CPU的缓存分为L1（线程独享），L2（内核独享），L3（多核共享）
 *  缓存查询效率：L1 > L2 > L3
 *  JMM就是Java内存模型的核心，可见性，有序性都基于这实现。
 *  主内存JVM，就是堆内存。

### 2.2 保证可见性的方式 ###

可见性解读： **可见性是指线程间的，对变量的变化是否可见**

保证可见性的方式：

*  **volatile**，用volatile基本数据类型，可以保证每次CPU去操作数据时，都直接去主内存进行读写。
 *  synchronized，可以保证在获取锁之后，前面操作的数据是可见的。
 *  lock（CAS-volatile），也可以保证CAS或者操作volatile的变量之后，前面操作的数据是可见的。
 *  final，是常量没法动~~

### 2.3 volatile修饰引用数据类型 ###

volatile修饰引用数据类型，**只能保证引用数据类型的地址是可见的，不保证内部属性可见**。

### 2.4 有了MESI协议，为啥还有volatile？ ###

MESI协议：是从CPU硬件层面上的一致性。

volatile：是Java中JMM层面的一致性。

MESI是CPU缓存一致性的协议，他有一套固定的机制，无论你是否声明了volatile，他都会基于这个机制来保证缓存的一致性（可见性）。如果没有MESI协议，volatile也会存在一些问题，不过也有其他的处理方案（总线锁，时间成本太高了，如果锁了总线，就一个CPU核心在干活）。

MESI是协议，是规划，是interface，他需要CPU厂商实现。

既然CPU有MESI了，为啥还要volatile，那自然是MESI协议有问题。MESI保证了多核CPU的独占cache之间的可见性，但是CPU不是说必须直接将寄存器中的数据写入到L1，因为**在大多是×86架构的CPU中，寄存器和L1之间有一个store buffer，寄存器值可能落到了store buffer，没落到L1中，就会导致缓存不一致**。而且除了×86架构的CPU，在arm和power的CPU中，还有load buffer，invalid queue都会或多或少影响缓存一致性！

\*\*总结：\*\*MESI协议和volatile不冲突，因为MESI是CPU层面的，而CPU厂商很多实现不一样，而且CPU的架构中的一些细节也会有影响，比如Store Buffer会影响寄存器写入L1缓存，导致缓存不一致。volatile的底层生成的是汇编的lock指令，这个指令会要求强行写入主内存，并且可以忽略Store Buffer这种缓存从而达到可见性的目的，而且会利用MESI协议，让其他缓存行失效。

### 2.5 volatile的可见性底层实现 ###

volatile的底层生成的是汇编的lock指令，这个指令会要求强行写入主内存，并且可以忽略Store Buffer这种缓存从而达到可见性的目的，而且会利用MESI协议，让其他缓存行失效。

### 三、有序性高频问题： ###

#### 3.1 什么是有序性问题 ####

单例模式中的懒汉机制中，就存在一个这样的问题。

懒汉为了保证线程安全，一般会采用DCL的方式。

但是单单用DCL，依然会有几率出现问题。

线程可能会拿到初始化一半的对象去操作，极有可能出现NullPointException。

（初始化对象三部，开辟空间，初始化内部属性，指针指向引用）

**在Java编译.java为.class时，会基于JIT做优化，将指令的顺序做调整，从而提升执行效率。**

**在CPU层面，也会对一些执行进行重新排序，从而提升执行效率。**

**这种指令的调整，在一些特殊的操作上，会导致出现问题。**

#### 3.2 volatile的有序性底层实现 ####

被volatile修饰的属性，在编译时，会在前后追加 **内存屏障** 。

SS：屏障前的读写操作，必须全部完成，再执行后续操作

SL：屏障前的写操作，必须全部完成，再执行后续读操作

LL：屏障前的读操作，必须全部完成，再执行后续读操作

LS：屏障前的读操作，必须全部完成，再执行后续写操作

![image.png][image.png 7]

这个内存屏障是JDK规定的，目的是保证volatile修饰的属性不会出现指令重排的问题。

volatile在JMM层面，保证JIT不重排可以理解，但是，CPU怎么实现的。

查看这个文档：https://gee.cs.oswego.edu/dl/jmm/cookbook.html

![image.png][image.png 8]

不同的CPU对内存屏障都有一定的支持，比如×86架构，内部自己已经实现了LS，LL，SS，只针对SL做了支持。

去openJDK再次查看，mfence是如何支持的。其实在底层还是mfence内部的lock指定，来解决指令重排问题。

![image.png][image.png 9]

### 四、synchronized高频问题： ###

#### 4.1 synchronized锁升级的过程? ####

**锁就是对象，随便哪一个都可以，Java中所有对象都是锁。**

无锁(匿名偏向)、偏向锁、轻量级锁、重量级锁

**无锁(匿名偏向)**： 一般情况下，new出来的一个对象，是无锁状态。因为偏向锁有延迟，在启动JVM的4s中，不存在偏向锁，但是如果关闭了偏向锁延迟的设置，new出来的对象，就是匿名偏向。

**偏向锁**： 当某一个线程来获取这个锁资源时，此时，就会变为偏向锁，偏向锁存储线程的ID

当偏向锁升级时，会触发偏向锁撤销，偏向锁撤销需要等到一个安全点，比如GC的时候，偏向锁撤销的成本太高，所以默认开始时，会做偏向锁延迟。

安全点：

*  GC
 *  方法返回之前
 *  调用某个方法之后
 *  甩异常的位置
 *  循环的末尾

**轻量级锁：** 当在出现了多个线程的竞争，就要升级为轻量级锁（有可能直接从无锁变为轻量级锁，也有可能从偏向锁升级为轻量级锁），轻量级锁的效果就是基于CAS尝试获取锁资源，这里会用到自适应自旋锁，根据上次CAS成功与否，决定这次自旋多少次。

**重量级锁：** 如果到了重量级锁，那就没啥说的了，如果有线程持有锁，其他竞争的，就挂起。

#### 4.2 synchronized锁粗化&锁消除？ ####

锁粗化（锁膨胀）：（JIT优化）

while(){
       sync(){
          // 多次的获取和释放，成本太高，优化为下面这种
       }
    }
    //----
    sync(){
       while(){
           //  优化成这样
       }
    }

锁消除：在一个sync中，没有任何共享资源，也不存在锁竞争的情况，JIT编译时，就直接将锁的指令优化掉。

#### 4.3 synchronized实现互斥性的原理？ ####

偏向锁：查看对象头中的MarkWord里的线程ID，是否是当前线程，如果不是，就CAS尝试改，如果是，就拿到了锁资源。

轻量级锁：查看对象头中的MarkWord里的Lock Record指针指向的是否是当前线程的虚拟机栈，如果是，拿锁执行业务，如果不是CAS，尝试修改，修改他几次，不成，再升级到重量级锁。

重量级锁：查看对象头中的MarkWord里的指向的ObjectMonitor，查看owner是否是当前线程，如果不是，扔到ObjectMonitor里的EntryList中，排队，并挂起线程，等待被唤醒。

![image.png][image.png 10]

#### 4.4 wait为什么是Object下的方法？ ####

执行wait方法需要持有sync锁。

sync锁可以是任意对象。

同时执行wait方法是在持有sync锁的时候，释放锁资源。

其次wait方法需要去操作ObjectMonitor，而操作ObjectMonitor就必须要在持有锁资源的前提的才能操作，将当前线程扔到WaitSet等待池中。

同理，notify方法需要将WaitSet等待池中线程扔到EntryList，如果不拥有ObjectMonitor，怎么操作！

类锁就是基于类.class作为类锁

对象锁，就是new 一个对象作为对象锁

[image.png]: https://img-blog.csdnimg.cn/img_convert/617630af319fce515c0a544a81753f31.png
[image.png 1]: https://img-blog.csdnimg.cn/img_convert/86b49bd654e57cda1dd9739e8578a4b8.png
[image.png 2]: https://img-blog.csdnimg.cn/img_convert/9f4068e5340a64e695c6ca51d09c225d.png
[image.png 3]: https://img-blog.csdnimg.cn/img_convert/1075c216e8ea7bb6232344db692e2489.png
[image.png 4]: https://img-blog.csdnimg.cn/img_convert/3373814aa061554fe3459515a4f79bc1.png
[image.png 5]: https://img-blog.csdnimg.cn/img_convert/f54a2578fd0a713d1e6676b3d1c21174.png
[image.png 6]: https://img-blog.csdnimg.cn/img_convert/7c5dd8b5a311fcef3a0fa8f002b6be20.png
[image.png 7]: https://img-blog.csdnimg.cn/img_convert/de855ced01e076eff7234f6d2aa78507.png
[image.png 8]: https://img-blog.csdnimg.cn/img_convert/b3e05c16bef3877b00db18ef273e9ba6.png
[image.png 9]: https://img-blog.csdnimg.cn/img_convert/67228dca631489433e1251fb19670662.png
[image.png 10]: https://img-blog.csdnimg.cn/img_convert/58902a24c5ed3711c0b9168fd2726e26.png