Ref: https://pdai.tech/md/java/thread/java-thread-x-theorty.html

1.并发问题根源

线程不安全指的是：如果多个线程对同一个共享数据进行访问而不采取同步操作的话，那么操作的结果是不一致的。
并发三要素：

  • 可见性：CPU 缓存引起
  • 原子性：分时复用引起
  • 有序性：重排序引起

    1.1 可见性

    可见性：一个线程对共享变量的修改，另外一个线程能够立刻看到。
    举个简单的例子，看下面这段代码： ```java // 线程1执行的代码 int i = 0; i = 10;

// 线程2执行的代码 j = i;

  1. 假若执行线程 1 的是 CPU1，执行线程 2 的是 CPU2。由上面的分析可知，当线程 1 执行 i =10 这句时，会先把 i 的初始值加载到 CPU1 的高速缓存中，然后赋值为 10，那么在 CPU1 的高速缓存当中 i 的值变为 10 了，却没有立即写入到主存当中。 
  3. 此时线程 2 执行 j = i，它会先去主存读取 i 的值并加载到 CPU2 的缓存当中，注意此时内存当中 i 的值还是 0，那么就会使得 j 的值为 0，而不是 10. 这就是可见性问题，线程 1 对变量 i 修改了之后，线程 2 没有立即看到线程 1 修改的值。
  4. <a name="TkHt6"></a>
  5. ### 1.2 原子性
  6. 原子性：即一个操作或者多个操作，要么全部执行并且执行的过程不会被任何因素打断，要么就都不执行。 
  8. 经典的转账问题：比如从账户 A 向账户 B 转 1000 元，那么必然包括 2 个操作：从账户 A 减去 1000 元，往账户 B 加上 1000 元。 <br />试想一下，如果这 2 个操作不具备原子性，会造成什么样的后果。假如从账户 A 减去 1000 元之后，操作突然中止。然后又从 B 取出了 500 元，取出 500 元之后，再执行往账户 B 加上 1000 元 的操作。这样就会导致账户 A 虽然减去了 1000 元，但是账户 B 没有收到这个转过来的 1000 元。 <br />所以这 2 个操作必须要具备原子性才能保证不出现一些意外的问题。
  9. <a name="e7BoH"></a>
  10. ### 1.3 有序性
  11. 有序性：即程序执行的顺序按照代码的先后顺序执行。<br />举个简单的例子，看下面这段代码：
  12. ```java
  13. int i = 0;              
  14. boolean flag = false;
  15. i = 1;                //语句1  
  16. flag = true;          //语句2

上面代码定义了一个 int 型变量，定义了一个 boolean 类型变量，然后分别对两个变量进行赋值操作。从代码顺序上看，语句 1 是在语句 2 前面的，那么 JVM 在真正执行这段代码的时候会保证语句 1 一定会在语句 2 前面执行吗？不一定，为什么呢？这里可能会发生指令重排序(Instruction reorder)。

在执行程序时为了提高性能，编译器和处理器常常会对指令做重排序。重排序分三种类型：

  • 编译器优化的重排序。编译器在不改变单线程程序语义的前提下，可以重新安排语句的执行顺序。
  • 指令级并行的重排序。现代处理器采用了指令级并行技术（Instruction-Level Parallelism， ILP）来将多条指令重叠执行。如果不存在数据依赖性，处理器可以改变语句对应机器指令的执行顺序。
  • 内存系统的重排序。由于处理器使用缓存和读 / 写缓冲区，这使得加载和存储操作看上去可能是在乱序执行。

从 java 源代码到最终实际执行的指令序列，会分别经历下面三种重排序：
image.png
上述的 1 属于编译器重排序，2 和 3 属于处理器重排序。这些重排序都可能会导致多线程程序出现内存可见性问题。

  • 对于编译器，JMM 的编译器重排序规则会禁止特定类型的编译器重排序（不是所有的编译器重排序都要禁止）。
  • 对于处理器重排序，JMM 的处理器重排序规则会要求 java 编译器在生成指令序列时，插入特定类型的内存屏障（memory barriers，intel 称之为 memory fence）指令，通过内存屏障指令来禁止特定类型的处理器重排序（不是所有的处理器重排序都要禁止）。

具体可以参看：Java 内存模型详解的重排序章节。

2.Java 解决并发问题

Java 内存模型是个很复杂的规范，强烈推荐你看后续（应该是网上能找到最好的材料之一了）：Java 内存模型详解。

  1. 理解的第一个维度：核心知识点

JMM 本质上可以理解为，Java 内存模型规范了 JVM 如何提供按需禁用缓存和编译优化的方法。具体来说，这些方法包括：

  • volatile、synchronized 和 final 三个关键字
  • Happens-Before 规则
  1. 理解的第二个维度：可见性，有序性，原子性

    2.1 原子性

    在 Java 中，对基本数据类型的变量的读取和赋值操作是原子性操作，即这些操作是不可被中断的，要么执行，要么不执行。 请分析以下哪些操作是原子性操作：
    x = 10;        // 语句1: 直接将数值10赋值给x，也就是说线程执行这个语句的会直接将数值10写入到工作内存中
y = x;         // 语句2: 包含2个操作，它先要去读取x的值，再将x的值写入工作内存，
            //       虽然读取x的值以及 将x的值写入工作内存 这2个操作都是原子性操作，但是合起来就不是原子性操作了。
x++;           // 语句3: x++包括3个操作：读取x的值，进行加1操作，写入新的值。
x = x + 1;     // 语句4: 同语句3
    上面 4 个语句只有语句 1 的操作具备原子性。
    也就是说，只有简单的读取、赋值（而且必须是将数字赋值给某个变量，变量之间的相互赋值不是原子操作）才是原子操作。

    从上面可以看出，Java 内存模型只保证了基本读取和赋值是原子性操作，如果要实现更大范围操作的原子性，可以通过 synchronized 和 Lock 来实现。由于 synchronized 和 Lock 能够保证任一时刻只有一个线程执行该代码块，那么自然就不存在原子性问题了，从而保证了原子性。

2.2 可见性

Java 提供了 volatile 关键字来保证可见性。
当一个共享变量被 volatile 修饰时，它会保证修改的值会立即被更新到主存，当有其他线程需要读取时，它会去内存中读取新值。
而普通的共享变量不能保证可见性，因为普通共享变量被修改之后，什么时候被写入主存是不确定的，当其他线程去读取时，此时内存中可能还是原来的旧值，因此无法保证可见性。

另外，通过 synchronized 和 Lock 也能够保证可见性，synchronized 和 Lock 能保证同一时刻只有一个线程获取锁然后执行同步代码，并且在释放锁之前会将对变量的修改刷新到主存当中。因此可以保证可见性。

2.3 有序性

在 Java 里面，可以通过 volatile 关键字来保证一定的 “有序性”（具体原理在下一节讲述）。另外可以通过 synchronized 和 Lock 来保证有序性，很显然，synchronized 和 Lock 保证每个时刻是有一个线程执行同步代码，相当于是让线程顺序执行同步代码，自然就保证了有序性。当然 JMM 是通过 Happens-Before 规则来保证有序性的。