JVM 线程模型

引言

本文着重介绍 JVM 线程模型相关的内容,更多关于 JVM 的文章均收录于<JVM系列文章>

线程模型

我们知道,线程是比进程更轻量级的调度执行单元,而主流的操作系统都提供了线程的实现,Java 语言则提供了不同硬件和操作系统平台下对线程操作的统一抽象,每个执行了 start 函数且未结束的 java.lang.Thread 类实例就代表了一个线程。要想实现线程,主要有 3 种方式:使用内核线程实现、使用用户线程实现、使用用户线程加轻量级进程混合实现。

可选方案

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

程序一般不会直接去使用内核线程, 而是去使用内核线程的一种高级接口————轻量级进程(Light Weight Process, LWP), 轻量级进程就是我们通常意义上所讲的线程, 由于每个轻量级进程都由一个内核线程支持。这种轻量级进程与内核线程之间 1:1 的关系称为一对一的线程模型, 如下图所示。
lwp-thread-mode
由于内核线程的支持, 每个轻量级进程都成为一个独立的调度单元, 即使有一个轻量级进程在系统调用中阻塞了, 也不会影响整个进程继续工作, 但是轻量级进程具有它的局限性:首先, 由于是基于内核线程实现的, 所以各种线程操作, 如创建、析构及同步, 都需要进行系统调用。而系统调用的代价相对较高, 需要在用户态和内核态中来回切换。其次, 每个轻量级进程都需要有一个内核线程的支持, 因此轻量级进程要消耗一定的内核资源(如内核线程的栈空间), 因此一个系统支持轻量级进程的数量是有限的。

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

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

Java 线程模型

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

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

在 Linux 中,我们可以通过 ps -L -p <pid> 来查看一个 Java 进程使用的所有轻量级进程。

1
2
3
4
5
6
7
8
ps -L -p 11522
PID LWP TTY TIME CMD
11522 11522 ? 00:00:00 java
11522 11525 ? 00:00:09 java
11522 11526 ? 00:00:31 java
11522 11527 ? 00:00:32 java
11522 11528 ? 00:00:32 java
...

线程调度

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

如果使用协同式调度的多线程系统, 线程的执行时间由线程本身来控制, 线程把自己的工作执行完了之后, 要主动通知系统切换到另外一个线程上。协同式多线程的最大好处是实现简单, 而且由于线程要把自己的事情干完后才会进行线程切换, 切换操作对线程自己是可知的, 所以没有什么线程同步的问题。它的坏处也很明显: 线程执行时间不可控制, 甚至如果一个线程编写有问题, 一直不告知系统进行线程切换, 那么程序就会一直阻塞在那里。

如果使用抢占式调度的多线程系统, 那么每个线程将由系统来分配执行时间, 线程的切换不由线程本身来决定。在这种实现线程调度的方式下, 线程的执行时间是系统可控的, 也不会有一个线程导致整个进程阻塞的问题, Java 使用的线程调度方式就是抢占式调度。

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

不过, 线程优先级并不是太靠谱, 原因是 Java 的线程是通过映射到系统的原生线程上来实现的, 所以线程调度最终还是取决于操作系统, 虽然现在很多操作系统都提供线程优先级的概念, 但是并不见得能与 Java 线程的优先级一一对应, 如 Windows 中就只有 7 种, 这就比 Java 线程优先级少, 所以不得不出现几个优先级相同的情况了。

线程状态

Java 语言定义了 6 种线程状态, 在任意一个时间点, 一个线程只能有且只有其中的一种状态, 这 6 种状态分别如下。
新建(New): 创建后尚未启动的线程处于这种状态。
运行(Runable): Runable 包括了操作系统线程状态中的 Running 和 Ready, 也就是处于此状态的线程有可能正在执行, 也有可能正在等待着 CPU 为它分配执行时间。
无限期等待(Waiting): 处于这种状态的线程不会被分配 CPU 执行时间, 它们要等待被其他线程显式地唤醒。以下方法会让线程陷入无限期的等待状态:

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

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

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

阻塞(Blocked): 线程被阻塞了,“阻塞状态”与“等待状态”的区别是: “阻塞状态”在等待着获取到一个排他锁, 这个事件将在另外一个线程放弃这个锁的时候发生; 而“等待状态“则是在等待一段时间, 或者唤醒动作的发生。在程序等待进入同步区域的时候, 线程将进入这种状态。
结束(Terminated): 已终止线程的线程状态, 线程已经结束执行。

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

参考内容

[1]《实战 Java 虚拟机》
[2]《深入理解 Java 虚拟机》
[3] GC复制算法和标记-压缩算法的疑问
[4] Java中什么样的对象才能作为gc root,gc roots有哪些呢?
[5] concurrent-mark-and-sweep
[6] 关于 -XX:+CMSScavengeBeforeRemark,是否违背cms的设计初衷?
[7] Java Hotspot G1 GC的一些关键技术
[8] Java 垃圾回收权威指北
[9] [HotSpot VM] 请教G1算法的原理
[10] [HotSpot VM] 关于incremental update与SATB的一点理解
[11] Java线程的6种状态及切换
[12] Java 8 动态类型语言Lambda表达式实现原理分析
[13] Java 8 Lambda 揭秘
[14] 字节码增强技术探索
[15] 不可不说的Java“锁”事
[16] 死磕Synchronized底层实现–概论
[17] 死磕Synchronized底层实现–偏向锁
[18] 死磕Synchronized底层实现–轻量级锁
[19] 死磕Synchronized底层实现–重量级锁

贝克街的流浪猫 wechat
您的打赏将鼓励我继续分享!
  • 本文作者: 贝克街的流浪猫
  • 本文链接: https://www.beikejiedeliulangmao.top/java/jvm/thread-model/
  • 版权声明: 本博客所有文章除特别声明外,均采用 BY-NC-SA 许可协议。转载请注明出处!
  • 创作声明: 本文基于上述所有参考内容进行创作,其中可能涉及复制、修改或者转换,图片均来自网络,如有侵权请联系我,我会第一时间进行删除。