1.硬件的效率与一致性

计算机的存储设备与处理器的运算速度有着几个数量级的差距，不得不加入一层或多层高速缓存（Cache）来作为内存与处理器之间的缓冲。但引出了缓存一致性的问题。

共享内存多核系统：每个处理器都有自己的高速缓存，但又共享同一主内存

处理器可能会对输入代码进行乱序执行（Out-Of-Order Execution）优化，处理器会在计算之后将乱序执行的结果重组，保证该结果与顺序执行的结果是一致的，但并不保证程序中各个语句计算的先后顺序与输入代码中的顺序一致，因此如果存在一个计算任务依赖另外一个计算任务的中间结果，那么其顺序性并不能靠代码的先后顺序来保证。

Java虚拟机的即时编译器中也有指令重排序优化。

2.主内存与工作内存

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

其主要目的是定义程序中各种变量的访问规则，即虚拟机中把变量值存储到内存和从内存中取出变量值这样的底层细节。

实例字段、静态字段和构成数组对象的元素，但是不包括局部变量与方法参数，后者是线程私有的

Java内存模型规定所有的变量都存储在主内存（Main Memory）中。每条线程有自己的工作内存（Working Memory），线程的工作内存中保存被该线程使用的变量的主内存副本，线程对变量的所有操作（读取、赋值等）都必须在工作内存中进行，而不能直接读写主内存中的数据。不同的线程之间也无法直接访问对方工作内存中的变量，线程间变量值的传递均需要通过主内存来完成，

对象的引用、对象中某个在线程访问到的字段是可能被复制的，但不会把整个对象复制一次。

主内存、工作内存与Java内存区域中的Java堆、栈、方法区等并不是同一个层次的对内存的划分，这两者基本上是没有任何关系的。从更基础的层次上说，主内存直接对应于物理硬件的内存，而为了获取更好的运行速度，虚拟机可能会让工作内存优先存储于寄存器和高速缓存中。

3.内存间交互操作

Java虚拟机实现时保证下面提及的每一种操作都是原子的、不可再分的。

• lock（锁定）：作用于主内存的变量，把一个变量标识为一条线程独占的状态。
• unlock（解锁）：作用于主内存的变量，把一个处于锁定状态的变量释放出来，释放后的变量

才可以被其他线程锁定。

• read（读取）：作用于主内存的变量，把一个变量的值从主内存传输到线程的工作内存中，以

便随后的load动作使用。

• load（载入）：作用于工作内存的变量，把read操作从主内存中得到的变量值放入工作内存的

变量副本中。

• use（使用）：作用于工作内存的变量，把工作内存中一个变量的值传递给执行引擎，每当虚

拟机遇到一个需要使用变量的值的字节码指令时将会执行这个操作。

• assign（赋值）：作用于工作内存的变量，它把一个从执行引擎接收的值赋给工作内存的变量，

每当虚拟机遇到一个给变量赋值的字节码指令时执行这个操作。

• store（存储）：作用于工作内存的变量，它把工作内存中一个变量的值传送到主内存中，以便随

后的write操作使用。

• write（写入）：作用于主内存的变量，把store操作从工作内存中得到的变量的值放入主内存的

变量中。

在执行上述8种基本操作时必须满足如下规则：

• read和load操作,store和write操作必须按顺序执行，但不要求是连续执行。
• 不允许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操作）。

4.对于volatile型变量的特殊规则

对instance变量赋值

通过对比，关键变化在于有volatile修饰的变量，赋值后（前面mov%eax，0x150(%esi)这句便是赋值操作）多执行了一个“lock addl$0x0，(%esp)”操作，这个操作相当于一个内存屏障，重排序时不能把后面的指令重排序到内存屏障之前的位置

指令中的“addl$0x0，(%esp)”（把ESP寄存器的值加0）是一个空操作，之所以用这个空操作而不是空操作专用指令nop，是因为IA32手册规定lock前缀不允许配合nop指令使用。作用是将本处理器的缓存写入内存，该写入动作也会引起别的处理器或者别的内核无效化（Invalidate）其缓存，这种操作相当于对缓存中的变量做了一次前面的“store和write”操作。

lock addl$0x0，(%esp)指令把修改同步到内存时，意味着所有之前的操作都已经执行完成，这样便形成了“指令重排序无法越过内存屏障”的效果。

满足如下规则：

• 只有当线程T对变量V执行的前一个动作是load的时候，线程T才能对变量V执行use动作；并且，

只有当线程T对变量V执行的后一个动作是use的时候，线程T才能对变量V执行load动作。线程T对 变量V的use动作可以认为是和线程T对变量V的load、read动作相关联的，必须连续且一起出现。

这条规则要求在工作内存中，每次使用V前都必须先从主内存刷新最新的值，用于保证能看见其

他线程对变量V所做的修改。

• 只有线程T对变量V执行的前一个动作是assign的时候，线程T才能对变量V执行store动作；并且，只有线程T对变量V执行的后一个动作是store的时候，线程T才能对变量V执行assign动作。线程T对变量V的assign动作可以认为和线程T对变量V的store、write动作相关联，必须连续且一起出现。

这条规则要求在工作内存中，每次修改V后都必须立刻同步回主内存中，用于保证其他线程可以

看到自己对变量V所做的修改。

• 假定动作A是线程T对变量V实施的use或assign动作，假定动作F是和动作A相关联的load或store动

作，假定动作P是和动作F相应的对变量V的read或write动作；与此类似，假定动作B是线程T对变量W实施的use或assign动作，假定动作G是和动作B相关联的load或store动作，假定动作Q是和动作G相应的对变量W的read或write动作。如果A先于B，那么P先于Q。这条规则要求volatile修饰的变量不会被指令重排序优化，从而保证代码的执行顺序与程序的顺序相同。

5.long和double型变量的特殊规则

Java内存模型要求八种操作都具有原子性，但是对于64位的数据类型（long和double），允许虚拟机将没有被volatile修饰的64位数据的读写操作划分为两次32位的操作来进行，即允许虚拟机实现自行选择是否要保证64位数据类型的load、store、read和write这四个操作的原子性，这就是“long和double的非原子性协定”（Non-Atomic Treatment of double and long Variables）。

6.原子性、可见性与有序性

Java内存模型是围绕着在并发过程中如何处理原子性、可见性和有序性这三个特征来建立的

1. 原子性（Atomicity）

Java内存模型来直接保证的原子性变量操作包括read、load、assign、use、store和write这六个，基本数据类型的访问、读写都是具备原子性的（例外就是long和double的非原子性协定）

2. 可见性（Visibility）

可见性就是指当一个线程修改了共享变量的值时，其他线程能够立即得知这个修改。Java内存模型是通过在变量修改后将新值同步回主内存，在变量读取前从主内存刷新变量值这种依赖主内存作为传递媒介的方式来实现可见性的。

synchronized和final也能实现可见性。

3. 有序性（Ordering）

Java程序中的有序性：如果在本线程内观察，所有的操作都是有序的；如果在一个线程中观察另一个线程，所有的操作都是无序的。前半句是指“线程内似表现为串行的语义”（Within-Thread As-If-SerialSemantics），后半句是指“指令重排序”现象和“工作内存与主内存同步延迟”现象。

volatile和synchronized两个关键字来保证线程之间操作的有序性，volatile关键字本身就禁止指令重排序的语义，而synchronized则是由“一个变量在同一个时刻只允许一条线程对其进行lock操作”这条规则获得的，这个规则决定了持有同一个锁的两个同步块只能串行地进入。

7.Java与线程

线程是比进程更轻量级的调度执行单位，可以把一个进程的资源分配和执行调度分开，各个线程既可以共享进程资源（内存地址、文件I/O等），又可以独立调度。目前线程是Java里面进行处理器资源调度的最基本单位

主流的操作系统都提供了线程实现，Java语言则提供了在不同硬件和操作系统平台下对线程操作

的统一处理，每个已经调用过start()方法且还未结束的java.lang.Thread类的实例就代表着一个线程。 Thread类与大部分的Java类库API有着显著差别，它的所有关键方法都被声明为Native。

实现线程主要有三种方式：内核线程实现（1:1实现），用户线程实现（1:N实现），用户线程加轻量级进程混合实现（N:M 实现）。

1. 内核线程实现

使用内核线程实现（Kernel-Level Thread，KLT），由内核来完成线程切换，内核通过操纵调度器（Scheduler）对线程进行调度，并负责将线程的任务映射到各个处理器上。程序一般不会直接使用内核线程，而是使用内核线程的一种高级接口——轻量级进程（LightWeight Process，LWP），轻量级进程就是通常意义上所讲的线程，由于每个轻量级进程都由一个内核线程支持，因此只有先支持内核线程，才能有轻量级进程。这种轻量级进程与内核线程之间1：1的关系称为一对一的线程模型

局限性：

由于是基于内核线程实现的，所以各种线程操作，如创建、析构及同步，都需要进行系统调用。需要在用户态（User Mode）和内核态（Kernel Mode）中来回切换。其次，每个轻量级进程都需要有一个内核线程的支持，因此轻量级进程要消耗一定的内核资源（如内核线程的栈空间），因此一个系统支持轻量级进程的数量是有限的

2. 用户线程实现

广义上来讲，一个线程只要不是内核线程，都可以认为是用户线程（User Thread，UT）的一种

狭义上的用户线程指的是完全建立在用户空间的线程库上，系统内核不能感知到用户线程的存在及如何实现的。用户线程的建立、同步、销毁和调度完全在用户态中完成，不需要内核的帮助。

用户线程的优势在于不需要系统内核支援，劣势也在于没有系统内核的支援，所有的线程操作都

需要由用户程序自己去处理。线程的创建、销毁、切换和调度都是用户必须考虑的问题，而且由于操

作系统只把处理器资源分配到进程，那诸如“阻塞如何处理”“多处理器系统中如何将线程映射到其他处

理器上”这类问题解决起来将会异常困难，甚至有些是不可能实现的。因为使用用户线程实现的程序通

常都比较复杂，除了有明确的需求外（譬如以前在不支持多线程的操作系统中的多线程程序、需要

支持大规模线程数量的应用），一般的应用程序都不倾向使用用户线程。

3. 混合实现

在这种混合实现下，既存在用户线程，也存在轻量级进程。用户线程还是完全建立在用户空间中，因此用户线程的创建、切换、析构等操作依然廉价，并且可以支持大规模的用户线程并发。而操作系统支持的轻量级进程则作为用户线程和内核线程之间的桥梁，这样可以使用内核提供的线程调度功能及处理器映射。用户线程与轻量级进程的数量比是不定的，是N：M 的关系，

4. Java线程的实现

Java线程如何实现不受Java虚拟机规范的约束，与具体虚拟机相关。Java线程在早期的Classic虚拟机上（JDK 1.2以前），是基于一种被称为“绿色线程”（Green Threads）的用户线程实现的，但从JDK 1.3起，“主流”平台上的“主流”商用Java虚拟机的线程模型普遍都被替换为基于操作系统原生线程模型来实现，即采用1：1的线程模型。

以HotSpot为例，它的每一个Java线程都是直接映射到一个操作系统原生线程来实现的，而且中间没有额外的间接结构，所以HotSpot自己是不会去干涉线程调度的（可以设置线程优先级）

5. Java线程调度

线程调度是指系统为线程分配处理器使用权的过程，主要有两种，分别是协同式线程调度和抢占式线程调度。

协同式调度的多线程系统，线程的执行时间由线程本身来控制，线程把自己的工作执行完了之后，要主动通知系统切换到另外一个线程上去。协同式多线程的最大好处是实现简单，切换操作对线程自己是可知的，一般没有什么线程同步的问题。坏处：线程执行时间不可控制。

抢占式调度的多线程系统，每个线程将由系统来分配执行时间。线程的执行时间是系统可控的，不会有一个线程导致整个进程甚至整个系统阻塞的问题。Java使用的线程调度方式就是抢占式调度。

Java语言设置10个级别的线程优先级（Thread.MIN_PRIORITY至Thread.MAX_PRIORITY）。在两个线程同时处于Ready状态时，优先级越高的线程越容易被系统选择执行。

线程优先级不是一项稳定的调节手段除了无法一一对应外，还有优先级可能会被系统自行改变，例如在Windows系统中存在一个叫“优先级推进器”的功能。

8.Java与协程

内核线程的局限

1：1的内核线程模型是如今Java虚拟机线程实现的主流选择，但是这种映射到操作系统上的线程天然的缺陷是切换、调度成本高昂，系统能容纳的线程数量也很有限。传统的Java Web服务器的线程池的容量通常在几十个到两百之间，当程序员把数以百万计的请求往线程池里面灌时，系统即使能处理得过来，但其中的切换损耗也是相当可观的。

内核线程的调度成本主要来自于用户态与核心态之间的状态转换，而这两种状态转换的开销主要

来自于响应中断、保护和恢复执行现场的成本。