Java内存模型(JMM)

Java 内存模型（Java Memory Model，JMM）是个抽象的概念，负责 Java 并发中每个线程工作内存和共享主存之间的交互。JMM 很重要，也是后端程序员面试的重点。

Java 内存模型（Java Memory Model，JMM）是个抽象的概念，负责 Java 并发中每个线程工作内存和共享主存之间的交互。

JMM 定义了线程与主存之间的抽象关系：

线程间通信必须经过主存：① 线程 A 将本地内存 A 中更新过的共享变量刷新到主存中；② 线程 B 到主存中去读取线程 A 之前更新过的共享变量。

说到 JMM 正好复习一下跟它很像的 Java 运行时内存区域

Java 运行时内存区域描述的是在 JVM 运行时，如何具体地将内存划分为不同的区域：

JMM 意在解决 Java 多线程并发编程中主内存和工作内存之间如何安全执行操作的问题：

JMM 的指令重排

计算机在执行程序时为了性能，编译器和处理器往往会对指令进行重排序：

1 2	a = b + c; d = e - f ;

加载完 b 和 c，可以一起把 e 和 f 都加载了，这样再去执行两个 add 操作就减少了停顿，而且对程序（串行）是无影响的。也就是说，重排序可以保证程序在串行条件下语义一致，但无法保证在多线程条件下的语义也一致。

指令重排序有三类:

编译器优化重排

处理器执行并行重排

内存系统重排

JMM 和顺序一致性模型

如果程序是正确同步的（不包含数据竞争），程序的执行将具备顺序一致性。即程序的执行结果和在顺序一致性模型（理想化的参考模型）中的执行结果相同。

正确同步：使用volatile、final、synchronized等关键字实现的正确流程下的同步。

顺序一致性模型的两大特性：

为了解释上述两大特性（假设正确使用了同步）A 线程的 3 个操作执行后释放锁，B 线程获取同一个锁。那么在顺序一致性模型中的执行效果如下所示：

正确使用同步

就算没有正确使用同步，操作的执行整体上无序，但是对于每个线程来说都按照了程序的执行顺序，且每个线程都只能看到如下的这个执行顺序（操作立刻对所有线程可见）：

不正确使用同步

但是 JMM 中没有顺序一致性的保证。

在 JMM 中，比如当前线程 A 把写过的数据缓存在本地内存中，在没有刷新到主存之前线程 B 是对该更改不可见的，所以线程 A 和线程 B 看到的执行顺序是不同的。

JMM 中处在临界区内的代码可以发生重排序而对外部线程不可见，也就是说在不改变程序执行结果（单线程程序和正确同步了的多线程程序）的前提下提高了执行效率，为编译器和处理器的优化打开了方便。

对于未同步的线程：

未同步多线程的最小安全性

JMM 提供了** happens-before 规则，保证了强内存可见性**。

可见性：当多个线程访问同一个变量时，一个线程修改了这个变量值，另一个线程能够立刻看到修改值。

也就是说，

符合 happens-before 规则，限定了操作 A 和操作 B 的理论执行顺序，就意味着内存可见性的保证。
在符合 happens-before 规则的前提下，A 和 B 可能会被 JMM 允许重排序，也可能不被允许，这取决于是否会改变程序的执行结果。

常见的符合 happens-before 关系：

同一个线程中的每一个操作
对同一个锁的解锁操作总是 happens-before 对该锁的加锁
对 volatile 修饰的变量的写总是 happens-before 对该变量的读
A -> B 且 B -> C，总是有传递性 A -> C
start 规则
join 规则

比如对上述单线程中的 A、B、C 操作，JMM 对两类重排序有不同的策略：

不会改变程序执行结果的重排序：A -> B，JMM 对编译器和处理器不做要求，允许这种重排序；
会改变程序执行结果的重排序：A -> C，JMM 要求编译器和处理器禁止这种重排序。

文章作者: KiCheng

文章链接: https://kicheng.github.io/2024/09/20/Java%E5%86%85%E5%AD%98%E6%A8%A1%E5%9E%8B/

并发编程 java

相关推荐

2024-09-25

通知等待Condition

ConditonObject 是 Condition 接口的实现类，用来做线程同步的通知等待，最重要的是它维护了一个单向的等待队列，要明确它和 AQS 队列的关系。此外还介绍了 LockSupport 类，Condition 的 await 底层就是通过 LockSupport 实现的。等待通知 ConditionCondition 的等待队列是一个不带头节点的链式队列，而 AQS 的同步队列是带头节点的。多个 Condition 对象的多个等待队列有什么用？同步队列和等待队列的关系：调用 Condition 的 await 方法，会使当前持有锁的线程进入同步队列，并释放锁，线程进入等待状态。相当于将同步队列的头节点（占用线程）移动到等待队列的尾部。调用 Condition 的 signal 方法，唤醒该线程，相当于将等待队列的头节点移动到同步队列的尾部。 Condition 是个接口，它的实现类是 ConditionObject，是 AQS 的子类。 Condition 的 await 方法当前线程调用 Condtion.await()...

2024-09-23

volatile和synchronized关键字

之所以把 volatile 和 synchronized 放在一起是因为二者都是关键字，而 synchronized 相比 volatile 除了提供内存可见性外还提供了锁的作用，也就是在同一时刻只允许一个线程访问共享资源，保证了线程安全性。 volatile关键字当使用 volatile 关键字修饰一个变量，Java 内存模型会插入一个内存屏障，确保执行到 volatile 变量的时候前面的语句全都执行完，后面的语句全都没有执行，且前面的语句对 volatile 变量及后面的语句是可见的。 volatile 可以保证可见性，但不保证原子性：当写一个 volatile 变量时，JMM 会把该线程在本地内存中的变量强制刷新到主内存中去；这个写操作会导致其他线程中的 volatile 变量缓存无效（修改对其他线程立即可见）。保证可见性： 1234567891011121314class ReorderExample { int a = 0; boolean volatile flag = false; public void writer()...

2024-09-25

线程池

线程池的核心思想就是实现线程的复用，避免线程反复创建和销毁带来的性能开销。这里主要介绍了基本的 ThreadPoolExecutor 以及用于定时循环任务的 ScheduledThreadPoolExecutor ，而且线程池是面试的重点。 ThreadPoolExecutor线程池的核心思想就是实现线程的复用，避免线程反复创建和销毁带来的性能开销。 Java 通过 ThreadPoolExecutor 来创建线程池，其核心参数如下：线程池 execute 工作 1public void execute(Runnable command){} 线程在线程池内部被封装成内部类 Worker 创建的对象。在线程池的 execute 方法中是通过 addWorker 方法来创建线程并执行任务的，Worker 会将线程和任务一同封装到 Worker 对象中，在通过 runWorker 方法来执行任务。在 runWorker 方法内部，通过 while 循环保证执行完任务的线程不被销毁，而是复用不断地 getTask...

2024-09-24

可重入锁 ReentrantLock、ReentrantReadWriteLock

可重入锁支持重入性，表示能够对共享资源重复加锁，即当前线程获取该锁后再次获取不会被阻塞，主要介绍了 ReentrantLock、ReentrantReadWriteLock 两种。 ReentrantLock支持重入性，表示能够对共享资源重复加锁，即当前线程获取该锁后再次获取不会被阻塞。 ReentrantLock 是通过抽象队列同步器 AQS 在 API 程序级别实现的，其内部类 Sync 继承了 AQS 抽象类，是 Lock 接口的默认实现。源码在线程获取锁的时候，如果已经获取锁的线程是当前线程的话则直接再次获取成功； 12345678910111213141516171819202122// 以内部类 Sync 的 nonfairTryAcquire 方法为例final boolean nonfairTryAcquire(int acquires) { final Thread current = Thread.currentThread(); int c = getState(); // 1....