thread之1：java与线程

一、线程的实现方式

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

1. 内核线程实现

内核线程（KLT）就是直接有操作系统内核支持的线程，这种线程由内核来完成线程切换，内核通过操作调度器对线程进行调度，并负责将线程的任务映射到各个处理器上。每个内核线程可以视为内核的一个分身，这样操作系统就有能力同时处理多件事情，支持多线程的内核成为多线程内核
程序一般不会直接使用内核线程，而是使用内核线程的一种高级接口-轻量级进程（通常意义上的线程），由于每个轻量级进程都是由一个内核线程支持，这种轻量级进程与内核线程之间的1：1关系成为一对一的线程模型。

轻量级进程是一个独立的调度单元。
局限性：
1. 各种线程操作，如创建、析构、同步，都需要进行系统调用，而系统调用代价相对交过，需要在用户态和内核态切换
2. 每个轻量级进程都需要有一个内核线程的支持，因此轻量级进程要消耗一定的内核资源（如内核线程的栈空间），因此一个系统支持轻量级进程的数量是有限的

2. 用户线程实现

广义讲，只要不是内核线程都是用户线程
狭义讲，完全建立在用户空间的线程库上，系统内核感知不到用户线程的存在以及实现。用户线程的建立同步销毁调度完全在用户态完成，不需要内核的帮助。
优势：因为不需要切换到内核态，因此操作非常快且低消耗，也能支持更大规模的线程数量
劣势：实现复杂，例如阻塞问题处理

3. 用户线程加轻量级进程混合实现

用户线程与内核线程共存。

二、 java线程的实现

JDK1.3 以后，主流平台上的主流商用java虚拟机普遍使用基于操作系统原生线程模型来实现，即采用1：1的线程模型，例如hotspot
以HotSpot为例，它的每一个Java线程都是直接映射到一个操作系统原生线程来实现的，而且中间没有额外的间接结构，所以Hotspot不干涉线程调度，全权交给操作系统处理，包括冻结线程、唤醒线程、执行时间分配、线程具体交给哪个处理器核心去执行，都是操作系统决定的。

三、java线程调度

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

1.协同式线程调度

线程自己的工作执行完成之后，要主动通知系统切换到另一个线程。
优势：实现简单，切换可知，无同步问题
劣势：线程实现时间不可控，如果一个进程坚持不让出处理器的执行时间，就可能导致整个系统崩溃

2.抢占式线程调度（java采用该调度方式）

由操作系统分配每个线程的执行时间，线程的切换不由线程本身来决定。
优势：不会因为一个线程导致整个进程或系统崩溃

碧如在java中，有Thread::yield()方法可以主动让出执行时间，但是如果想要主动获取执行时间，线程本身是没有办法的。在这种实现（抢占式调度）线程调度的方式下，线程的执行时间是系统可控的，也不会有一个线程导致整个进程甚至整个系统阻塞的问题。

java线程优先级

java线程调度虽然由系统决定，但我们可以”建议“操作系统给某些线程多分配一点时间——通过设置线程优先级来实现。
该技术并不稳定
1. 主流虚拟机上的java线程是被映射到系统的远程线程来实现的，所以最终线程调度系统说了算。尽管操作系统也提供了线程优先级的概念，但不见得能与java线程优先级一一对应。当操作系统优先级少于java，那不同的java优先级会被映射为同一内核线程优先级。
2. 优先级可能会被系统自行改变。当某个线程被执行的特别频繁时，系统可能会越过优先级去为他分配执行时间，从而减少线程频繁切换而带来的性能损耗。

 10.为什么内核线程调度成本高？

内核线程调度成本主要来自于用户态与内核态之间的状态转换，而两种状态转换之间的开销主要来自于响应中断、保护和恢复执行现场的成本。
程序是代码和数据的结合体，代码执行时必须有上下文的支持，而这里的上下文，以程序员的角度讲，是方法调用过程中的各种局部变量与资源；以线程的角度看，是方法的调用栈中存储的各类信息；以操作系统和硬件的角度看，是存储在内存、缓存和寄存器中的一个个具体数值。
物理硬件的各种存储设备和寄存器是被操作系统内所有线程共享的资源，当中断发生，线程切换完成前，系统首先要把线程A的上下文数据妥善保管好，然后把寄存器、内存分页等恢复到线程B挂起时的状态，这样线程B被激活之后才能仿佛没有被挂起过，这样保护和恢复现场的工作，免不了涉及一系列数据在各种寄存器、缓存中的来回拷贝，当然不可能是轻量级的操作。 

java与协程

Java线程与系统内核线程

Java虚拟机使用的是KLT线程模型。Java线程创建依赖于系统内核，通过JVM调用系统库创建内核线程，内核线程与Java-Thread是1:1的映射关系。

• Java时代早期，涌现过无数多线程的应用与框架，譬如在网页访问时，HTTP请求可以直接与Servlet API中的一条处理线程绑定在一起，以“一对一服务”的方式处理由浏览器发来的信息

• 今天对Web应用的服务要求，不论是在请求数量上还是在复杂度上，与十多年前相比已不可同日而语，这一方面是源于业务量的增长，另一方面来自于为了应对业务复杂化而不断进行的服务细分。现代B/S系统中一次对外部业务请求的响应，往往需要分布在不同机器上的大量服务共同协作来实现，这种服务细分的架构在减少单个服务复杂度、增加复用性的同时，也不可避免地增加了服务的数量，缩短了留给每个服务的响应时间。这要求每一个服务都必须在极短的时间内完成计算，这样组合多个服务的总耗时才不会太长；也要求每一个服务提供者都要能同时处理数量更庞大的请求，这样才不会出现请求由于某个服务被阻塞而出现等待

• Java目前的并发编程机制就与上述架构趋势产生了一些矛盾，1：1的内核线程模型是如今Java虚拟机线程实现的主流选择，但是这种映射到操作系统上的线程天然的缺陷是切换、调度成本高昂，系统能容纳的线程数量也很有限。以前处理一个请求可以允许花费很长时间在单体应用中，具有这种线程切换的成本也是无伤大雅的，但现在在每个请求本身的执行时间变得很短、数量变得很多的前提下，用户线程切换的开销甚至可能会接近用于计算本身的开销，这就会造成严重的浪费

• 传统的Java Web服务器的线程池的容量通常在几十个到两百之间，当程序员把数以百万计的请求往线程池里面灌时，系统即使能处理得过来，但其中的切换损耗也是相当可观的。现实的需求在迫使Java去研究新的解决方案

• 内核线程的调度成本主要来自于用户态与核心态之间的状态转换，而这两种状态转换的开销主要来自于响应中断、保护和恢复执行现场的成本

• 如果说内核线程的切换开销是来自于保护和恢复现场的成本，那如果改为采用用户线程，这部分开销就能够省略掉吗？答案是“不能”。但是，一旦把保护、恢复现场及调度的工作从操作系统交到程序员手上，那我们就可以打开脑洞，通过玩出很多新的花样来缩减这些开销

  • 有一些古老的操作系统（譬如DOS）是单人单工作业形式的，天生就不支持多线程，自然也不会有多个调用栈这样的基础设施。而早在那样的蛮荒时代，就已经出现了今天被称为栈纠缠（Stack Twine）的、由用户自己模拟多线程、自己保护恢复现场的工作模式。其大致的原理是通过在内存里划出一片额外空间来模拟调用栈，只要其他“线程”中方法压栈、退栈时遵守规则，不破坏这片空间即可，这样多段代码执行时就会像相互缠绕着一样，非常形象

  • 到后来，操作系统开始提供多线程的支持，靠应用自己模拟多线程的做法自然是变少了许多，但也并没有完全消失，而是演化为用户线程继续存在。由于最初多数的用户线程是被设计成协同式调度（Cooperative Scheduling）的，所以它有了一个别名——“协程”（Coroutine）。又由于这时候的协程会完整地做调用栈的保护、恢复工作，所以今天也被称为“有栈协程”（StackfullCoroutine），起这样的名字是为了便于跟后来的“无栈协程”（Stackless Coroutine）区分开。无栈协程不是本节的主角，不过还是可以简单提一下它的典型应用，即各种语言中的await、async、yield这类关键字。无栈协程本质上是一种有限状态机，状态保存在闭包里，自然比有栈协程恢复调用栈要轻量得多，但功能也相对更有限

• 协程的主要优势是轻量，无论是有栈协程还是无栈协程，都要比传统内核线程要轻量得多

• 协程当然也有它的局限，需要在应用层面实现的内容（调用栈、调度器这些）特别多

• 协程在最初，甚至在今天很多语言和框架中会被设计成协同式调度，这样在语言运行平台或者框架上的调度器就可以做得非常简单。不过有不少资料上显示，既然取了“协程”这样的名字，它们之间就一定以协同调度的方式工作。笔者并没有查证到这种“规定”的出处，只能说这种提法在今天太过狭隘了，非协同式、可自定义调度的协程的例子并不少见

• 具体到Java语言，还会有一些别的限制，譬如HotSpot这样的虚拟机，Java调用栈跟本地调用栈是做在一起的。如果在协程中调用了本地方法，还能否正常切换协程而不影响整个线程？另外，如果协程中遇传统的线程同步措施会怎样？譬如Kotlin提供的协程实现，一旦遭遇synchronize关键字，那挂起来的仍将是整个线程

1. • 对于有栈协程，有一种特例实现名为纤程（Fiber），这个词最早是来自微软公司，后来微软还推出过系统层面的纤程包来方便应用做现场保存、恢复和纤程调度。OpenJDK在2018年创建了Loom项目，这是Java用来应对本节开篇所列场景的官方解决方案，根据目前公开的信息，如无意外，日后该项目为Java语言引入的、与现在线程模型平行的新并发编程机制中应该也会采用“纤程”这个名字，不过这显然跟微软是没有任何关系的。从Oracle官方对“什么是纤程”的解释里可以看出，它就是一种典型的有栈协程

     • what is a fiber?
     • A light weight or user model thread,scheduled by the Java virtual machine,not the operating system
     • Fibers are low footprint and have negligible task-switching overhead.You can have millions of them!

   • Loom项目背后的意图是重新提供对用户线程的支持，但与过去的绿色线程不同，这些新功能不是为了取代当前基于操作系统的线程实现，而是会有两个并发编程模型在Java虚拟机中并存，可以在程序中同时使用。新模型有意地保持了与目前线程模型相似的API设计，它们甚至可以拥有一个共同的基类，这样现有的代码就不需要为了使用纤程而进行过多改动，甚至不需要知道背后采用了哪个并发编程模型

   • Loom团队在JVMLS 2018大会上公布了他们对Jetty基于纤程改造后的测试结果，同样在5000QPS的压力下，以容量为400的线程池的传统模式和每个请求配以一个纤程的新并发处理模式进行对比，前者的请求响应延迟在10000至20000毫秒之间，而后者的延迟普遍在200毫秒以下

   • 在新并发模型下，一段使用纤程并发的代码会被分为两部分——执行过程（Continuation）和调度器（Scheduler）。执行过程主要用于维护执行现场，保护、恢复上下文状态，而调度器则负责编排所有要执行的代码的顺序。将调度程序与执行过程分离的好处是，用户可以选择自行控制其中的一个或者多个，而且Java中现有的调度器也可以被直接重用。事实上，Loom中默认的调度器就是原来已存在的用于任务分解的Fork/Join池（JDK 7中加入的ForkJoinPool）

   • Loom项目目前仍然在进行当中，还没有明确的发布日期，上面笔者介绍的内容日后都有被改动的可能。如果读者现在就想尝试协程，那可以在项目中使用Quasar协程库[插图]，这是一个不依赖Java虚拟机的独立实现的协程库。不依赖虚拟机来实现协程是完全可能的，Kotlin语言的协程就已经证明了这一点。Quasar的实现原理是字节码注入，在字节码层面对当前被调用函数中的所有局部变量进行保存和恢复。这种不依赖Java虚拟机的现场保护虽然能够工作，但很影响性能，对即时编译器的干扰也非常大，而且必须要求用户手动标注每一个函数是否会在协程上下文被调用，这些都是未来Loom项目要解决的问题