深入并发原理和大厂面试（二），kotlin 协程的理解
lock(锁定)：作用于主内存的变量，把一个变量标记为一条线程独占状态
unlock(解锁)：作用于主内存的变量，把一个处于锁定状态的变量释放出来，释放后 的变量才可以被其他线程锁定
read(读取)：作用于主内存的变量，把一个变量值从主内存传输到线程的工作内存 中，以便随后的 load 动作使用
load(载入)：作用于工作内存的变量，它把 read 操作从主内存中得到的变量值放入工 作内存的变量副本中
use(使用)：作用于工作内存的变量，把工作内存中的一个变量值传递给执行引擎
assign(赋值)：作用于工作内存的变量，它把一个从执行引擎接收到的值赋给工作内 存的变量
store(存储)：作用于工作内存的变量，把工作内存中的一个变量的值传送到主内存 中，以便随后的 write 的操作
write(写入)：作用于工作内存的变量，它把 store 操作从工作内存中的一个变量的值 传送到主内存的变量中
如果要把一个变量从主内存中复制到工作内存中，就需要按顺序地执行 read 和 load 操 作，如果把变量从工作内存中同步到主内存中，就需要按顺序地执行 store 和 write 操作。但 Java 内存模型只要求上述操作必须按顺序执行，而没有保证必须是连续执行。
不允许一个线程无原因地（没有发生过任何 assign 操作）把数据从工作内存同步回主内存中
一个新的变量只能在主内存中诞生，不允许在工作内存中直接使用一个未被初始化 （load 或者 assign）的变量。即就是对一个变量实施 use 和 store 操作之前，必须先自行 assign 和 load 操作。
一个变量在同一时刻只允许一条线程对其进行 lock 操作，但 lock 操作可以被同一线程重 复执行多次，多次执行 lock 后，只有执行相同次数的 unlock 操作，变量才会被解锁。lock 和 unlock 必须成对出现。
如果对一个变量执行 lock 操作，将会清空工作内存中此变量的值，在执行引擎使用这个 变量之前需要重新执行 load 或 assign 操作初始化变量的值。
如果一个变量事先没有被 lock 操作锁定，则不允许对它执行 unlock 操作；也不允许去 unlock 一个被其他线程锁定的变量。
对一个变量执行 unlock 操作之前，必须先把此变量同步到主内存中（执行 store 和 write 操作）
========================================================================
原子性指的是一个操作是不可中断的，即使是在多线程环境下，一个操作一旦开始就不会被其他线程影响。
在 java 中，对基本数据类型的变量的读取和赋值操作是原子性操作有点要注意的是，对 于 32 位系统的来说，long 类型数据和 double 类型数据(对于基本数据类型，
byte,short,int,float,boolean,char 读写是原子操作)，它们的读写并非原子性的，也就是说 如果存在两条线程同时对 long 类型或者 double 类型的数据进行读写是存在相互干扰的，因 为对于 32 位虚拟机来说，每次原子读写是 32 位的，而 long 和 double 则是 64 位的存储单元，这样会导致一个线程在写时，操作完前 32 位的原子操作后，轮到 B 线程读取时，恰好只读取到了后 32 位的数据，这样可能会读取到一个既非原值又不是线程修改值的变量，它可能是“半个变量”的数值，即 64 位数据被两个线程分成了两次读取。但也不必太担心，因为读取到“半个变量”的情况比较少见，至少在目前的商用的虚拟机中，几乎都把 64 位的数据的读写操作作为原子操作来执行，因此对于这个问题不必太在意，知道这么回事即可。
理解了指令重排现象后，可见性容易了，可见性指的是当一个线程修改了某个共享变量 的值，其他线程是否能够马上得知这个修改的值。对于串行程序来说，可见性是不存在的， 因为我们在任何一个操作中修改了某个变量的值，后续的操作中都能读取这个变量值，并且是修改过的新值。
但在多线程环境中可就不一定了，前面我们分析过，由于线程对共享变量的操作都是线 程拷贝到各自的工作内存进行操作后才写回到主内存中的，这就可能存在一个线程 A 修改了 共享变量 x 的值，还未写回主内存时，另外一个线程 B 又对主内存中同一个共享变量 x 进行操 作，但此时 A 线程工作内存中共享变量 x 对线程 B 来说并不可见，这种工作内存与主内存同步延迟现象就造成了可见性问题，另外指令重排以及编译器优化也可能导致可见性问题，通过前面的分析，我们知道无论是编译器优化还是处理器优化的重排现象，在多线程环境下，确实会导致程序轮序执行的问题，从而也就导致可见性问题。
有序性是指对于单线程的执行代码，我们总是认为代码的执行是按顺序依次执行的，这 样的理解并没有毛病，毕竟对于单线程而言确实如此，但对于多线程环境，则可能出现乱序 现象，因为程序编译成机器码指令后可能会出现指令重排现象，重排后的指令与原指令的顺 序未必一致，要明白的是，在 Java 程序中，倘若在本线程内，所有操作都视为有序行为，如果是多线程环境下，一个线程中观察另外一个线程，所有操作都是无序的，前半句指的是单线程内保证串行语义执行的一致性，后半句则指指令重排现象和工作内存与主内存同步延迟现象。
=====================================================================================
除了 JVM 自身提供的对基本数据类型读写操作的原子性外，可以通过 synchronized 和 Lock 实现原子性。因为 synchronized 和 Lock 能够保证任一时刻只有一个线程访问该代码块。
volatile 关键字保证可见性。当一个共享变量被 volatile 修饰时，它会保证修改的值立即 被其他的线程看到，即修改的值立即更新到主存中，当其他线程需要读取时，它会去内存中 读取新值。synchronized 和 Lock 也可以保证可见性，因为它们可以保证任一时刻只有一个 线程能访问共享资源，并在其释放锁之前将修改的变量刷新到内存中。
可以通过 synchronized 和 Lock 来保证有序性，很显然，synchronized 和 Lock 保证每个时刻是有一个线程执行同步代码，相当于是让线程顺序执行同步代码，自然就保证了有序性。
3.3.1 Ja
va 内存模型
每个线程都有自己的工作内存（类似于前面的高速缓存）。线程对变 量的所有操作都必须在工作内存中进行，而不能直接对主存进行操作。并且每个线程不能访 问其他线程的工作内存。Java 内存模型具备一些先天的“有序性”，即不需要通过任何手段 就能够得到保证的有序性，这个通常也称为 happens-before 原则。如果两个操作的执行次序无法从 happens-before 原则推导出来，那么它们就不能保证它们的有序性，虚拟机可以 随意地对它们进行重排序。
3.3.2 指令重排序
java 语言规范规定 JVM 线程内部维持顺序化语义。即只要程序的最终结果 与它顺序化情况的结果相等，那么指令的执行顺序可以与代码顺序不一致，此过程叫指令的 重排序。指令重排序的意义是什么？JVM 能根据处理器特性（CPU 多级缓存系统、多核处 理器等）适当的对机器指令进行重排序，使机器指令能更符合 CPU 的执行特性，最大限度的 发挥机器性能。
3.3.2.1 as-if-serial 语义
as-if-serial 语义的意思是：不管怎么重排序（编译器和处理器为了提高并行度），（单 线程）程序的执行结果不能被改变。编译器、runtime 和处理器都必须遵守 as-if-serial 语 义。为了遵守 as-if-serial 语义，编译器和处理器不会对存在数据依赖关系的操作做重排序，因为这种重排序会改变执行结果。但是，如果操作之间不存在数据依赖关系，这些操作就可能被编译器和处理器重排序。
3.3.2.2 happens-before 原则
只靠 sychronized 和 volatile 关键字来保证原子性、可见性以及有序性，那么编写并发 程序可能会显得十分麻烦，幸运的是，从 JDK 5 开始，Java 使用新的 JSR-133 内存模型，提 供了 happens-before 原则来辅助保证程序执行的原子性、可见性以及有序性的问题，它是 判断数据是否存在竞争、线程是否安全的依据，happens-before 原则内容如下:
程序顺序原则，即在一个线程内必须保证语义串行性，也就是说按照代码顺序执 行。
锁规则,解锁(unlock)操作必然发生在后续的同一个锁的加锁(lock)之前，也就是 说，如果对于一个锁解锁后，再加锁，那么加锁的动作必须在解锁动作之后(同一个锁)。
volatile 规则,volatile 变量的写，先发生于读，这保证了 volatile 变量的可见性，简 单的理解就是，volatile 变量在每次被线程访问时，都强迫从主内存中读该变量的 值，而当该变量发生变化时，又会强迫将最新的值刷新到主内存，任何时刻，不同的 线程总是能够看到该变量的最新值。
还未添加个人签名 2021.10.31 加入
还未添加个人简介
评论