文章目录

一、原子性高频问题
- 1.1 Java中如何实现线程安全?
- 1.2 CAS底层实现
- 1.3 CAS的常见问题
- 1.4 四种引用类型 + ThreadLocal的问题？
二、可见性高频问题
- 2.1 Java的内存模型
- 2.2 保证可见性的方式
- 2.3 volatile修饰引用数据类型
- 2.4 有了MESI协议，为啥还有volatile？
- 2.5 volatile的可见性底层实现
三、有序性高频问题
- 3.1 什么是有序性问题
- 3.2 volatile的有序性底层实现
四、synchronized高频问题
- 4.1 synchronized锁升级的过程?
- 4.2 synchronized锁粗化&锁消除？
- 4.3 synchronized实现互斥性的原理？
- 4.4 wait为什么是Object下的方法？

一、原子性高频问题

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

线程安全问题：多线程操作共享数据出现的问题。

实现线程安全方式：

悲观锁：synchronized，lock（AQS）
乐观锁：CAS

可以根据业务情况，选择ThreadLocal，让每个线程玩自己的数据。

1.2 CAS底层实现

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

CAS在Java层面最多就能看到native方法，可以去看Unsafe类中提供的CAS操作

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

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

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

cmpxchg源码：https://hg.openjdk.java.net/jdk8u/jdk8u/hotspot/file/69087d08d473/src/os_cpu/linux_x86/vm/atomic_linux_x86.inline.hpp

cmpxchg ，是汇编的指令，CPU硬件底层就支持 比较和交换 （cmpxchg），cmpxchg并不保证原子性的，如果是多核的操作系统，需要追加一个lock指令。

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

1.3 CAS的常见问题

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

比如说一个线程one从内存位置V中取出A，这时候另一个线程two也从内存中取出A，并且two进行了一些操作变成了B，然后two又将V位置的数据变成A，这时候线程one进行CAS操作发现内存中仍然是A，然后one操作成功。

解决方案很简单，Java端已经提供了，JUC下提供的AtomicStampedReference就可以实现。修改value的同时，指定好版本号，一旦版本号和数据的版本号不一致就执行失败。
自旋次数过多问题：自旋次数过多，会额外的占用大量的CPU资源！浪费资源。

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

1.4 四种引用类型 + ThreadLocal的问题？

ThreadLocal的问题：见Java基础面试题——IO和多线程专题

四种引用类型：

强引用：User xx = new User(); xx就是强引用，只要引用还在，GC就不会回收！
软引用：用一个SofeReference引用的对象，就是软引用，如果内存空间不足，才会回收只有软引用指向对象。 一般用于做缓存。
```
SoftwareReference xx = new SoftwareReference (new User);

User user = xx.get();
```
弱引用：WeakReference引用的对象，一般就是弱引用，只要执行GC，就会回收只有弱引用指向的对象。可以解决内存泄漏的问题 ，看ThreadLocal即可
虚引用：PhantomReference引用的对象，就是虚引用，拿不到虚引用指向的对象，一般监听GC回收阶段，或者是回收堆外内存时使用。

二、可见性高频问题

2.1 Java的内存模型

在处理指令时，CPU会拉取数据，优先级是从L1（线程独享）到L2（内核独享）到L3（多核共享），如果都没有，需要去主内存中拉取，JMM就是在CPU和主内存之间，来协调，保证可见、有序性等操作。

Java Memory Model
、

2.2 保证可见性的方式

啥是可见性： 可见性是指线程间的，对变量的变化是否可见。

Java层面中，保证可见性的方式有很多：

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

2.3 volatile修饰引用数据类型

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

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

MESI是CPU缓存一致性的协议，大多数的CPU厂商都根据MESI去实现了缓存一致性的效果。

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

2.5 volatile的可见性底层实现

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

三、有序性高频问题

3.1 什么是有序性问题

在Java编译.java为.class时，会基于JIT做优化，将指令的顺序做调整，从而提升执行效率。在CPU层面，也会对一些执行进行重新排序，从而提升执行效率。这种指令的调整，在一些特殊的操作上，会导致出现问题。

单例模式中的懒汉机制中，就存在一个这样的问题。懒汉为了保证线程安全，一般会采用DCL的方式。

3.2 volatile的有序性底层实现

被volatile修饰的属性，在编译时，会在前后追加 内存屏障 ，这个内存屏障是JDK规定的，目的是保证volatile修饰的属性不会出现指令重排的问题。

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

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

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

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

volatile在JMM层面，保证JIT不重排可以理解，但是，CPU怎么实现的,
查看这个文档：https://gee.cs.oswego.edu/dl/jmm/cookbook.html

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

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

四、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中，排队，并挂起线程，等待被唤醒。

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

wait方法是在持有sync锁的时候释放锁资源。
sync锁的是对象也就是Object。
所以wait自然是Object下的方法。

Java并发编程面试题——线程安全（原子性、可见性、有序性）