文章目录

二、并发编程的三大特性
- 1 原子性
- - 1.1 什么是原子性
  - 1.2 怎么保证原子性
  - - 1.2.1 synchronized
    - 1.2.2 CAS
    - 1.2.3 Lock 锁
    - 1.2.4 ThreadLocal
- 2 可见性
- - 2.1 什么是可见性
  - 2.2 解决可见性的方式
  - - 2.2.1 volatile
    - 2.2.2 synchronized
    - 2.2.3 Lock
    - 2.2.4 final
- 3 有序性
- - 3.1 什么是有序性
  - 3.2 as-if-serial
  - 3.3 happens-before
  - 3.4 volatile

二、并发编程的三大特性

1 原子性

1.1 什么是原子性

JMM（Java Memory Model）。不同的硬件和不同的操作系统在内存上的操作有一定的差异，Java 为了解决相同代码在不同操作系统上出现的各种问题，用 JMM 屏蔽掉各种硬件和操作系统带来的差异，让 Java 的并发编程可以做到跨平台。
JMM 规定所有变量都会存储在主内存中，在操作的时候，需要从主内存中复制一份到线程内存(CPU内存)，在线程内部做计算，然后回写到主内存中(不一定!!)
原子性的定义：原子性是指一个操作是不可分割的、不可中断的，一个线程在执行时，另一个线程不会影响到它。
并发编程的原子性用代码阐述：

private static int count;
public static void main(String[] args) throws InterruptedException {
    Thread t1 = new Thread(() -> {
        for (int i = 0; i < 100; i++) {
            increment();
        }
    });
    Thread t2 = new Thread(() -> {
        for (int i = 0; i < 100; i++) {
            increment();
        }
    });
    t1.start();
    t2.start();
    t1.join();
    t2.join();
    System.out.println(count);
}
private static void increment() {
    try {
        Thread.sleep(10);
    } catch (InterruptedException e) {
        e.printStackTrace();
    }
    count++;
}

当前程序，多线程操作共享数据时，预期的结果与最终的结果不符。
原子性：多线程操作临界资源，预期结果与最终结果一致。
通过这个程序的分析，可以查看出，++ 操作一共分为三步：① 线程从主内存拿到数据并保存到 CPU 的寄存器中，② 在寄存器中进行 +1 操作，③ 最终将结果写回到主内存中。

1.2 怎么保证原子性

1.2.1 synchronized

因为 ++操作可以从指令中查看到

可以在方法上追加 synchronized 关键字或者采用同步代码块的形式来保证原子性。synchronized 可以避免多线程同时操作临界资源，在同一时间点，只会有一个线程正在操作临界资源。

1.2.2 CAS

什么是CAS？

CAS 即 Compare And Swap 也就是比较和交换，是一条 CPU 的并发原语。
它在替换内存的某个位置的值时，首先查看内存中的值与预期值是否一致，如果一致，那么执行替换操作，这个操作是一个原子操作。
Java中基于Unsafe类提供了对 CAS 操作的方法，JVM会帮助我们将方法实现 CAS 汇编指令。但是要清楚 CAS 只是比较和交换，在获取原值的这个操作上，需要自己实现。

private static AtomicInteger count = new AtomicInteger(0);
public static void main(String[] args) throws InterruptedException {
    Thread t1 = new Thread(() -> {
        for (int i = 0; i < 100; i++) {
            count.incrementAndGet();
        }
    });
    Thread t2 = new Thread(() -> {
        for (int i = 0; i < 100; i++) {
            count.incrementAndGet();
        }
    });
    t1.start();
    t2.start();
    t1.join();
    t2.join();
    System.out.println(count);
}

Doug Lea 在 CAS 的基础上帮助我们实现了一些原子类，其中就包括现在看到的 AtomicInteger，还有其他很多原子类…
CAS的缺点：CAS 只能保证对一个变量的操作是原子性的，无法实现对多行代码实现原子性。
CAS的问题一：ABA问题
- 可以引入版本号的方式，来解决ABA的问题，Java中提供了一个类在CAS时，针对各个版本追加版本号的操作：AtomicStampeReference。

public static void main(String[] args) throws InterruptedException {
    AtomicStampedReference<String> reference = new AtomicStampedReference<>("A", 1);

    String oldValue = reference.getReference();
    int oldVersion = reference.getStamp();

    boolean result = reference.compareAndSet(oldValue, "B", oldVersion, oldVersion + 1);
    System.out.println("修改1版本的:" + result);

    result = reference.compareAndSet("B", "C", 1, 2);
    System.out.println("修改2版本的:" + result);
}

CAS的问题二：自旋时间过长问题
- 可以指定CAS一共循环多少次，如果超过这个次数，直接失败、或者挂起线程（自旋锁、自适应自旋锁）
- 可以在CAS一次失败后，将这个操作暂存起来，后面需要获取结果时，将暂存操作全部执行，再返回最后的结果。比如：LongAdder。

1.2.3 Lock 锁

Lock锁是在JDK1.5由Doug Lea研发的，它的性能相比 synchronized在JDK1.5时期，性能好了很多。但是在JDK1.6对synchronized优化之后，性能相差不大，但是如果涉及到并发比较多时，推荐使用 ReentrantLock，性能会更好。
实现方式：

private static int count;
private static ReentrantLock lock = new ReentrantLock();
public static void increment() {
    lock.lock();
    try {
        count++;
        Thread.sleep(10);
    } catch (InterruptedException e) {
        e.printStackTrace();
    } finally {
        lock.unlock();
    }
}
public static void main(String[] args) throws InterruptedException {
    Thread t1 = new Thread(() -> {
        for (int i = 0; i < 100; i++) {
            increment();
        }
    });
    Thread t2 = new Thread(() -> {
        for (int i = 0; i < 100; i++) {
            increment();
        }
    });
    t1.start();
    t2.start();
    t1.join();
    t2.join();
    System.out.println(count);
}

ReentrantLock 可以直接对比 synchronized，在功能上来说都是锁。但是 ReentrantLock 的功能性相比 synchronized 更加丰富。
ReentrantLock 底层是基于AQS实现的，有一个基于 CAS 维护的 state 变量来实现锁的操作。

1.2.4 ThreadLocal

Java 中的四种引用类型，分别是：强、软、弱、虚。在 Java 中最常用的就是强引用，把一个对象赋给另一个引用变量（User user = new User()），这个引用变量就是一个强引用。当一个对象被强引用变量引用时，它始终处于可达状态，它是不能被垃圾回收机制回收的，即使该对象以后永远都不会被用到，JVM也不会回收。因此，强引用时造成Java内存泄漏的主要原因之一。
其次是软引用（SoftReference），对于只有软引用的对象来说，当系统内存充足时不会被回收，当系统内存空间不足时被回收。软引用通常用在对内存敏感的程序中，作为缓存使用。
然后是弱引用，它比软引用的生存期更短，对于只有弱引用的对象来说，只要垃圾回收机制一运行，不管JVM内存是否充足，都会回收该对象占用的内存。可以解决内存泄漏问题，ThreadLocal 就是基于弱引用来解决内存泄漏问题。（针对 Entry 中的key）
最后是虚引用，它不能单独使用，必须和引用队列联合使用。虚引用的主要作用是跟踪对象被垃圾回收的状态，不过在开发中，我们用的更多的还是强引用。

ThreadLocal 保证原子性的方式，是不让多线程去操作临界资源，而是让每个线程去操作属于自己的数据。

代码实现：

static ThreadLocal tl1 = new ThreadLocal();
static ThreadLocal tl2 = new ThreadLocal();
public static void main(String[] args) throws InterruptedException {
    tl1.set("123");
    tl2.set("456");
    Thread t1 = new Thread(() -> {
        System.out.println("t1:" + tl1.get()); // null
        System.out.println("t1:" + tl2.get()); // null
    });
    t1.start();
    System.out.println("main:" + tl1.get()); // 123
    System.out.println("main:" + tl2.get()); // 456
}

ThreadLocal实现原理：

每个线程Thread中都存储着一个成员变量，ThreadLocalMap；
ThreadLocal本身不存储数据，它更像是一个工具类，基于 ThreadLocal 去操作 ThreadLocalMap；
ThreadLocalMap 本身就是基于 Entry[] 实现的，因为一个线程可以绑定多个 ThreadLocal，这样一来，可能需要存储多个数据，所以采用 Entry[] 的形式实现；
每个线程都有自己独立的 ThreadLocalMap，再基于 ThreadLocalMap 对象本身作为 key，对 value 进行存取；
ThreadLocalMap 的key是一个弱引用，弱引用的特点是，GC发生时必须被回收。这里是为了在 ThreadLocalMap 对象失去引用后，如果 key 的引用是强引用，会导致 ThreadLocal 对象无法被回收。

ThreadLocal 内存泄漏问题：

如果 ThreadLocal 引用丢失，key 因为是弱引用会被 GC 回收掉，如果同时线程还没有被回收，就会导致内存泄漏，内存中的 value 无法被回收，同时也无法被获取到。
解决办法：只需要在使用完毕 ThreadLocal 对象之后，及时的调用 remove 方法，移除 Entry 即可。

2 可见性

2.1 什么是可见性

可见性问题是基于 CPU 位置出现的，CPU 处理速度非常快，相对CPU而言，去主内存获取数据这个事情太慢了，CPU提供了 L1、L2、L3 三级缓存，每次去主内存拿完数据后，就会存储到 CPU 的三级缓存，每次去三级缓存拿数据，效率肯定会提升。

但这就带来问题，现在CPU都是多核，每个线程的工作内存（CPU三级缓存）都是独立的，会告知每个线程中做修改时，只改自己的工作内存，没有及时的同步到主内存中，导致数据不一致的问题。

可见性问题的代码逻辑：

private static boolean flag = true;

public static void main(String[] args) throws InterruptedException {
    Thread t1 = new Thread(() -> {
        while (flag) {
            // ...
        }
        System.out.println("t1线程结束");
    });
    t1.start();
    Thread.sleep(10);
    flag = false;
    System.out.println("主线程将flag改为false");
}

2.2 解决可见性的方式

2.2.1 volatile

volatile 是一个关键字，用来修饰成员变量。如果属性被 volatile 修改，相当于会告诉CPU，对当前属性的操作，不允许使用CPU缓存，必须去主内存操作。

volatile的内存语义：

volatile属性被写：当写一个volatile变量时，JMM会将当前线程对应的 CPU 缓存及时的刷新到主内存中；
volatile属性被读：当读一个volatile变量时，JMM会将对应的CPU缓存中的内存设置为无效，必须去主内存中重新读取共享变量。

其实加了volatile就是告诉CPU，对当前属性的读写操作，不允许使用 CPU 缓存，加了 volatile 修饰的属性，会在转为汇编指令后，追加一个 lock 的前缀，CPU执行这个指令时，对于带有 lock 前缀的会做两个事情：

将当前处理缓存行的数据写回到主内存；
这个写回的数据，在其他CPU内行的缓存中，直接无效。

总结：volatile就是让 CPU 每次操作这个数据时，必须立即同步到主内存，以及从主内存读取数据。

private volatile static boolean flag = true;

public static void main(String[] args) throws InterruptedException {
    Thread t1 = new Thread(() -> {
        while (flag) {
            // ...
        }
        System.out.println("t1线程结束");
    });
    t1.start();
    Thread.sleep(10);
    flag = false;
    System.out.println("主线程将flag改为false");
}

2.2.2 synchronized

synchronized也可以解决可见性问题，synchronized的内存语义：

如果涉及到 synchronized 的同步代码块或者同步方法，获取锁资源之后，将内部涉及到的变量从 CPU 缓存中移除，必须去主内存中重新拿数据；而且在释放锁之后，会立即将CPU缓存中的数据同步到主内存。

private static boolean flag = true;

public static void main(String[] args) throws InterruptedException {
    Thread t1 = new Thread(() -> {
        while (flag) {
            synchronized (MyTest.class) {
                // ...
            }
//                System.out.println(); // 打印方法内部也使用了synchronized
        }
        System.out.println("t1线程结束");
    });
    t1.start();
    Thread.sleep(10);
    flag = false;
    System.out.println("主线程将flag改为false");
}

2.2.3 Lock

Lock锁保证可见性的方式和 synchronized完全不同，synchronized基于它的内存语义，在获取锁和释放锁时，对CPU缓存做了一个同步到主内存的操作。

Lock锁时基于volatile实现的，Lock锁内部再进行加锁和释放锁时，会对一个由volatile修饰的state属性进行加减操作。

如果对volatile修饰的属性进行写操作，CPU会执行带有lock前缀的指令，CPU会降修改后的数据，从CPU缓存立即同步到主内存，同时也会将其他属性也立即同步到主内存中。还会降其他CPU缓存行中的这个数据设置为无效，必须重新去主内存中拉取。

private static boolean flag = true;
private static Lock lock = new ReentrantLock();

public static void main(String[] args) throws InterruptedException {
    Thread t1 = new Thread(() -> {
        while (flag) {
            lock.lock();
            try {
                // ...
            } finally {
                lock.unlock();
            }
        }
        System.out.println("t1线程结束");
    });
    t1.start();
    Thread.sleep(10);
    flag = false;
    System.out.println("主线程将flag改为false");
}

2.2.4 final

final修饰的属性，在运行期间是不允许修改的，这样一来，就间接保证了可见性，所有多线程读取 final 属性，值肯定是一样的。

final并不是说每次取数据从主内存读取，也没这个必要，而且final和volatile不允许同时修饰一个变量。

final修饰的内容已经不允许再次别写了，而 volatile 是保证每次读写数据去主内存读取，并且volatile会影响一定的性能，就不需要同时修饰。

3 有序性

3.1 什么是有序性

在Java中，.java 文件中的内容会被编译，在执行前需要再次转为 CPU 可以识别的指令，CPU在执行这些指令时，为了提升执行效率，在不影响最终结果的前提下（满足一下要求），会对指令进行重排。

指令乱序执行的原因，是为了尽可能的发挥 CPU 的性能。Java 中的程序是乱序执行的，验证乱序执行效果：

static int a, b, x, y;

public static void main(String[] args) throws InterruptedException {
    for (int i = 0; i < Integer.MAX_VALUE; i++) {
        a = 0;
        b = 0;
        x = 0;
        y = 0;
        Thread t1 = new Thread(() -> {
            a = 1;
            x = b;
        });
        Thread t2 = new Thread(() -> {
            b = 1;
            y = a;
        });
        t1.start();
        t2.start();
        t1.join();
        t2.join();

        if (x == 0 && y == 0) {
            System.out.println("第" + i + "次，x = " + x + ", y = " + y);
        }
    }
}

DCL 单例模式由于指令重排序可能出现问题：线程可能会拿到没有初始化的对象，导致在使用时，由于内部属性为默认值，导致出现一些不必要的问题：

public class MyTest {
    private static volatile MyTest test;

    private MyTest() {}
  
    public static MyTest getInstance() {
        // B
        if (test == null) {
            synchronized (MyTest.class) {
                if (test == null) {
                    // A: 开辟空间、test指向地址、初始化
                    test = new MyTest();
                }
            }
        }
        return test;
    }
}

3.2 as-if-serial

as-if-serial语义：不论指令如何重排序，需要保证单线程的程序执行结果是不变的。而且如果存在依赖关系，那么也不可以做指令重排。

// 这种情况肯定不能做指令重排
int i = 0;
i++;

// 这种情况肯定不能做指令重排序
int j = 200;
j * 100;
j + 100;
// 这里即便出现了指令重排，也不可以影响最终的结果，20100

3.3 happens-before

具体规则：

单线程happen-before原则：在同一个线程中，书写在前面的操作happen-before后面的操作。
锁的happen-before原则：同一个锁的unlock操作happen-before此锁的lock操作。
volatile的happen-before原则：对一个volatile变量的写操作happen-before对此变量的任意操作。
happen-before的传递性原则：如果A操作 happen-before B操作，B操作happen-before C操作，那么A操作happen-before C操作。
线程启动的happen-before原则：同一个线程的start方法happen-before此线程的其它方法。
线程中断的happen-before原则：对线程interrupt方法的调用happen-before被中断线程的检测到中断发送的代码。
线程终结的happen-before原则：线程中的所有操作都happen-before线程的终止检测。
对象创建的happen-before原则：一个对象的初始化完成先于他的finalize方法调用。

**JMM 只有不出现上述 8 种情况时，才不会触发指令重排效果。**不需要过分的关注happens-before原则，只需要可以写出线程安全的代码就可以了。