【Java 多线程并发】理论基础

Metadata

title: 【Java 多线程并发】 理论基础
date: 2022-12-14 14:55
tags:
  - 行动阶段/完成
  - 主题场景/编程
  - 笔记空间/KnowladgeSpace/ProgramSpace
  - 细化主题/Java/多线程并发
categories:
  - Java
keywords:
  - Java/多线程并发
description: 多线程并发 理论基础

多线程的意义

众所周知，CPU、内存、I/O 设备的速度是有极大差异的，为了合理利用 CPU 的高性能，平衡这三者的速度差异，计算机体系结构、操作系统、编译程序都做出了贡献，主要体现为:

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

并发出现问题的根源: 并发三要素

可见性: CPU 缓存引起

可见性：一个线程对共享变量的修改，另外一个线程能够立刻看到。

这就是可见性问题，线程 1 对变量 i 修改了之后，线程 2 没有立即看到线程 1 修改的值。

原子性: 分时复用引起

原子性：即一个操作或者多个操作要么全部执行并且执行的过程不会被任何因素打断，要么就都不执行。

由于 CPU 分时复用（线程切换）的存在，线程 1 执行了第一条指令后，就切换到线程 2 执行，假如线程 2 执行了这三条指令后，再切换会线程 1 执行后续两条指令，将造成最后写到内存中的 i 值是 2 而不是 3。

有序性: 重排序引起

有序性：即程序执行的顺序按照代码的先后顺序执行。

从 java 源代码到最终实际执行的指令序列，会分别经历下面三种重排序：

上述的 1 属于编译器重排序，2 和 3 属于处理器重排序。这些重排序都可能会导致多线程程序出现内存可见性问题。对于编译器，JMM 的编译器重排序规则会禁止特定类型的编译器重排序（不是所有的编译器重排序都要禁止）。对于处理器重排序，JMM 的处理器重排序规则会要求 java 编译器在生成指令序列时，插入特定类型的内存屏障（memory barriers，intel 称之为 memory fence）指令，通过内存屏障指令来禁止特定类型的处理器重排序（不是所有的处理器重排序都要禁止）。

JAVA 是怎么解决并发问题的: JMM(Java 内存模型）

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

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

volatile、synchronized 和 final 三个关键字
Happens-Before 规则

理解的第二个维度：可见性，有序性，原子性

原子性

在 Java 中，对基本数据类型的变量的读取和赋值操作是原子性操作，即这些操作是不可被中断的，要么执行，要么不执行。

只有简单的读取、赋值（而且必须是将数字赋值给某个变量，变量之间的相互赋值不是原子操作）才是原子操作。

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

可见性

Java 提供了 volatile 关键字来保证可见性。

当一个共享变量被 volatile 修饰时，它会保证修改的值会立即被更新到主存，当有其他线程需要读取时，它会去内存中读取新值。

而普通的共享变量不能保证可见性，因为普通共享变量被修改之后，什么时候被写入主存是不确定的，当其他线程去读取时，此时内存中可能还是原来的旧值，因此无法保证可见性。

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

有序性

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