1 硬件的效率与一致性

由于计算机的存储设备与处理器的运算速度有几个数量级的差距， 所以现代计算机系统都不得不加入一层读写速度尽可能接近处理器运算速度的高速缓存 （Cache）来作为内存与处理器之间的缓冲：将运算需要使用到的数据复制到缓存中，让运 算能快速进行，当运算结束后再从缓存同步回内存之中，这样处理器就无须等待缓慢的内存 读写了。
基于高速缓存的存储交互很好地解决了处理器与内存的速度矛盾，但是也为计算机系统 带来更高的复杂度，因为它引入了一个新的问题：缓存一致性（Cache Coherence）。在多处 理器系统中，每个处理器都有自己的高速缓存，而它们又共享同一主内存（Main Memory），如图12-1所示。当多个处理器的运算任务都涉及同一块主内存区域时，将可能导 致各自的缓存数据不一致，如果真的发生这种情况，那同步回到主内存时以谁的缓存数据为 准呢？为了解决一致性的问题，需要各个处理器访问缓存时都遵循一些协议，在读写时要根 据协议来进行操作，这类协议有MSI、MESI（Illinois Protocol）、MOSI、Synapse、Firefly及 Dragon Protocol等。在本章中将会多次提到的“内存模型”一词，可以理解为在特定的操作协 议下，对特定的内存或高速缓存进行读写访问的过程抽象。不同架构的物理机器可以拥有不 一样的内存模型，而Java虚拟机也有自己的内存模型，并且这里介绍的内存访问操作与硬件 的缓存访问操作具有很高的可比性。
image.png
除了增加高速缓存之外，为了使得处理器内部的运算单元能尽量被充分利用，处理器可 能会对输入代码进行乱序执行（Out-Of-Order Execution）优化，处理器会在计算之后将乱序 执行的结果重组，保证该结果与顺序执行的结果是一致的，但并不保证程序中各个语句计算 的先后顺序与输入代码中的顺序一致，因此，如果存在一个计算任务依赖另外一个计算任务 的中间结果，那么其顺序性并不能靠代码的先后顺序来保证。与处理器的乱序执行优化类 似，Java虚拟机的即时编译器中也有类似的指令重排序（Instruction Reorder）优化

2 JAVA内存模型

2.1 主内存与工作内存

Java内存模型的主要目标是定义程序中各个变量的访问规则，即在虚拟机中将变量存储 到内存和从内存中取出变量这样的底层细节。
此处的变量（Variables）与Java编程中所说的 变量有所区别，它包括了实例字段、静态字段和构成数组对象的元素，但不包括局部变量与 方法参数，因为后者是线程私有的[3]，不会被共享，自然就不会存在竞争问题。
Java内存模型规定了所有的变量都存储在主内存（Main Memory）中。线程的工作内存中保存了被该线程使用到的变量的主内存副本拷贝[4]，线程对变量的 所有操作（读取、赋值等）都必须在工作内存中进行，而不能直接读写主内存中的变量[5]。 不同的线程之间也无法直接访问对方工作内存中的变量，线程间变量值的传递均需要通过主 内存来完成，线程、主内存、工作内存三者的交互关系如图12-2所示。
image.png

2.2 内存间交互操作

image.png

2.3 对于volatile型变量的特殊规则

当一个变量定义为volatile之后，它将具备两种特性，第一是保证此变量对所有线程的可 见性，这里的“可见性”是指当一条线程修改了这个变量的值，新值对于其他线程来说是可以 立即得知的。
由于volatile变量只能保证可见性，在不符合以下两条规则的运算场景中，我们仍然要通 过加锁（使用synchronized或java.util.concurrent中的原子类）来保证原子性。

  • 运算结果并不依赖变量的当前值，或者能够确保只有单一的线程修改变量的值。
  • 变量不需要与其他的状态变量共同参与不变约束。

使用volatile变量的第二个语义是禁止指令重排序优化

2.4 对于long和double型变量的特殊规则

Java内存模型要求lock、unlock、read、load、assign、use、store、write这8个操作都具有 原子性，但是对于64位的数据类型（long和double），在模型中特别定义了一条相对宽松的 规定：允许虚拟机将没有被volatile修饰的64位数据的读写操作划分为两次32位的操作来进 行，即允许虚拟机实现选择可以不保证64位数据类型的load、store、read和write这4个操作的 原子性，这点就是所谓的long和double的非原子性协定（Nonatomic Treatment ofdouble and long Variables）。
不过这种读取到“半个变量”的情况非常罕见（在目前商用Java虚拟机中不会出现），因 为Java内存模型虽然允许虚拟机不把long和double变量的读写实现成原子操作，但允许虚拟机 选择把这些操作实现为具有原子性的操作，而且还“强烈建议”虚拟机这样实现。在实际开发 中，目前各种平台下的商用虚拟机几乎都选择把64位数据的读写操作作为原子操作来对待， 因此我们在编写代码时一般不需要把用到的long和double变量专门声明为volatile

2.5 原子性、可见性与有序性

原子性（Atomicity）：由Java内存模型来直接保证的原子性变量操作包括read、load、 assign、use、store和write，我们大致可以认为基本数据类型的访问读写是具备原子性的（例 外就是long和double的非原子性协定，读者只要知道这件事情就可以了，无须太过在意这些 几乎不会发生的例外情况）。
如果应用场景需要一个更大范围的原子性保证（经常会遇到），Java内存模型还提供了 lock和unlock操作来满足这种需求，尽管虚拟机未把lock和unlock操作直接开放给用户使用， 但是却提供了更高层次的字节码指令monitorenter和monitorexit来隐式地使用这两个操作，这 两个字节码指令反映到Java代码中就是同步块——synchronized关键字，因此在synchronized块 之间的操作也具备原子性。
可见性（Visibility）：可见性是指当一个线程修改了共享变量的值，其他线程能够立即 得知这个修改。上文在讲解volatile变量的时候我们已详细讨论过这一点。Java内存模型是通 过在变量修改后将新值同步回主内存，在变量读取前从主内存刷新变量值这种依赖主内存作 为传递媒介的方式来实现可见性的，无论是普通变量还是volatile变量都是如此，普通变量与 volatile变量的区别是，volatile的特殊规则保证了新值能立即同步到主内存，以及每次使用前 立即从主内存刷新。因此，可以说volatile保证了多线程操作时变量的可见性，而普通变量则 不能保证这一点。
除了volatile之外，Java还有两个关键字能实现可见性，即synchronized和final。同步块的 可见性是由“对一个变量执行unlock操作之前，必须先把此变量同步回主内存中（执行store、 write操作）”这条规则获得的，而final关键字的可见性是指：被final修饰的字段在构造器中一 旦初始化完成，并且构造器没有把“this”的引用传递出去（this引用逃逸是一件很危险的事 情，其他线程有可能通过这个引用访问到“初始化了一半”的对象），那在其他线程中就能看 见final字段的值。如代码清单12-7所示，变量i与j都具备可见性，它们无须同步就能被其他 线程正确访问。
有序性（Ordering）：Java内存模型的有序性在前面讲解volatile时也详细地讨论过 了，Java程序中天然的有序性可以总结为一句话：如果在本线程内观察，所有的操作都是有 序的；如果在一个线程中观察另一个线程，所有的操作都是无序的。前半句是指“线程内表 现为串行的语义”（Within-Thread As-If-Serial Semantics），后半句是指“指令重排序”现象 和“工作内存与主内存同步延迟”现象。
Java语言提供了volatile和synchronized两个关键字来保证线程之间操作的有序性，volatile 关键字本身就包含了禁止指令重排序的语义，而synchronized则是由“一个变量在同一个时刻 只允许一条线程对其进行lock操作”这条规则获得的，这条规则决定了持有同一个锁的两个同 步块只能串行地进入。
介绍完并发中3种重要的特性后，读者有没有发现synchronized关键字在需要这3种特性的 时候都可以作为其中一种的解决方案？看起来很“万能”吧。的确，大部分的并发控制操作都 能使用synchronized来完成。synchronized的“万能”也间接造就了它被程序员滥用的局面， 越“万能”的并发控制，通常会伴随着越大的性能影响，这点我们将在第13章讲解虚拟机锁优 化时再介绍

2.6 先行发生原则

如果Java内存模型中所有的有序性都仅仅靠volatile和synchronized来完成，那么有一些操 作将会变得很烦琐，但是我们在编写Java并发代码的时候并没有感觉到这一点，这是因为 Java语言中有一个“先行发生”（happens-before）的原则。这个原则非常重要，它是判断数据 是否存在竞争、线程是否安全的主要依据，依靠这个原则，我们可以通过几条规则一揽子地 解决并发环境下两个操作之间是否可能存在冲突的所有问题。
现在就来看看“先行发生”原则指的是什么。先行发生是Java内存模型中定义的两项操作 之间的偏序关系，如果说操作A先行发生于操作B，其实就是说在发生操作B之前，操作A产 生的影响能被操作B观察到，“影响”包括修改了内存中共享变量的值、发送了消息、调用了 方法等。

3 JAVA与线程

实现线程主要有3种方式：使用内核线程实现、使用用户线程实现和使用用户线程加轻 量级进程混合实现。

3.1线程的实现

3.1.1 使用内核线程实现

内核线程（Kernel-Level Thread,KLT）就是直接由操作系统内核（Kernel，下称内核）支 持的线程，这种线程由内核来完成线程切换，内核通过操纵调度器（Scheduler）对线程进行 调度，并负责将线程的任务映射到各个处理器上。每个内核线程可以视为内核的一个分身， 这样操作系统就有能力同时处理多件事情，支持多线程的内核就叫做多线程内核（MultiThreads Kernel）。
程序一般不会直接去使用内核线程，而是去使用内核线程的一种高级接口——轻量级进 程（Light Weight Process,LWP），轻量级进程就是我们通常意义上所讲的线程，由于每个轻 量级进程都由一个内核线程支持，因此只有先支持内核线程，才能有轻量级进程。这种轻量 级进程与内核线程之间1:1的关系称为一对一的线程模型
image.png
由于内核线程的支持，每个轻量级进程都成为一个独立的调度单元，即使有一个轻量级 进程在系统调用中阻塞了，也不会影响整个进程继续工作，但是轻量级进程具有它的局限 性：首先，由于是基于内核线程实现的，所以各种线程操作，如创建、析构及同步，都需要 进行系统调用。而系统调用的代价相对较高，需要在用户态（User Mode）和内核态（Kernel Mode）中来回切换。其次，每个轻量级进程都需要有一个内核线程的支持，因此轻量级进 程要消耗一定的内核资源（如内核线程的栈空间），因此一个系统支持轻量级进程的数量是 有限的。

3.1.2 使用用户线程实现

从广义上来讲，一个线程只要不是内核线程，就可以认为是用户线程（User Thread,UT），因此，从这个定义上来讲，轻量级进程也属于用户线程，但轻量级进程的实 现始终是建立在内核之上的，许多操作都要进行系统调用，效率会受到限制。 而狭义上的用户线程指的是完全建立在用户空间的线程库上，系统内核不能感知线程存 在的实现。
用户线程的建立、同步、销毁和调度完全在用户态中完成，不需要内核的帮助。 如果程序实现得当，这种线程不需要切换到内核态，因此操作可以是非常快速且低消耗的， 也可以支持规模更大的线程数量，部分高性能数据库中的多线程就是由用户线程实现的。这 种进程与用户线程之间1：N的关系称为一对多的线程模型，如图12-4所示
image.png
使用用户线程的优势在于不需要系统内核支援，劣势也在于没有系统内核的支援，所有 的线程操作都需要用户程序自己处理。线程的创建、切换和调度都是需要考虑的问题，而且 由于操作系统只把处理器资源分配到进程，那诸如“阻塞如何处理”、“多处理器系统中如何 将线程映射到其他处理器上”这类问题解决起来将会异常困难，甚至不可能完成。因而使用 用户线程实现的程序一般都比较复杂[1]，除了以前在不支持多线程的操作系统中（如DOS） 的多线程程序与少数有特殊需求的程序外，现在使用用户线程的程序越来越少了，Java、 Ruby等语言都曾经使用过用户线程，最终又都放弃使用它。

3.1.3 使用用户线程加轻量级进程混合实现

线程除了依赖内核线程实现和完全由用户程序自己实现之外，还有一种将内核线程与用 户线程一起使用的实现方式。在这种混合实现下，既存在用户线程，也存在轻量级进程。用 户线程还是完全建立在用户空间中，因此用户线程的创建、切换、析构等操作依然廉价，并 且可以支持大规模的用户线程并发。而操作系统提供支持的轻量级进程则作为用户线程和内 核线程之间的桥梁，这样可以使用内核提供的线程调度功能及处理器映射，并且用户线程的 系统调用要通过轻量级线程来完成，大大降低了整个进程被完全阻塞的风险。在这种混合模 式中，用户线程与轻量级进程的数量比是不定的，即为N：M的关系，如图12-5所示，这种 就是多对多的线程模型。
image.png

3.1.4 JAVA线程的实现

3.2 Java线程调度

线程调度是指系统为线程分配处理器使用权的过程，主要调度方式有两种，分别是协同 式线程调度（Cooperative Threads-Scheduling）和抢占式线程调度（Preemptive Threads-Scheduling）。
如果使用协同式调度的多线程系统，线程的执行时间由线程本身来控制，线程把自己的 工作执行完了之后，要主动通知系统切换到另外一个线程上。协同式多线程的最大好处是实 现简单，而且由于线程要把自己的事情干完后才会进行线程切换，切换操作对线程自己是可 知的，所以没有什么线程同步的问题。Lua语言中的“协同例程”就是这类实现。它的坏处也 很明显：线程执行时间不可控制，甚至如果一个线程编写有问题，一直不告知系统进行线程 切换，那么程序就会一直阻塞在那里。很久以前的Windows 3.x系统就是使用协同式来实现 多进程多任务的，相当不稳定，一个进程坚持不让出CPU执行时间就可能会导致整个系统崩 溃。
如果使用抢占式调度的多线程系统，那么每个线程将由系统来分配执行时间，线程的切 换不由线程本身来决定（在Java中，Thread.yield（）可以让出执行时间，但是要获取执行时 间的话，线程本身是没有什么办法的）。在这种实现线程调度的方式下，线程的执行时间是 系统可控的，也不会有一个线程导致整个进程阻塞的问题，Java使用的线程调度方式就是抢 占式调度[1]。与前面所说的Windows 3.x的例子相对，在Windows 9x/NT内核中就是使用抢占 式来实现多进程的，当一个进程出了问题，我们还可以使用任务管理器把这个进程“杀掉”， 而不至于导致系统崩溃。
虽然Java线程调度是系统自动完成的，但是我们还是可以“建议”系统给某些线程多分配 一点执行时间，另外的一些线程则可以少分配一点——这项操作可以通过设置线程优先级来 完成。
不过，线程优先级并不是太靠谱。原因是Java的线程是通过映射到系统的原生线程上来 实现的，所以线程调度最终还是取决于操作系统。
例 如，在Windows系统中存在一个称为“优先级推进器”（Priority Boosting，当然它可以被关闭 掉）的功能，它的大致作用就是当系统发现一个线程执行得特别“勤奋努力”的话，可能会越 过线程优先级去为它分配执行时间。因此，我们不能在程序中通过优先级来完全准确地判断 一组状态都为Ready的线程将会先执行哪一个。

3.3 状态转换

Java语言定义了5种线程状态，在任意一个时间点，一个线程只能有且只有其中的一种 状态，这5种状态分别如下。

  • 新建（New）：创建后尚未启动的线程处于这种状态。
  • 运行（Runable）：Runable包括了操作系统线程状态中的Running和Ready，也就是处于此 状态的线程有可能正在执行，也有可能正在等待着CPU为它分配执行时间。
  • 无限期等待（Waiting）：处于这种状态的线程不会被分配CPU执行时间，它们要等待被 其他线程显式地唤醒。以下方法会让线程陷入无限期的等待状态：
    • 没有设置Timeout参数的Object.wait（）方法。
    • 没有设置Timeout参数的Thread.join（）方法。
    • LockSupport.park（）方法。
  • 限期等待（Timed Waiting）：处于这种状态的线程也不会被分配CPU执行时间，不过无 须等待被其他线程显式地唤醒，在一定时间之后它们会由系统自动唤醒。以下方法会让线程 进入限期等待状态：
    • Thread.sleep（）方法。
    • 设置了Timeout参数的Object.wait（）方法。
    • 设置了Timeout参数的Thread.join（）方法。
    • LockSupport.parkNanos（）方法。
    • LockSupport.parkUntil（）方法。
  • 阻塞（Blocked）：线程被阻塞了，“阻塞状态”与“等待状态”的区别是：“阻塞状态”在等 待着获取到一个排他锁，这个事件将在另外一个线程放弃这个锁的时候发生；而“等待状 态”则是在等待一段时间，或者唤醒动作的发生。在程序等待进入同步区域的时候，线程将 进入这种状态。
  • 结束（Terminated）：已终止线程的线程状态，线程已经结束执行。

上述5种状态在遇到特定事件发生的时候将会互相转换，它们的转换关系如图12-6所 示

image.png