并发编程：并发核心问题是什么？

目录

前言

1.分工

2.同步

3.互斥

二、并发编程bug源头

1.缓存导致的可见性问题

2.线程切换带来的原子性问题

3.编译优化带来的有序性问题

三、Java内存模型

内存交互操作

四、可见性问题深入分析

JMM的内存可见性保证

volatile的内存语义

volatile可见性实现原理

五、有序性问题深入分析

指令重排序

JMM内存屏障插入策略

JVM层面的内存屏障

硬件层面的内存屏障

---

前言

首先，得理解并发的重要性。为什么需要并发？其实就是为了解决「性能」问题。

然后，并发处理的是「任务」，就是：对任务的抽象、拆解和分工执行。Java使用的是多线程模型，对应到具体的代码：Thread、Runnable、Task，执行任务：Executors。那么有了多线程势必会有线程安全性问题，因为多线程的访问，数据会存在不一致的问题。

在然后，大的任务被拆解为小的任务，小任务各自执行，这些任务之间必然存在依赖关系，那么就需要协调，那要如何协调呢？「锁」就是非常直接的方式（Monitor原理），如果只使用锁的话，协调的费力度太高了，就出现了一些并发工具类：闭锁、屏障、队列以及其它的一些并发容器等；好了，协调的工作不难处理了。可是协调也会有出错的时候，这就有了死锁、活锁等问题，

到此，如果一遇到并发问题，就直接上锁，倒也没有什么大问题，可是追求性能是人类的天性。计算机大师就在思考，能不不加锁也能实现并发，还不容易出错，于是就有了：CAS、copy-on-write等技术思想，这就是实现了「无锁」并发。

最后，如果以上都需要每一个程序员去弄，然后自己保证正确性，那程序员真累死了。于是，计算机大师又开始思考，能不能抽象出统一「模型」，可能这就有了类似于「Java内存模型」这样的东西。

一、并发编程核心问题

并发编程问题其实可以拆分为三个核心问题：分工、同步和互斥。

1.分工

所谓分工其实就是任务的分解。就类似于一个项目，领导要拆分任务，安排合适的人员去完成。

在Java 并发包中的 Executor、Fork/Join、Future等本质上也是一种分工。并发设计模式中有一部分也是与分工相关的，例如：生产者-消费者、Thread-Per-Message、Worker Thread 等模式。

2.同步

在并发编程领域里的同步，主要指的就是线程间的协作，本质上和现实生活中的协作没区别，不过是一个线程执行完了一个任务，如何通知执行后续任务的线程开工而已。

工作中遇到的线程协作问题，基本上都可以描述为这样的一个问题：当某个条件不满足时，线程需要等待，当某个条件满足时，线程需要被唤醒执行。

3.互斥

所谓互斥，指的是同一时刻，只允许一个线程访问共享变量。

实现互斥的核心技术就是锁，Java 语言里 synchronized、SDK 里的各种 Lock 都能解决互斥问题。

二、并发编程bug源头

随着计算机硬件不断的迭代，CPU、内存、I/O 设备一直存在着一个核心矛盾，就是他们三者的速度差异。CPU最快，内存次之，I/O最慢。

为了合理利用 CPU 的高性能，平衡这三者的速度差异，计算机体系结构、操作系统、编译程序都做出了贡献，主要体现为：

1. CPU 增加了缓存，以均衡与内存的速度差异；
2. 操作系统增加了进程、线程，以分时复用 CPU，进而均衡 CPU 与 I/O 设备的速度差异；
3. 编译程序优化指令执行次序，使得缓存能够得到更加合理地利用。

这里可以总结出来的三点就是：

1.缓存导致的可见性问题

什么是可见性？当一个线程修改了共享变量的值，其他线程能够看到修改的值。

Java 内存模型是通过在变量修改后将新值同步回主内存，在变量读取前从主内存刷新变量值这种依赖主内存作为传递媒介的方法来实现可见性的。

如何保证可见性？

• 通过 volatile 关键字保证可见性。
• 通过 内存屏障保证可见性。
• 通过 synchronized 关键字保证可见性。
• 通过 Lock保证可见性。
• 通过 final 关键字保证可见性

2.线程切换带来的原子性问题

什么是原子性？一个或多个操作，要么全部执行且在执行过程中不被任何因素打断，要么全部不执行。

在 Java 中，对基本数据类型的变量的读取和赋值操作是原子性操作（64位处理器）。不采取任何的原子性保障措施的自增操作并不是原子性的。

如何保证原子性？

• 通过 synchronized 关键字保证原子性。
• 通过 Lock保证原子性。
• 通过 CAS保证原子性。

3.编译优化带来的有序性问题

什么是有序性？即程序执行的顺序按照代码的先后顺序执行。

JVM 存在指令重排，所以存在有序性问题。

如何保证有序性问题？

• 通过 volatile 关键字保证有序性。
• 通过 内存屏障保证有序性。
• 通过 synchronized关键字保证有序性。
• 通过 Lock保证有序性。

三、Java内存模型

导致可见性的原因是缓存，导致有序性的原因是编译优化，那解决可见性、有序性最直接的办法就是禁用缓存和编译优化，但是这样问题虽然解决了，我们程序的性能可就堪忧了。

合理的方案应该是按需禁用缓存以及编译优化。

Java 内存模型是个很复杂的规范，可以从不同的视角来解读，站在我们这些程序员的视角，本质上可以理解为，Java 内存模型规范了 JVM 如何提供按需禁用缓存和编译优化的方法。

Java虚拟机规范中定义了Java内存模型（Java Memory Model，JMM），用于屏蔽掉各种硬件和操作系统的内存访问差异，以实现让Java程序在各种平台下都能达到一致的并发效果，JMM规范了Java虚拟机与计算机内存是如何协同工作的：规定了一个线程如何和何时可以看到由其他线程修改过后的共享变量的值，以及在必须时如何同步的访问共享变量。

内存交互操作

关于主内存与工作内存之间的具体交互协议，即一个变量如何从主内存拷贝到工作内存、如何从工作内存同步到主内存之间的实现细节，Java内存模型定义了以下八种操作来完成：

• lock（锁定）：作用于主内存的变量，把一个变量标识为一条线程独占状态。
• unlock（解锁）：作用于主内存变量，把一个处于锁定状态的变量释放出来，释放后的变量才可以被其他线程锁定。
• read（读取）：作用于主内存变量，把一个变量值从主内存传输到线程的工作内存中，以便随后的load动作使用
• load（载入）：作用于工作内存的变量，它把read操作从主内存中得到的变量值放入工作内存的变量副本中。
• use（使用）：作用于工作内存的变量，把工作内存中的一个变量值传递给执行引擎，每当虚拟机遇到一个需要使用变量的值的字节码指令时将会执行这个操作。
• assign（赋值）：作用于工作内存的变量，它把一个从执行引擎接收到的值赋值给工作内存的变量，每当虚拟机遇到一个给变量赋值的字节码指令时执行这个操作。
• store（存储）：作用于工作内存的变量，把工作内存中的一个变量的值传送到主内存中，以便随后的write的操作。
• write（写入）：作用于主内存的变量，它把store操作从工作内存中一个变量的值传送到主内存的变量中。

四、可见性问题深入分析

JMM的内存可见性保证

按程序类型，Java程序的内存可见性可以分为3类：

• 单线程程序：单线程程序不会出现内存可见性问题。编译器、runtime和处理器会共同确保单线程程序的执行结果与该程序在顺序一致性模型中的执行结果相同。
• 正确同步的多线程程序：正确同步的多线程程序的执行将具有顺序一致性（程序的执行结果与该程序在顺序一致性内存模型中的执行结果相同）。这是JMM关注的重点，JMM通过限制编译器和处理器的重排序来为程序员提供内存可见性保证。
• 未同步/未正确同步的多线程程序：JMM为它们提供了最小安全性保障：线程执行时读取到的值，要么是之前某个线程写入的值，要么是默认值未同步程序在JMM中的执行时，整体上是无序的，其执行结果无法预知。 JMM不保证未同步程序的执行结果与该程序在顺序一致性模型中的执行结果一致。

volatile的内存语义

volatile的特性：

• 可见性：对一个volatile变量的读，总是能看到（任意线程）对这个volatile变量最后的写入。
• 原子性：对任意单个volatile变量的读/写具有原子性，但类似于volatile++这种复合操作不具有原子性（基于这点，我们通过会认为volatile不具备原子性）。volatile仅仅保证对单个volatile变量的读/写具有原子性，而锁的互斥执行的特性可以确保对整个临界区代码的执行具有原子性。
• 有序性：对volatile修饰的变量的读写操作前后加上各种特定的内存屏障来禁止指令重排序来保障有序性。

volatile写-读的内存语义

• 当写一个volatile变量时，JMM会把该线程对应的本地内存中的共享变量值刷新到主内存。
• 当读一个volatile变量时，JMM会把该线程对应的本地内存置为无效，线程接下来将从主内存中读取共享变量。

volatile可见性实现原理

JMM内存交互层面实现

        volatile修饰的变量的read、load、use操作和assign、store、write必须是连续的，即修改后必须立即同步回主内存，使用时必须从主内存刷新，由此保证volatile变量操作对多线程的可见性。

硬件层面实现

        通过lock前缀指令，会锁定变量缓存行区域并写回主内存，这个操作称为“缓存锁定”，缓存一致性机制会阻止同时修改被两个以上处理器缓存的内存区域数据。一个处理器的缓存回写到内存会导致其他处理器的缓存无效。

五、有序性问题深入分析

指令重排序

Java语言规范规定JVM线程内部维持顺序化语义。即只要程序的最终结果与它顺序化情况的结果相等，那么指令的执行顺序可以与代码顺序不一致，此过程叫指令的重排序。

指令重排序的意义：JVM能根据处理器特性（CPU多级缓存系统、多核处理器等）适当的对机器指令进行重排序，使机器指令能更符合CPU的执行特性，最大限度的发挥机器性能。

在编译器与CPU处理器中都能执行指令重排优化操作

volatile禁止重排序场景：表格中NO表示不能重排序，YES表示可以重排序。第一列表示第一个操作，第一行表示第二个操作。

第一个操作 \ 第二个操作	普通读/写	volatile读	volatile写
普通读/写	YES	YES	NO
volatile读	NO	NO	NO
volatile写	YES	NO	NO

volatile禁止重排序场景：

1.  第二个操作是volatile写，不管第一个操作是什么都不会重排序

2.  第一个操作是volatile读，不管第二个操作是什么都不会重排序

3.  第一个操作是volatile写，第二个操作是volatile读，也不会发生重排序

JMM内存屏障插入策略

1. 在每个volatile写操作的前面插入一个StoreStore屏障

2. 在每个volatile写操作的后面插入一个StoreLoad屏障

3. 在每个volatile读操作的后面插入一个LoadLoad屏障

4. 在每个volatile读操作的后面插入一个LoadStore屏障

JVM层面的内存屏障

LoadLoad屏障：（指令Load1; LoadLoad; Load2），在Load2及后续读取操作要读取的数据被访问前，保证Load1要读取的数据被读取完毕。

LoadStore屏障：（指令Load1; LoadStore; Store2），在Store2及后续写入操作被刷出前，保证Load1要读取的数据被读取完毕。

StoreStore屏障：（指令Store1; StoreStore; Store2），在Store2及后续写入操作执行前，保证Store1的写入操作对其它处理器可见。

StoreLoad屏障：（指令Store1; StoreLoad; Load2），在Load2及后续所有读取操作执行前，保证Store1的写入对所有处理器可见。它的开销是四种屏障中最大的。在大多数处理器的实现中，这个屏障是个万能屏障，兼具其它三种内存屏障的功能

由于x86只有store load可能会重排序，所以只有JSR的StoreLoad屏障对应它的mfence或lock前缀指令，其他屏障对应空操作

硬件层面的内存屏障

硬件层提供了一系列的内存屏障 memory barrier / memory fence(Intel的提法)来提供一致性的能力。拿X86平台来说，有几种主要的内存屏障：

1. lfence，是一种Load Barrier 读屏障

2. sfence, 是一种Store Barrier 写屏障

3. mfence, 是一种全能型的屏障，具备lfence和sfence的能力

4. Lock前缀，Lock不是一种内存屏障，但是它能完成类似内存屏障的功能。Lock会对CPU总线和高速缓存加锁，可以理解为CPU指令级的一种锁。它后面可以跟ADD, ADC, AND, BTC, BTR, BTS, CMPXCHG, CMPXCH8B, DEC, INC, NEG, NOT, OR, SBB, SUB, XOR, XADD, and XCHG等指令。

内存屏障有两个能力：

1. 阻止屏障两边的指令重排序
2. 刷新处理器缓存/冲刷处理器缓存

对Load Barrier来说，在读指令前插入读屏障，可以让高速缓存中的数据失效，重新从主内存加载数据；对Store Barrier来说，在写指令之后插入写屏障，能让写入缓存的最新数据写回到主内存。

Lock前缀实现了类似的能力，它先对总线和缓存加锁，然后执行后面的指令，最后释放锁后会把高速缓存中的数据刷新回主内存。在Lock锁住总线的时候，其他CPU的读写请求都会被阻塞，直到锁释放。

不同硬件实现内存屏障的方式不同，Java内存模型屏蔽了这种底层硬件平台的差异，由JVM来为不同的平台生成相应的机器码。