一个 Java 程序从 main() 方法开始执行，然后按照既定的代码逻辑执行，看似没有其他线程参与，但实际上 Java 程序天生就是多线程程序，因为执行 main() 方法的是一个名称为 main 的线程。我们通过一段代码看下一个普通的 Java 程序包含哪些线程。
public class thread {
public static void main(String[] args) {
// 获取Java线程管理
ThreadMXBean threadMXBean = ManagementFactory.getThreadMXBean();
// 仅获取线程和线程堆栈信息
ThreadInfo[] threadInfos = threadMXBean.dumpAllThreads(false, false);
// 遍历线程信息，仅仅打印线程 ID 和线程名称信息
for (ThreadInfo threadInfo : threadInfos) {
System.out.println("[" + threadInfo.getThreadId() + "]" + threadInfo.getThreadName());
}
}
}图片
可以看到，一个 Java 程序的运行不仅仅是 main() 方法的运行，而是 main 线程和多个其他线程的同时运行。
线程的实现
主流的操作系统都提供了线程实现。Java 语言则提供了在不同硬件和操作系统平台下对线程操作统一处理的能力。在 Java 中，每个已经执行 start() 方法且尚未结束的 java.lang.Thread 类的实例代表一个线程。
查看 JDK 的 Thread 类可以看到 Thread 类与大部分 Java API 有明显的差异，它的关键方法都被声明为 Native。在 Java API 中，Native 方法通常意味着该方法没有使用或无法使用平台无关的手段来实现（说明需要操作的是很底层的东西了，已经脱离了 Java 语言层面的范畴）。
图片
实现线程主要有 3 种方式：使用内核线程实现（ 1:1 实现）、使用用户线程实现（ N:1 实现）和使用用户线程加轻量级进程混合实现（ N:M 实现）。
1、内核线程实现（1:1实现）
内核线程（Kernel-Level Thread, KLT）是由操作系统内核直接支持的线程，内核通过操纵调度器（Scheduler）对线程进行调度，并负责将线程的任务映射到各个处理器上。下图中 KLT 线程上面都有一个 LWP 与之对应，每个内核线程可以视为内核的一个分身，这样操作系统就能够同时处理多个任务，从而支持多线程。
程序一般不会直接使用内核线程，而是使用内核线程的一种高级接口——轻量级进程（Light Weight Process, LWP）。轻量级进程是我们通常所说的线程，由于每个轻量级进程都由一个内核线程支持，因此只有先支持内核线程，才能有轻量级进程。轻量级进程与内核线程之间是一对一的关系，称为一对一的线程模型。
由于内核线程的支持，每个轻量级进程都成为一个独立的调度单元，即使有一个轻量级进程在系统调用中阻塞了，也不会影响整个进程继续工作。但轻量级进程也有一些局限性：由于是基于内核线程实现的，各种线程操作，如创建、析构及同步，都需要进行系统调用。而系统调用的代价相对较高，需要在用户态（User Mode）和内核态（Kernel Mode）之间来回切换。其次，每个轻量级进程都需要有一个内核线程的支持，因此轻量级进程要消耗一定的内核资源（例如内核线程的栈空间），因此一个系统支持轻量级进程的数量是有限的。
图片
轻量级进程与内核线程之间1:1的示意图
2、用户线程实现（ N:1 实现）
用户线程是指完全建立在用户空间线程库之上的线程实现，系统内核对其不可感知。即所有的用户线程都会对应到一个内核线程中，用户线程的创建、同步、销毁和调度完全在用户空间中完成，无需内核的帮助。如果程序实现得当，这些线程无需切换到内核模式，从而实现快速且低开销的操作。它们还可以支持更多的线程数量，因此在高性能数据库等场景中经常使用用户线程。进程与用户线程之间的关系采用一对多的线程模型。
使用用户线程的优势在于不需要系统内核的支持。然而劣势在于它们也缺乏系统内核的支持，所有线程操作都需要用户程序自己处理。需要考虑线程创建、切换和调度等问题。在某一线程被阻塞时，会导致整个所属进程阻塞。Java 曾经使用过用户线程，但最终放弃了使用它们。但是比如 Golang、Erlang 等一些新的、以高并发为卖点的变成语言普遍支持了用户线程。
进程与用户线程之间N:1的关系示意图
3、用户线程加轻量级进程混合实现（ N:M 实现）
内核线程和用户线程结合的实现方式。在这种混合实现中，用户线程和轻量级进程同时存在。用户线程仍然完全建立在用户空间中，因此创建、切换和销毁用户线程的操作仍然是廉价的，并且可以同时支持大量的用户线程。操作系统提供对轻量级进程的支持，它们充当用户线程和内核线程之间的桥梁。这样可以利用内核提供的线程调度和处理器映射功能。用户线程的系统调用通过轻量级进程来处理，大大降低了整个进程被完全阻塞的风险。在这种混合模型中，用户线程和轻量级进程的比例可以变化，形成一个 N:M 的关系。
许多 UNIX 系列的操作系统都提供了 N:M 的线程模型实现。这些操作系统上的应用也相对更容易应用 N:M 的线程模型。
用户线程与轻量级进程之间N:M的关系示意图
Java 线程的实现
操作系统支持怎么样的线程模型，很大程度上会影响上面的 Java 虚拟机的线程是怎么映射的，JVM 规范里面没有规定，必须使用哪一种模型。线程模型主要影响线程的并发规模和操作成本，对于 Java 程序的编码和运行过程来说，这些差异都是透明的， Java 作为上层应用，其实是感知不到上面三种模型之间的区别的，即开发者无需关注具体的线程模型细节。
在 JDK 1.2 之前，Java 线程使用的是称为“绿色线程”（Green Threads）的用户级线程实现。但是在 JDK 1.3 起，线程模型被替换为基于操作系统原生线程模型的实现方式，即采用 1:1 的线程模型。
Java SE 最常用的 JVM 是 Oracle/Sun 研发的 HotSpot VM。在这个 JVM 的较新版本所支持的所有平台上，它都是使用 1:1 线程模型的——除了 Solaris 之外，它是个特例。也就是说一个 Java 线程是直接通过一个操作系统原生线程来实现的，中间并没有额外的间接结构。而且 HotSpot VM 自己也不干涉线程的调度，全权交给底下的 OS 去处理。
Java 线程调度
线程调度是指系统为线程分配处理器使用权的过程，主要调度方式有两种，分别是协同式线程调度（Cooperative Threads-Scheduling）和抢占式线程调度（Preemptive Threads-Scheduling）。
如果在多线程系统中使用协同式调度，每个线程的执行时间由线程自身控制。在完成工作后，线程需要主动通知系统切换到另一个线程。协同式多线程的主要优势在于简单性，由于线程切换由线程自身知晓，因此不存在线程同步问题。协同式调度也存在明显的缺点。线程的执行时间无法控制，如果一个线程出现问题并且没有通知系统切换线程，整个进程可能会无限期地被阻塞。
如果一个多线程系统采用抢占式调度，系统会为每个线程分配执行时间，线程切换不由线程自身决定（在 Java 中，Thread.yield() 可以让出执行时间，但线程本身无法控制获取执行时间）。在这种线程调度实现中，线程的执行时间由系统控制，不会出现一个线程阻塞整个进程的情况。Java 使用抢占式调度作为其线程调度机制。如果一个进程遇到问题，我们可以使用“任务管理器”终止该进程，而不会导致系统崩溃。
说到计算调度这里还要说一下 CPU 时间片
在单个处理器的时期，操作系统就能处理多线程并发任务。处理器给每个线程分配 CPU 时间片（Time Slice），线程在分配获得的时间片内执行任务。CPU 时间片是 CPU 分配给每个线程执行的时间段，一般为几十毫秒。在这么短的时间内线程互相切换，我们根本感觉不到，所以看上去就好像是同时进行的一样。
时间片决定了一个线程可以连续占用处理器运行的时长。当一个线程的时间片用完了，或者因自身原因被迫暂停运行了，这个时候，另外一个线程（可以是同一个线程或者其它进程的线程）就会被操作系统选中，来占用处理器。这种一个线程被暂停剥夺使用权，另外一个线程被选中开始或者继续运行的过程就叫做上下文切换。
上下文切换
当一个线程让出 CPU 时间片时，它需要记录下整个执行上下文，以便在恢复执行时从上次离开的地方继续。这包括变量、计算结果、程序计数器等等。就像是对线程的运行环境进行快照，这样当它重新获得 CPU 时间时，可以通过检索保存的数据快速恢复先前的执行上下文。这个过程被称为“上下文切换”。
在一个拥有多个 CPU 的系统中，操作系统以循环方式将 CPU 分配给不同的线程。这导致上下文切换更加频繁，特别是在跨不同 CPU 进行上下文切换时，比单个 CPU 内的上下文切换更加昂贵。
在操作系统中，上下文切换可以发生在进程之间或线程之间。在多线程编程的背景下，我们主要关注线程之间上下文切换的性能影响。现在，让我们探讨一下多线程中上下文切换的原因。但在此之前，让我们先了解一下系统线程的生命周期状态。
图片
系统线程主要有“新建”（NEW）、“就绪”（RUNNABLE）、“运行”（RUNNING）、“阻塞”（BLOCKED）、“死亡”（DEAD）五种状态。到了 Java 层面它们都被映射为了 NEW、RUNABLE、BLOCKED、WAITING、TIMED_WAITING、TERMINADTED 等 6 种状态。
在这个运行过程中，线程由 RUNNABLE 转为非 RUNNABLE 的过程就是线程上下文切换。一个线程的状态由 RUNNING 转为 BLOCKED ，再由 BLOCKED 转为 RUNNABLE ，然后再被调度器选中执行，这就是一个上下文切换的过程。多线程的上下文切换实际上就是由多线程两个运行状态的互相切换导致的。
那么在线程运行时，线程状态由 RUNNING 转为 BLOCKED 或者由 BLOCKED 转为 RUNNABLE，是怎么诱发的呢？
系统线程切换可以由多种情况下诱发，包括但不限于以下几种情况：
- 时间片耗尽：当一个线程的时间片用尽时，操作系统会强制切换到另一个线程，以确保公平地分配 CPU 时间给其他线程。
- 高优先级线程抢占：如果有一个优先级更高的线程需要执行，操作系统会中断当前线程的执行，并切换到优先级更高的线程。
- 阻塞操作：当一个线程执行阻塞操作（如等待 I/O 完成、等待锁释放等）时，操作系统会将该线程置于阻塞状态，并切换到其他可执行的线程，以充分利用 CPU 资源。
- 线程同步：当多个线程需要访问共享资源时，可能需要进行线程同步操作，如互斥锁、信号量等。在这种情况下，当一个线程获取到同步资源时，其他线程可能需要等待，从而引发线程切换。
- 中断处理：当一个硬件中断或软件中断发生时，操作系统会中断当前线程的执行，并转而处理中断事件，这可能导致线程切换。这些情况下，操作系统会根据调度算法和优先级规则来决定切换到哪个线程，并通过保存和恢复线程的上下文来实现线程切换。
我们可以分两种情况来分析，一种是程序本身触发的切换，这种我们称为自发性上下文切换，另一种是由系统或者虚拟机诱发的非自发性上下文切换。
接下来我们看一段代码，来对比串联执行和并发执行的速度
package com.yuyy.test;
public class DemoApplication {
public static void main(String[] args) {
// 运行多线程
MultiThreadTester test1 = new MultiThreadTester();
test1.Start();
// 运行单线程
SerialTester test2 = new SerialTester();
test2.Start();
}
static class MultiThreadTester extends ThreadContextSwitchTester {
@Override
public void Start() {
long start = System.currentTimeMillis();
MyRunnable myRunnable1 = new MyRunnable();
Thread[] threads = new Thread[4];
// 创建多个线程
for (int i = 0; i < 4; i++) {
threads[i] = new Thread(myRunnable1);
threads[i].start();
}
for (int i = 0; i < 4; i++) {
try {
// 等待一起运行完
threads[i].join();
} catch (InterruptedException e) {
e.printStackTrace();
}
}
long end = System.currentTimeMillis();
System.out.println("multi thread exec time: " + (end - start) + "s");
System.out.println("counter: " + counter);
}
// 创建一个实现Runnable的类
class MyRunnable implements Runnable {
public void run() {
while (counter < 100000000) {
synchronized (this) {
if(counter < 100000000) {
increaseCounter();
}
}
}
}
}
}
// 创建一个单线程
static class SerialTester extends ThreadContextSwitchTester{
@Override
public void Start() {
long start = System.currentTimeMillis();
for (long i = 0; i < count; i++) {
increaseCounter();
}
long end = System.currentTimeMillis();
System.out.println("serial exec time: " + (end - start) + "s");
System.out.println("counter: " + counter);
}
}
static abstract class ThreadContextSwitchTester {
public static final int count = 100000000;
public volatile int counter = 0;
public void increaseCounter() {
this.counter += 1;
}
public abstract void Start();
}
}执行之后，看一下两者的时间测试结果：串联的执行速度比并发的执行速度要快。这就是因为线程的上下文切换导致了额外的开销。
图片
线程的优先级
虽然 Java 线程调度由系统自动处理，但我们仍然可以“建议”系统为某些线程分配更多的执行时间，而为其他线程分配较少的执行时间。这可以通过设置线程优先级来实现。Java 语言提供了 10 个级别的线程优先级。当两个线程同时处于 Ready 状态时，优先级较高的线程更有可能被系统选择执行，其实就是让高优先级的线程获得更多的CPU 时间片。
设置优先级有助于”线程规划期“确定在下一次选择哪一个线程来优先执行，设置线程优先级使用 setPriority() 方法
图片
但是，线程优先级并不总是可靠的，因为 Java 线程最终是通过映射到底层操作系统的原生线程来实现的。因此，线程调度仍然取决于操作系统。尽管许多操作系统提供了线程优先级的概念，但它们不一定直接对应于 Java 线程优先级。例如，Solaris 拥有 2,147,483,648（2^32）个优先级级别，而 Windows 只有 7 个。如果操作系统的优先级级别多于 Java，将它们映射是相对简单的，可以在它们之间留下一些空位。然而，如果操作系统的优先级级别少于 Java，可能会出现多个优先级映射到同一级别的情况。
下图显示了 Java 线程优先级与 Windows 线程优先级之间的对应关系，不包括 THREAD_PRIORITY_IDLE，因为它在 Windows 平台的 JDK 中未使用。因此如果在 Java 程序中对两个线程设置的优先级分别是 3 和 4 那么对于Windows 来说他们的优先级还是一致的。还有例如 Windows 系统中存在一个叫做“优先级推进器”的功能，大致作用是当系统发现一个线程被执行的特别频繁的时候，可能会越过线程优先级去为它分配执行时间，从而减少线程频繁切换而带来的性能损耗。因此我们在程序中并不能判断同样为就绪状态且优先级一致的多个线程系统会先执行哪一个。
图片
总结
对于任何支持多线程的计算机语言来说，深入理解线程及写好多线程程序，都是一个巨大的挑战。本主要简述 Java 线程与操作系统线程之间的关系。java 中的线程和操作系统中的线程分别存在于虚拟机和操作系统中，一个 Java 线程是直接通过一个操作系统线程来实现的。其中还有很多值得深挖的点。大家有兴趣的话，可以仔细研究一下。
参考文档
深入理解Java虚拟机（第3版）
