第12章 Java内存模型与线程
文章目录
12.1 概述
每秒事务处理数（Transactions Per Second，TPS）
12.3 Java内存模型
定义程序中各种变量的访问规则，即关注在虚拟机中把变量值存储到内存和从内存中取出变量值这样的底层细节
变量（Variables）包括实例字段、静态字段和构成数组对象的元素，但是不包括局部变量与方法参数(线程私有)
12.3.1 主内存与工作内存
12.3.2 内存间交互操作
操作
- lock（锁定）：作用于主内存的变量，它把一个变量标识为一条线程独占的状态
- unlock（解锁）：作用于主内存的变量，它把一个处于锁定状态的变量释放出来，释放后的变量才可以被其他线程锁定
- read（读取）：作用于主内存的变量，它把一个变量的值从主内存传输到线程的工作内存中，以便随后的load动作使用
- load（载入）：作用于工作内存的变量，它把read操作从主内存中得到的变量值放入工作内存的变量副本中
- use（使用）：作用于工作内存的变量，它把工作内存中一个变量的值传递给执行引擎，每当虚拟机遇到一个需要使用变量的值的字节码指令时将会执行这个操作
- assign（赋值）：作用于工作内存的变量，它把一个从执行引擎接收的值赋给工作内存的变量，每当虚拟机遇到一个给变量赋值的字节码指令时执行这个操作
- store（存储）：作用于工作内存的变量，它把工作内存中一个变量的值传送到主内存中，以便随后的write操作使用
- write（写入）：作用于主内存的变量，它把store操作从工作内存中得到的变量的值放入主内存的变量中
规定
- 不允许read和load、store和write操作之一单独出现，即不允许一个变量从主内存读取了但工作内存不接受，或者工作内存发起回写了但主内存不接受的情况出现
- 不允许一个线程丢弃它最近的assign操作，即变量在工作内存中改变了之后必须把该变化同步回主内存
- 不允许一个线程无原因地（没有发生过任何assign操作）把数据从线程的工作内存同步回主内存中
- 一个新的变量只能在主内存中“诞生”，不允许在工作内存中直接使用一个未被初始化（load或assign）的变量，换句话说就是对一个变量实施use、store操作之前，必须先执行assign和load操作
- 一个变量在同一个时刻只允许一条线程对其进行lock操作，但lock操作可以被同一条线程重复执行多次，多次执行lock后，只有执行相同次数的unlock操作，变量才会被解锁
- 如果对一个变量执行lock操作，那将会清空工作内存中此变量的值，在执行引擎使用这个变量前，需要重新执行load或assign操作以初始化变量的值
- 如果一个变量事先没有被lock操作锁定，那就不允许对它执行unlock操作，也不允许去unlock一个被其他线程锁定的变量
- 对一个变量执行unlock操作之前，必须先把此变量同步回主内存中（执行store、write操作）
12.3.3 对于volatile型变量的特殊规则
可见性、禁止指令重排序优化。选择依据仅仅是volatile的语义能否满足使用场景的需求
可见性规则
- 运算结果并不依赖变量的当前值，或者能够确保只有单一的线程修改变量的值
- 变量不需要与其他的状态变量共同参与不变约束
12.3.4 针对long和double型变量的特殊规则
非原子性协定（Non-Atomic Treatment of double and long Variables）：虚拟机自行选择是否要保证64位数据类型的load、store、read和write操作的原子性。除非该数据有明确可知的线程竞争，否则不需要把long和double声明为volatile
12.3.5 原子性、可见性与有序性
- 原子性（Atomicity）：基本数据类型的访问、读写都是具备原子性的，synchronized块
- 可见性（Visibility）：volatile、synchronized和final（被final修饰的字段在构造器中一旦被初始化完成，并且构造器没有把“this”的引用传递出去）
- 有序性（Ordering）：volatile和synchronized
12.3.6 先行发生原则（Happens-Before）
程序次序规则（Program Order Rule）：在一个线程内，按照控制流顺序，书写在前面的操作先行发生于书写在后面的操作。注意，这里说的是控制流顺序而不是程序代码顺序，因为要考虑分支、循环等结构
管程锁定规则（Monitor Lock Rule）：一个unlock操作先行发生于后面对同一个锁的lock操作。这里必须强调的是“同一个锁”，而“后面”是指时间上的先后
volatile变量规则（Volatile Variable Rule）：对一个volatile变量的写操作先行发生于后面对这个变量的读操作，这里的“后面”同样是指时间上的先后
线程启动规则（Thread Start Rule）：Thread对象的start()方法先行发生于此线程的每一个动作
线程终止规则（Thread Termination Rule）：线程中的所有操作都先行发生于对此线程的终止检测，我们可以通过Thread::join()方法是否结束、Thread::isAlive()的返回值等手段检测线程是否已经终止执行
线程中断规则（Thread Interruption Rule）：对线程interrupt()方法的调用先行发生于被中断线程的代码检测到中断事件的发生，可以通过Thread::interrupted()方法检测到是否有中断发生
对象终结规则（Finalizer Rule）：一个对象的初始化完成（构造函数执行结束）先行发生于它的finalize()方法的开始
传递性（Transitivity）：如果操作A先行发生于操作B，操作B先行发生于操作C，那就可以得出操作A先行发生于操作C的结论
12.4 Java与线程
12.4.1 线程的实现
- 内核线程实现（Kernel-Level Thread，KLT）：1(轻量级进程)：1(内核线程)
- 内核线程：是直接由操作系统内核（Kernel，下称内核）支持的线程，内核通过操纵调度器（Scheduler）对线程进行调度，并负责将线程的任务映射到各个处理器上。
- 轻量级进程（Light Weight Process，LWP）：程序一般不会直接使用内核线程，而是使用内核线程的一种高级接口——轻量级进程，轻量级进程就是我们通常意义上所讲的线程
- 系统调用的代价相对较高：基于内核线程实现的，所以各种线程操作，如创建、析构及同步，都需要进行系统调用,需要在用户态（User Mode）和内核态（Kernel Mode）中来回切换。
- 系统支持轻量级进程的数量是有限的：轻量级进程都需要有一个内核线程的支持，因此轻量级进程要消耗一定的内核资源（如内核线程的栈空间）
- 用户线程实现（User Thread，UT）：1（进程）：N（用户线程）
- 混合实现：N（内核线程）：M（用户线程）
- Java线程的实现 1:1模型，线程模型只对线程的并发规模和操作成本产生影响，对Java程序的编码和运行过程来说，这些差异都是完全透明的
12.4.2 Java线程调度
系统为线程分配处理器使用权的过程
调度方式
- 协同式（Cooperative Threads-Scheduling）线程调度：执行时间由线程本身来控制，工作执行完之后，主动通知系统切换到另外一个线程上去
- 实现简单
- 切换操作对线程自己是可知的，一般没有线程同步问题
- 线程执行时间不可控制
- 抢占式（Preemptive Threads-Scheduling）线程调度：由系统来分配执行时间
- 线程的执行时间是系统可控
12.4.3 状态转换
新建（New）：创建后尚未启动的线程处于这种状态
运行（Runnable）：包括操作系统线程状态中的Running和Ready，可能正在执行，也有可能正在等待着操作系统为它分配执行时间
无限期等待（Waiting）：不会被分配处理器执行时间，等待被其他线程显式唤醒
- 没有设置Timeout参数的Object::wait()方法
- 没有设置Timeout参数的Thread::join()方法
- LockSupport::park()方法
限期等待（Timed Waiting）：不会被分配处理器执行时间，在一定时间之后由系统自动唤醒
- Thread::sleep()方法
- 设置了Timeout参数的Object::wait()方法
- 设置了Timeout参数的Thread::join()方法
- LockSupport::parkNanos()方法
- LockSupport::parkUntil()方法
阻塞（Blocked）：线程被阻塞了，等待着获取到一个排它锁，这个事件将在另外一个线程放弃这个锁的时候发生
结束（Terminated）：已终止线程的线程状态，线程已经结束执行
12.5 Java与协程
12.5.1 内核线程的局限
12.5.2 协程的复苏
协程（Coroutine）：用户线程设计成协同式调度（Cooperative Scheduling）
- 有栈协程（Stackfull Coroutine）：完整地做调用栈的保护、恢复工作
- 无栈协程（Stackless Coroutine）：各种语言中的await、async、yield这类关键字。本质上是一种有限状态机，状态保存在闭包里，比有栈协程恢复调用栈要轻量得多，但功能也相对更有限
特点：比传统内核线程要轻量，需要在应用层面实现的内容（调用栈、调度器）特别多