Skip to content

Latest commit

 

History

History
244 lines (152 loc) · 11.1 KB

2_并发理论.md

File metadata and controls

244 lines (152 loc) · 11.1 KB
Raw

并发理论

Java 内存模型

Java 内存模型（即 Java Memory Model，简称 JMM）试图屏蔽各种硬件和操作系统的内存访问差异，以实现让 Java 程序在各种平台下都能达到一致的内存访问效果。

本身是一种抽象的概念，并不真实存在，它描述的是一组规则或规范。

1. 主内存与工作内存

处理器上的寄存器的读写的速度比内存快几个数量级，为了解决这种速度矛盾，在它们之间加入了高速缓存。

加入高速缓存带来了一个新的问题：缓存一致性。如果多个缓存共享同一块主内存区域，那么多个缓存的数据可能会不一致，需要一些协议来解决这个问题。

img

JMM 规定所有的变量都存储在主内存中，每个线程还有自己的工作内存，工作内存存储在高速缓存或者寄存器中，保存了该线程使用的变量的主内存副本拷贝。

线程只能直接操作工作内存中的变量，不同线程之间的变量值传递需要通过主内存来完成。

img

2. JMM 三大特性

内存间的交互操作

Java 内存模型定义了 8 个操作来完成主内存和工作内存的交互操作。

img

  • read：把一个变量的值从主内存传输到工作内存中
  • load：在 read 之后执行，把 read 得到的值放入工作内存的变量副本中
  • use：把工作内存中一个变量的值传递给执行引擎
  • assign：把一个从执行引擎接收到的值赋给工作内存的变量
  • store：把工作内存的一个变量的值传送到主内存中
  • write：在 store 之后执行，把 store 得到的值放入主内存的变量中
  • lock：作用于主内存的变量
  • unlock

特性一：原子性

Java 内存模型保证了 read、load、use、assign、store、write、lock 和 unlock 操作具有原子性。

例如对一个 int 类型的变量执行 assign 赋值操作，这个操作就是原子性的。但是 Java 内存模型允许虚拟机将没有被 volatile 修饰的 64 位数据（long，double）的读写操作划分为两次 32 位的操作来进行，即 load、store、read 和 write 操作可以不具备原子性。

有一个错误认识就是，int 等原子性的类型在多线程环境中不会出现线程安全问题。前面的线程不安全示例代码中，cnt 属于 int 类型变量，1000 个线程对它进行自增操作之后，得到的值为 997 而不是 1000。

为了方便讨论，将内存间的交互操作简化为 3 个：load、assign、store。

下图演示了两个线程同时对 cnt 进行操作，load、assign、store 这一系列操作整体上看不具备原子性，那么在 T1 修改 cnt 并且还没有将修改后的值写入主内存，T2 依然可以读入旧值。可以看出，这两个线程虽然执行了两次自增运算，但是主内存中 cnt 的值最后为 1 而不是 2。因此对 int 类型读写操作满足原子性只是说明 load、assign、store 这些单个操作具备原子性。

img

AtomicInteger 能保证多个线程修改的原子性。

img

使用 AtomicInteger 重写之前线程不安全的代码之后得到以下线程安全实现：

public class AtomicExample {
    private AtomicInteger cnt = new AtomicInteger();

    public void add() {
        cnt.incrementAndGet();
    }

    public int get() {
        return cnt.get();
    }
}Copy to clipboardErrorCopied
public static void main(String[] args) throws InterruptedException {
    final int threadSize = 1000;
    AtomicExample example = new AtomicExample(); // 只修改这条语句
    final CountDownLatch countDownLatch = new CountDownLatch(threadSize);
    ExecutorService executorService = Executors.newCachedThreadPool();
    for (int i = 0; i < threadSize; i++) {
        executorService.execute(() -> {
            example.add();
            countDownLatch.countDown();
        });
    }
    countDownLatch.await();
    executorService.shutdown();
    System.out.println(example.get());
}Copy to clipboardErrorCopied
1000Copy to clipboardErrorCopied

除了使用原子类之外，也可以使用 synchronized 互斥锁来保证操作的原子性。它对应的内存间交互操作为：lock 和 unlock，在虚拟机实现上对应的字节码指令为 monitorenter 和 monitorexit。

public class AtomicSynchronizedExample {
    private int cnt = 0;

    public synchronized void add() {
        cnt++;
    }

    public synchronized int get() {
        return cnt;
    }
}Copy to clipboardErrorCopied
public static void main(String[] args) throws InterruptedException {
    final int threadSize = 1000;
    AtomicSynchronizedExample example = new AtomicSynchronizedExample();
    final CountDownLatch countDownLatch = new CountDownLatch(threadSize);
    ExecutorService executorService = Executors.newCachedThreadPool();
    for (int i = 0; i < threadSize; i++) {
        executorService.execute(() -> {
            example.add();
            countDownLatch.countDown();
        });
    }
    countDownLatch.await();
    executorService.shutdown();
    System.out.println(example.get());
}
1000

特性二：可见性

可见性指当一个线程修改了共享变量的值，其它线程能够立即得知这个修改。

主要有三种实现可见性的方式：

  • volatile，保证被 volatile 修饰的共享变量对所有线程总是可见的
  • synchronized，对一个变量执行 unlock 操作之前，必须把变量值同步回主内存。
  • final，被 final 关键字修饰的字段在构造器中一旦初始化完成，并且没有发生 this 逃逸（其它线程通过 this 引用访问到未初始化完成的对象），那么其它线程就能看见 final 字段的值。

注意： volatile 并不能保证操作的原子性。

特性三：有序性

有序性是指在一个线程内观察，所有的操作都是有序的。在一个线程观察另一个线程，所有操作都是无序的，无序是因为发生了指令重排序。

在 Java 内存模型中，允许编译器和处理器对指令进行重排序，重排序过程不会影响到单线程程序的执行，却会影响到多线程并发执行的正确性。

volatile 和 synchronized 都可保证有序性：

  • volatile 关键字通过添加内存屏障的方式来禁止指令重排，即重排序时不能把后面的指令放到内存屏障之前。
  • synchronized 来保证有序性，它保证每个时刻只有一个线程执行同步代码，相当于是让线程顺序执行同步代码。

3. 先行发生原则

规则一：单一线程原则

Single Thread rule

在一个线程内，在程序前面的操作先行发生于后面的操作。

img

规则二：管程锁定规则

一个 unlock 操作先行发生于后面对同一个锁的 lock 操作。

img

规则三：volatile 变量规则

Volatile Variable Rule

对一个 volatile 变量的写操作先行发生于后面对这个变量的读操作。

img

规则四：线程启动规则

Thread Start Rule

Thread 对象的 start() 方法调用先行发生于此线程的每一个动作。

img

规则五：线程加入规则

Thread Join Rule

Thread 对象的结束先行发生于 join() 方法返回。

img

规则六：线程中断规则

Thread Interruption Rule

对线程 interrupt() 方法的调用先行发生于被中断线程的代码检测到中断事件的发生，可以通过 interrupted() 方法检测到是否有中断发生。

规则七：对象终结规则

Finalizer Rule

一个对象的初始化完成（构造函数执行结束）先行发生于它的 finalize() 方法的开始。

规则八：传递性

Transitivity

如果操作 A 先行发生于操作 B，操作 B 先行发生于操作 C，那么操作 A 先行发生于操作 C。

乐观锁和悲观锁

1. 悲观锁

互斥同步最主要的问题就是线程阻塞和唤醒所带来的性能问题，因此这种同步也称为阻塞同步。

互斥同步属于一种悲观的并发策略：总是认为只要不去做正确的同步措施，那就肯定会出现问题。无论共享数据是否真的会出现竞争，它都要进行加锁。

Java 中 synchronized 和 ReentrantLock 等独占锁就是悲观锁思想的实现。

2. 乐观锁

乐观锁基于冲突检测的乐观并发策略：先进行操作，如果没有其他线程争用共享数据，操作成功；如果数据存在竞争，就采用补偿措施（常见的有不断重试，直到成功）。这种乐观的并发策略的许多实现是不需要将线程挂起的，因此这种同步操作称为非阻塞同步。

3. CAS

乐观锁需要操作和冲突检测这两个步骤具备原子性，这里就不能再使用互斥同步来保证了，只能靠硬件来完成。、

硬件支持的原子性操作最典型的是：CAS（Compare-and-Swap）。

当多个线程尝试使用 CAS 同时更新一个共享变量时，只有其中一个线程能够更新共享变量中的值，其他线程都失败，失败的线程不会被挂起，而是被告知在这次竞争中失败，并且可以再次尝试。

CAS 指令需要有 3 个操作数，分别是内存地址 V、旧的预期值 A 和新值 B。当执行操作时，只有当 V 的值等于 A，才将 V 的值更新为 B。

使用 CAS 带来的问题：

  • ABA 问题

    如果一个变量初次读取的时候是 A 值，它的值被改成了 B，后来又被改回为 A，那 CAS 操作就会误认为它从来没有被改变过。

    J.U.C 包提供了一个带有标记的原子引用类 AtomicStampedReference 来解决这个问题，它可以通过控制变量值的版本来保证 CAS 的正确性。大部分情况下 ABA 问题不会影响程序并发的正确性，如果需要解决 ABA 问题，改用传统的互斥同步可能会比原子类更高效。

  • 只能保证一个共享变量的原子操作

    JDK 1.5 以后，使用 AtomicReference 将多个共享变量封装为一个共享变量进行操作。

  • 自旋时间长开销大

    自旋CAS（也就是不成功就一直循环执行直到成功）如果长时间不成功，会给 CPU 带来非常大的执行开销。