Java与线程

Java与线程

摘录自《深入理解Java虚拟机》一书第十二章

一、线程的实现

实现线程主要有三种方式:

1. 使用内核线程实现（1:1实现)
2. 使用用户线程实现(1:N实现)
3. 使用用户线程加轻量级进程混合实现(N:M实现）

---

1.1 内核线程实现

  使用内核线程实现的方式也被称为1:1实现。内核线程(Kernel-Level Thread，KLT)就是直接由操作系统内核（Kernel，下称内核）支持的线程，这种线程由内核来完成线程切换，内核通过操纵调度器（Scheduler）对线程进行调度，并负责将线程的任务映射到各个处理器上。每个内核线程可以视为内核的一个分身，这样操作系统就有能力同时处理多件事情，支持多线程的内核就称为多线程内核(Multi-Threads Kernel) 。
程序一般不会直接使用内核线程，而是使用内核线程的一种高级接口——轻量级进程（LightWeight Process，LWP)，轻量级进程就是我们通常意义上所讲的线程，由于每个轻量级进程都由一个内核线程支持，因此只有先支持内核线程，才能有轻量级进程。这种轻量级进程与内核线程之间1: 1的关系称为一对一的线程模型，如图12-3所示。

轻量级线程的优点：

由于内核线程的支持，每个轻量级线程都是一个独立的调度单元，即使被阻塞也不会影响整个进程的工作

缺点：

• 基于内核线程实现，因此各种线程操作需要进行系统调用，在用户态和内核态间来回切换，代价较高
• 消耗内核资源（如内核线程的栈空间）

---

1.2 用户线程实现

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

优点：

不需要系统内核的支援，速度更快

缺点：

没有系统内核的支援，所有的线程操作都需要由用户程序自己去处理，难以处理一些相对复杂的问题，如阻塞处理、线程映射等等

---

1.3 混合实现

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

1.4 Java线程的实现

  但从JDK 1.3起，“主流”平台上的“主流”商用Java虚拟机的线程模型普遍都被替换为基于操作系统原生线程模型来实现，即采用1:1的线程模型。
  以HotSpot为例，它的每一个Java线程都是直接映射到一个操作系统原生线程来实现的，而且中间没有额外的间接结构，所以HotSpot自己是不会去干涉线程调度的（可以设置线程优先级给操作系统提供调度建议），全权交给底下的操作系统去处理，所以何时冻结或唤醒线程、该给线程分配多少处理器执行时间、该把线程安排给哪个处理器核心去执行等，都是由操作系统完成的，也都是由操作系统全权决定的。

二、Java线程调度

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

协同式调度：

• 线程执行时间由线程本身控制。线程执行完后，主动通知系统切换到另一线程上去
• 实现简单，由线程自己控制切换，易于实现线程同步
• 线程执行时间不可控，线程若长期占有处理器，容易造成阻塞

抢占式调度

• 线程由系统来分配执行时间 ，线程的切换不由线程本身决定
• Java使用的就是抢占式调度方式

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

三、状态转换

  Java语言定义了6种线程状态，在任意一个时间点中，一个线程只能有且只有其中的一种状态，并且可以通过特定的方法在不同状态之间转换。这6种状态分别是:

• 新建(New)：创建后尚未启动的线程处于这种状态。
• 运行(Runnable)：包括操作系统线程状态中的Running和Ready，也就是处于此状态的线程有可能正在执行，也有可能正在等待着操作系统为它分配执行时间。
• 无限期等待(Waiting):处于这种状态的线程不会被分配处理器执行时间，它们要等待被其他线程显式唤醒。以下方法会让线程陷入无限期的等待状态:

• 没有设置Timeout参数的Object:.wait()方法;
• 没有设置Timeout参数的Thread:join()方法;
• mLockSupport::park(方法。

• 限期等待(Timed Waiting):处于这种状态的线程也不会被分配处理器执行时间，不过无须等待被其他线程显式唤醒，在一定时间之后它们会由系统自动唤醒。以下方法会让线程进入限期等待状态:

• Thread::sleep()方法；
• 设置了Timeout参数的Object::wait()方法;
• 设置了Timeout参数的Thread:.join()方法;
• LockSupport::parkNanos()方法;
• LockSupport:parkUntil()方法

• 阻塞（Blocked):线程被阻塞了，“阻塞状态”与“等待状态”的区别是“阻塞状态”在等待着获取到一个排它锁，这个事件将在另外一个线程放弃这个锁的时候发生;而“等待状态”则是在等待一段时间，或者唤醒动作的发生。在程序等待进入同步区域的时候，线程将进入这种状态。
• 结束(Terminated):已终止线程的线程状态，线程已经结束执行
  上述6种状态在遇到特定事件发生的时候将会互相转换，它们的转换关系如图12-6所示。
  

四、Java与协程

4.1 内核线程的局限

  笔者可以通过一个具体场景来解释目前Java线程面临的困境。今天对Web应用的服务要求，不论是在请求数量上还是在复杂度上，与十多年前相比已不可同日而语，这一方面是源于业务量的增长，另一方面来自于为了应对业务复杂化而不断进行的服务细分。现代B/S系统中一次对外部业务请求的响应，往往需要分布在不同机器上的大量服务共同协作来实现，这种服务细分的架构在减少单个服务复杂度、增加复用性的同时，也不可避免地增加了服务的数量，缩短了留给每个服务的响应时间。这要求每一个服务都必须在极短的时间内完成计算，这样组合多个服务的总耗时才不会太长;也要求每一个服务提供者都要能同时处理数量更庞大的请求，这样才不会出现请求由于某个服务被阻塞而出现等待。
  Java目前的并发编程机制就与上述架构趋势产生了一些矛盾，1:
1的内核线程模型是如今Java虚拟机线程实现的主流选择，但是这种映射到操作系统上的线程天然的缺陷是切换、调度成本高昂，系统能容纳的线程数量也很有限。以前处理一个请求可以允许花费很长时间在单体应用中，具有这种线程切换的成本也是无伤大雅的，但现在在每个请求本身的执行时间变得很短、数量变得很多的前提下，用户线程切换的开销甚至可能会接近用于计算本身的开销，这就会造成严重的浪费。
  传统的Java Web服务器的线程池的容量通常在几十个到两百之间，当程序员把数以百万计的请求往线程池里面灌时，系统即使能处理得过来，但其中的切换损耗也是相当可观的。现实的需求在迫使Java去研究新的解决方案，同大家又开始怀念以前绿色线程的种种好处，绿色线程已随着Classic虚拟机的消失而被尘封到历史之中，它还会有重现天日的一天吗?

4.2 协程的复苏

  首先我们要理解一个问题：为什么内核线程调度切换起来成本要更高？
  内核线程的调度成本主要来自于用户态与和核心态之间的状态转换，其开销主要包括响应中断、保护和恢复执行现场的成本
  当发生中断，运行线程从线程A切换到线程B时，系统首先要把A的上下文数据保存好（包括方法调用过程中的各种局部变量和资源），然后再把寄存器、内存分页等恢复到B挂起时的状态
  虽然对于用户线程来说，这种保护和恢复现场的开销也是必要的，但由于切换工作由程序自己决定，自然有各种缩减开销的方法
  有一些古老的操作系统（譬如DOS〉是单人单工作业形式的，天生就不支持多线程，自然也不会有多个调用栈这样的基础设施。而早在那样的蛮荒时代，就已经出现了今天被称为栈纠缠(StackTwine)的、由用户自己模拟多线程、自己保护恢复现场的工作模式。其大致的原理是通过在内存里划出一片额外空间来模拟调用栈，只要其他“线程”中方法压栈、退栈时遵守规则，不破坏这片空间即可，这样多段代码执行时就会像相互缠绕着一样，非常形象。
  到后来，操作系统开始提供多线程的支持，靠应用自己模拟多线程的做法自然是变少了许多，但也并没有完全消失，而是演化为用户线程继续存在。由于最初多数的用户线程是被设计成协同式调度(Cooperative Scheduling)的，所以它有了一个别名——“协程”(Coroutine)。又由于这时候的协程会完整地做调用栈的保护、恢复工作，所以今天也被称为“有栈协程”(Stackfull Coroutine)，起这样的名字是为了便于跟后来的“无栈协程”(Stackless Coroutine〉区分开。无栈协程不是本节的主角，不过还是可以简单提一下它的典型应用，即各种语言中的await、async、yield这类关键字。无栈协程本质上是一种有限状态机，状态保存在闭包里，自然比有栈协程恢复调用栈要轻量得多，但功能也相对更有限。
  协程非常轻量级，但需要在应用层面实现的内容（调用栈、调度器等）非常多，并且也具备一些协同式调度固有的缺点

4.3 Java的解决方案

  对于有栈协程，有一种特例实现名为纤程（Fiber)，这个词最早是来自微软公司，后来微软还推出过系统层面的纤程包来方便应用做现场保存、恢复和纤程调度。OpenJDK在2018年创建了Loom项目，这是Java用来应对本节开篇所列场景的官方解决方案，根据目前公开的信息，如无意外，日后该项目为Java语言引入的、与现在线程模型平行的新并发编程机制中应该也会采用“纤程”这个名字，不过这显然跟微软是没有任何关系的。
  Loom项目背后的意图是重新提供对用户线程的支持，但与过去的绿色线程不同，这些新功能不是为了取代当前基于操作系统的线程实现，而是会有两个并发编程模型在Java虚拟机中并存，可以在程序中同时使用。新模型有意地保持了与目前线程模型相似的API设计，它们甚至可以拥有一个共同的基类，这样现有的代码就不需要为了使用纤程而进行过多改动，甚至不需要知道背后采用了哪个并发编程模型。Loom团队在JVMLS2018大会上公布了他们对Jetty基于纤程改造后的测试结果，同样在5000QPS的压力下，以容量为400的线程池的传统模式和每个请求配以一个纤程的新并发处理模式进行对比，前者的请求响应延迟在10000至20000毫秒之间，而后者的延迟普遍在200毫秒以下，具体结果如图12-8所示。
在新并发模型下，一段使用纤程并发的代码会被分为两部分——执行过程(Continuation)和调度器(Scheduler）。执行过程主要用于维护执行现场，保护、恢复上下文状态，而调度器则负责编排所有要执行的代码的顺序。将调度程序与执行过程分离的好处是，用户可以选择自行控制其中的一个或者多个，而且Java中现有的调度器也可以被直接重用。事实上，Loom中默认的调度器就是原来已存在的用于任务分解的Fork/Join池（JDK 7中加入的ForkJoinPool)。