Java 内存模型与线程

并发处理的广泛应用是 Amdahl 定律代替摩尔定律成为计算机性能发展源动力的原因。Amdahl 定律描述了处理器并行运算之后运行效率提升的情况，而摩尔定律表明了处理器晶体管数量与运行效率之间存在正相关性。这两个定律的更替代表了近年来硬件从追求处理器频率到追求多核心并行处理的发展过程。

概述

一个常见并发应用场景则是一个服务端同时给多个客户端提供服务。衡量一个服务性能的高低，每秒事务处理数（Transactions Per Second，TPS）是最重要的指标之一，它代表着一秒内服务端平均能响应的请求总数，而 TPS 与程序的并发能力又有着非常密切的关系。对于计算量相同的任务，线程并发协调得越有条不紊，效率自然会越高；反之，线程之间频繁阻塞甚至死锁，则会大大降低程序的并发能力。

多任务处理在现代计算机操作系统中几乎是一项必备的功能了。让计算机同时去做几件事情，不仅仅是因为计算机的运算能力变强了，还有一个很重要的原因是计算机的运算速度与它的存储和通信子系统速度间的差距太大，大量的时间都花费在磁盘 I/O、网络通信或者数据库访问上。如果不希望处理器在大部分时间里都处于等待其他资源的状态，就必须使用一些手段去把处理器的运算能力『压榨』出来。

硬件的效率与一致性

在正式讲解 Java 虚拟机并发相关的知识之前，我们先花费一点时间去了解一下物理计算机中的并发问题，物理机遇到的并发问题与虚拟机中的情况有不少相似之处，物理机对并发的处理方案对于虚拟机的实现也有相当大的参考意义。

『让计算机并发执行若干个运算任务』与『更好的提高计算机处理器效率』之间的因果关系，看起来顺理成章，实际上它们之间的关系并没有想象中的那么简单。其中一个重要的原因是绝大多数的运算任务都不可能只靠处理器『计算』就能完成，处理器至少要与内存交互，如读取运算数据、存储运算结果等，这个 I/O 操作是很难消除的。

缓存的作用

由于计算机的处理器与存储设备之间的运算速度有几个数量级的差距，所以现代计算机系统都不得不加入一层读写速度尽可能接近处理器运算速度的高速缓存来作为内存与处理器之间的缓冲：将运算需要使用到的数据复制到缓存中，让运算能快速进行；运算结束后再从缓存同步数据到内存中，这样处理器就无须等待缓慢的内存读写了。

基于高速缓存的存储交互很好地解决了处理器与内存的速度矛盾，但也为计算机系统带来更高的复杂度，因为它引入了一个新的问题：缓存一致性（Cache Coherence）。在多处理器系统中，每个处理器都有自己的高速缓存，而它们又共享同一主内存（Main Memory），如下图所示。

处理器、高速缓存、主存间的交互关系

当多个处理器的运算任务都涉及同一块主内存区域时，很可能导致各自的缓存数据不一致，如果真的发生这种情况，那同步数据到主内存时以谁的缓存数据为准呢？

为了解决一致性的问题，需要各个处理器访问缓存时都遵循一些协议，在读写时要根据协议来进行操作，这类协议有 MSI、MESI（Illinois Protocol）、MOSI、Synapse、Firefly 及 Dragon Protocol 等。

指令重排序

为了使处理器内部的运算单元被充分利用，除了增加高速缓存，处理器还可能对输入代码进行乱序执行（Out-Of-Order Execution）。处理器会将乱序执行的结果重组，保证该结果与顺序执行的结果是一致的，但并不保证程序中各个语句计算的先后顺序与源代码中的顺序保证一致。因此，如果存在一个计算任务依赖另外一个计算任务的中间结果，那么其顺序性并不能靠代码的先后顺序来保证。 与处理器的乱序执行优化类似，Java 虚拟机的即时编译器中也有类似的指令重排序（Instruction Reorder）优化。

Java 内存模型

『内存模型』是一种在特定的操作协议下、对特定的内存或高速缓存进行读写访问操作的抽象。 Java 虚拟机规范试图定义一种 Java 内存模型（Java Memory Model）来屏蔽掉各种硬件和操作系统的内存访问差异，以实现 Java 程序在各种平台下都能达到一致的内存访问效果。在此之前，主流程序语言（C/C++ 等）直接使用物理硬件和操作系统的内存模型。由于不同平台上内存模型的差异，可能导致程序在一套平台上并发访问正常，在另外一套平台上并发访问出错，因此在某些场景就必须针对不同的平台来编写程序。

定义 Java 内存模型并非一件容易的事情，这个模型必须足够严谨，才能让 Java 的并发内存访问操作不会产生歧义；但是，也必须足够宽松，使得虚拟机的实现有足够的自由空间去利用硬件的各种特性（寄存器、高速缓存和指令集中某些特有的指令）来获取更好的执行速度。经过长时间的验证和修补，在 JDK 1.5 发布后（实现了 JSR-133），Java 内存模型已经成熟和完善起来了。

主内存与工作内存

Java 内存模型主要是定义程序中各个变量的访问规则，即『虚拟机将变量存储到内存和从内存中取出来』这样的底层细节。此处的变量与 Java 编程中所说的变量有所区别，它包括了实例字段、静态字段和构成数组对象的元素，但不包括局部变量与方法参数，因为后者是线程私有的，不会被共享。

为了获得较好的执行效能，Java 内存模型并没有限制执行引擎使用处理器的特定寄存器或缓存来与主内存进行交互，也没有限制即时编译器进行代码执行顺序调整这类优化措施。

Java 内存模型规定了所有的变量都存储在主内存（Main Memory）中（此处的主内存与介绍物理硬件时的主内存名字一样，两者可以类比）。每条线程还有自己的工作内存（Working Memory，可与前面的高速缓存类比）。线程的工作内存中保存了被该线程使用到的变量的主内存副本，线程对变量的所有操作（读取、赋值等）都必须在工作内存中进行，不能直接读写主内存中的变量。不同线程之间也无法直接访问对方工作内存中的变量，线程之间变量值的传递需要通过主内存来完成。线程、工作内存、主内存三者的交互关系如下图所示。

线程、工作内存、主内存间的交互关系

线程

并发不一定要依赖多线程（如 PHP 中的多进程并发），但是在 Java 里面谈论并发，大多数都与线程脱不开关系。

线程的实现

我们知道，线程是比进程更轻量级的调度单位。线程的引入，可以把一个进程的资源分配和执行分开，各个线程既可以共享进程资源（内存地址、文件 I/O 等），又可以独立调度（线程是 CPU 调度的基本单位）。

主流的操作系统都提供了线程实现，Java 语言也提供了在不同操作系统下对线程操作的统一处理，每个已经执行 start 方法且还未结束的 java.lang.Thread 类的实例就代表了一个线程。我们注意到 Thread 类与大部分的 Java API 有显著的差别，它所有的关键方法都是声明为 Native。在 Java API 中，一个 Native 方法往往意味着这个方法没有使用与平台无关的手段来实现（当然也可能是为了执行效率而使用 Native 方法，不过，通常最有效率的手段也就是平台相关的手段）。

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

使用内核线程实现

内核线程（Kernel-Level Thread，KLT）就是直接由操作系统内核（Kernel，下称内核）支持的线程，这种线程由内核来完成线程切换，内核通过操纵调度器（Scheduler）对线程进行调度，并负责将线程的任务映射到各个处理器上。每个内核线程可以视为内核的一个分身，这样操作系统就有能力同时处理多件事情，支持多线程的内核就叫做多线程内核（Multi-Threads Kernel）。

程序一般不会直接使用内核线程，而是去使用内核线程的一种高级接口——轻量级进程（Light Weight Process，LWP），轻量级进程就是我们通常意义上所讲的线程，由于每个轻量级进程都由一个内核线程支持，因此只有先支持内核线程，才能有轻量级进程。这种轻量级进程与内核线程之间 1:1 的关系称为一对一的线程模型，如下图所示。

轻量级进程与内核线程之间 1:1 的关系

由于内核线程的支持，每个轻量级进程都成为一个独立的调度单元，即使有一个轻量级进程在系统调用中阻塞了，也不会影响整个进程继续工作。但是轻量级进程具有它的局限性：

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

使用用户线程实现

从广义上看，一个线程只要不是内核线程，就可以认为是用户线程（User Thread，UT）。从这个定义上来说，轻量级进程也属于用户线程，但轻量级进程的实现始终是建立在内核之上的，许多操作都要进行系统调用，效率会受到限制。

而狭义上的用户线程指的是完全建立在用户空间中、系统内核无法感知其存在的线程。用户线程的建立、同步、销毁和调度完全在用户态中完成，不需要内核的帮助。如果程序实现得当，这种线程不需要切换到内核态，因此操作可以是非常快速且低消耗的，也可以支持规模更大的线程数量，部分高性能数据库中的多线程就是由用户线程实现的。这种进程与用户线程之间 1:N 的关系称为一对多的线程模型，如图下图所示。

进程与用户线程之间 1:N 的关系

使用用户线程的优势在于不需要系统内核支援，劣势也在于没有系统内核的支援，所有的线程操作都需要用户程序自己处理。线程的创建、切换和调度都是需要考虑的问题，而且由于操作系统只把处理器资源分配到进程，那诸如『阻塞如何处理』、『多处理器系统中如何将线程映射到其他处理器上』这类问题解决起来将会异常困难，甚至不可能完成。因而使用用户线程实现的程序一般都比较复杂，除了以前在不支持多线程的操作系统中（如 DOS）的多线程程序与少数有特殊需求的程序外，现在使用用户线程的程序越来越少了，Java、Ruby 等语言都曾经使用过用户线程，但最终又都放弃使用它。

混合实现

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

许多 UNIX 系列的操作系统，如 Solaris、HP-UX 等都提供了 N:M 的线程模型实现。

用户线程与轻量级进程之间 N:M 的关系

Java 线程实现

对于 Sun JDK 来说，它的 Windows 版与 Linux 版都是使用一对一的线程模型实现的，一条 Java 线程就映射到一条轻量级进程之中（因为 Windows 和 Linux 系统提供的线程模型就是 1:1 的）。

Java 线程在 JDK 1.2 之前，是基于称为绿色线程（Green Threads）的用户线程实现的，而在 JDK 1.2 中，线程模型替换为基于操作系统原生线程模型来实现。因此，在目前的 JDK 版本中，操作系统支持怎样的线程模型，在很大程度上决定了 Java 虚拟机的线程是怎样映射的，这点在不同的平台上没有办法达成一致，因此在虚拟机规范中并未限定 Java 线程需要使用哪种线程模型来实现。线程模型只对线程的并发规模和操作成本产生影响，对 Java 程序的编码和运行过程来说，这些差异都是透明的。

Java 线程调度

线程调度是指系统为线程分配处理器使用权的过程，主要调度方式分两种：协同式线程调度（Cooperative Threads-Scheduling）和抢占式线程调度（Preemptive Threads-Scheduling）。

如果使用协同式调度的多线程系统，线程的执行时间由线程本身来控制，线程把自己的工作执行完了之后，要主动通知系统切换到另外一个线程上。协同式多线程的最大好处是实现简单，而且由于线程要把自己的事情干完后才会进行线程切换，切换操作对线程自己是可知的，所以没有什么线程同步的问题。Lua 语言中的『协同例程』就是这类实现。它的坏处也很明显：线程执行时间不可控制。甚至如果一个线程编写有问题，一直不告知系统进行线程切换，那么程序就会一直阻塞在那里。很久以前的 Windows 3.x 系统就是使用协同式来实现多进程多任务的，相当不稳定，一个进程坚持不让出 CPU 执行时间就可能会导致整个系统崩溃。

如果使用抢占式调度的多线程系统，那么每个线程将由系统来分配执行时间，线程的切换不由线程本身来决定（在 Java 中，Thread.yield 可以让出执行时间，但是要获取执行时间的话，线程本身是没有什么办法的）。在这种实现线程调度的方式下，线程的执行时间是系统可控的，也不会由于一个线程导致整个进程阻塞，Java 使用的线程调度方式就是抢占式调度。与前面所说的 Windows 3.x 的例子相对，在 Windows 9x/NT 内核中就是使用抢占式来实现多进程的，当一个进程出了问题，我们可以使用任务管理器把这个进程『杀掉』，而不至于导致系统崩溃。

虽然 Java 线程调度是系统自动完成的，但是我们可以『建议』系统给某些线程多分配一点执行时间，另外的一些线程则可以少分配一点——这项操作可以通过设置线程优先级来完成。Java 语言一共设置了 10 个级别的优先级（Thread.MIN_PRIORITY 至 Thread.MAX_PRIORITY），在两个线程同时处于 Ready 状态时，优先级越高的线程越容易被系统选择执行。

不过，Java 线程优先级并不是太靠谱，原因是 Java 线程是通过映射到系统的原生线程上来实现的，所以线程调度最终还是取决于操作系统，虽然现在很多操作系统都提供线程优先级的概念，但并不见得能与 Java 线程的优先级一一对应。如 Solaris 中有 2147483648（2³²）种优先级，但 Windows 中就只有 7 种，比 Java 线程优先级多的系统还好说，中间留下一点空位就可以了，但比 Java 线程优先级少的系统，就不得不出现几个优先级相同的情况了。下表显示了 Java 线程优先级与 Windows 线程优先级之间的对应关系，Windows 平台的 JDK 中使用了除 THREAD_PRIORITY_IDLE 之外的其余 6 种线程优先级。

Java 线程优先级与 Windows 线程优先级之间的对应关系

Java 线程优先级	Windows 线程优先级
1（Thread.MIN_PRIORITY）	THREAD_PRIORITY_LOWEST
2	THREAD_PRIORITY_LOWEST
3	THREAD_PRIORITY_BELOW_NORMAL
4	THREAD_PRIORITY_BELOW_NORMAL
5（Thread.NORM_PRIORITY）	THREAD_PRIORITY_NORMAL
6	THREAD_PRIORITY_ABOVE_NORMAL
7	THREAD_PRIORITY_ABOVE_NORMAL
8	THREAD_PRIORITY_HIGHEST
9	THREAD_PRIORITY_HIGHEST
10（Thread.MAX_PRIORITY）	THREAD_PRIORITY_CRITICAL

上文说到『Java 线程优先级并不是太靠谱』，不仅仅是说在一些平台上不同的线程优先级实际会变得相同这一点，还有其他情况让我们不能太依赖优先级：优先级可能会被系统自行改变。 例如，在 Windows 系统中存在一个称为『优先级推进器』（Priority Boosting，当然它可以被关闭掉）的功能，它的大致作用就是当系统发现一个线程执行得特别『勤奋努力』的话，可能会越过线程优先级去为它分配执行时间。因此，我们不能在程序中通过优先级来准确地判断一组状态都为 Ready 的线程将会先执行哪一个。

状态转化

Java 语言定义了 6 种线程状态（由 Thread 类内部枚举 State 定义），在任意一个时间点，一个线程只能有且只有其中的一种状态，这 6 种状态分别如下：

New：创建后尚未启动的线程处于这种状态。
RUNNABLE：包括了操作系统线程状态中的 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：已终止线程的线程状态，线程已经结束执行。

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

线程状态转换关系

小结

Java 内存模型和操作系统内存模型的有着类似的结构。Java 线程是基于内核线程和用户线程的混合使用来实现的。

引用

《深入理解 Java 虚拟机》