深入理解并发、线程与等待通知机制

最新推荐文章于 2024-10-09 11:13:12 发布

xue_520java

最新推荐文章于 2024-10-09 11:13:12 发布

阅读量91

点赞数

文章标签： java

本文链接：https://blog.csdn.net/wo82933418/article/details/133710550

版权

深入理解并发、线程与等待通知机制

一、开发中需要并发编程的重要性

(1)加快响应用户的时间

比如我们经常用的迅雷下载,都喜欢多开几个线程去下载,谁都不愿意用一个线程去下载,为什么呢?答案很简单,就是多个线程下载快啊。我们在做程序开发的时候更应该如此,特别是我们做互联网项目,网页的响应时间若提升 1s,如果流量大的话,就能增加不少转换量。做过高性能 web 前端调优的都知道,要将静态资源地址用两三个子域名去加载,为什么?因为每多一个子域名,浏览器在加载你的页面的时候就会多开几个线程去加载你的页面资源,提升网站的响应速度。

(2)使你的代码模块化,异步化,简单化

例如我们实现电商系统，下订单和给用户发送短信、邮件就可以进行拆分，将给用户发送短信、邮件这两个步骤独立为单独的模块，并交给其他线程去执行。这样既增加了异步的操作，提升了系统性能，又使程序模块化,清晰化和简单化。多线程应用开发的好处还有很多,大家在日后的代码编写过程中可以慢慢体会它的魅力。

(3)充分利用 CPU 的资源

目前市面上没有 CPU 的内核不是多核的，多核下如果还是使用单线程的技术做思路明显就 out 了，无法充分利用 CPU 的多核特点。如果设计一个多线程的程序的话,那它就可以同时在多个 CPU 的多个核的多个线程上跑，可以充分地利用 CPU,减少 CPU 的空闲时间,发挥它的运算能力,提高并发量。就像我们平时坐地铁一样,很多人坐长线地铁的时候都在认真看书,而不是为了坐地铁而坐地铁,到家了再去看书,这样你的时间就相当于有了两倍。这就是为什么有些人时间很充裕,而有些人老是说没时间的一个原因,工作也是这样,有的时候可以并发地去做几件事情,充分利用我们的时间,CPU 也是一样，也要充分利用。当然有同学会有疑问，单核 CPU 呢？单核 CPU 一样可以利用到并发编程的好处吗？当然可以，用我们平时常用的 QQ 之类的聊天程序来举例，当我们用 QQ 聊天时，其实程序要做好几件事，比如：接受我们的键盘输入，把输入的信息通过网络发给对方，接受对方通过网络发来的信息，把对方的信息显示在屏幕上，很多的时候，这些事情是可以同时发生的。如果程序不能利用并发编程同时处理，我们和对方的通话就只能一问一答的方式进行了。

二、怎么学习并发编程

1、从 0 开始深入理解并发、线程与等待通知机制

2、导致 JVM 内存泄露的 ThreadLocal 详解

3、并发编程之 CAS&Atomic 原子操作详解

4、一节课学透面试必问并发安全问题

5、JUC 并发工具类在大厂的应用场景详解

6、深入理解 AQS 之 ReentrantLock 源码分析

7、ReentrantReadWriteLock&StampLock 详解

8、并发容器（Map、List、Set）实战及其原理

9、阻塞队列 BlockingQueue 实战及其原理分析

10、线程池 ThreadPoolExecutor 实战及其原理分析

11、线程池 ForkJoinPool 工作原理分析

12、深入理解并发可见性、有序性、原子性与 JMM 内存模型

13、CPU 缓存架构详解&高性能内存队列 Disruptor 实战

14、常用并发设计模式精讲

可以看到并发编程的课时其实是相当多的，反过来也说明并发编程在 Java 程序员的技能栈中重要地位。

对于没有或者很少接触并发编程的同学，建议主要掌握并发里的基础概念、基础用法和并发工具类、并发容器的用法，章节主要对应第 1 ~ 5 章、第 8、9、 10、11。对于已经有较多并发编程经验建议全部学习，synchronized 底层原理则以知识小节的视频方式单独提供

三、基础概念

3.1 进程

我们常听说的是应用程序，也就是 app，由指令和数据组成。但是当我们不运行一个具体的 app 时，这些应用程序就是放在磁盘（也包括 U 盘、远程网络存储等等）上的一些二进制的代码。一旦我们运行这些应用程序，指令要运行，数据要读写，就必须将指令加载至 CPU，数据加载至内存。在指令运行过程中还需要用到磁盘、网络等设备，从这种角度来说，进程就是用来加载指令、管理内存、管理 IO 的。

当一个程序被运行，从磁盘加载这个程序的代码至内存，这时就开启了一个进程。

进程就可以视为程序的一个实例。大部分程序可以同时运行多个实例进程（例如记事本、画图、浏览器等），也有的程序只能启动一个实例进程（例如网易云音乐、360 安全卫士等）。显然,程序是死的、静态的,进程是活的、动态的。进程可以分为系统进程和用户进程。凡是用于完成操作系统的各种功能的进程就是系统进程,它们就是处于运行状态下的操作系统本身,用户进程就是所有由你启动的进程。

站在操作系统的角度，进程是程序运行资源分配（以内存为主）的最小单位。

3.2 线程

一个机器中肯定会运行很多的程序，CPU 又是有限的，怎么让有限的 CPU 运行这么多程序呢？就需要一种机制在程序之间进行协调，也就所谓 CPU 调度。线程则是 CPU 调度的最小单位。

线程必须依赖于进程而存在，线程是进程中的一个实体，是 CPU 调度和分派的基本单位，它是比进程更小的、能独立运行的基本单位。线程自己基本上不拥有系统资源,，只拥有在运行中必不可少的资源(如程序计数器,一组寄存器和栈), 但是它可与同属一个进程的其他的线程共享进程所拥有的全部资源。一个进程可以拥有多个线程，一个线程必须有一个父进程。线程，有时也被称为轻量级进程 (Lightweight Process，LWP），早期 Linux 的线程实现几乎就是复用的进程，后来才独立出自己的 API。

Java 线程的无处不在

案例:

在这里插入图片描述

Java 中不管任何程序都必须启动一个 main 函数的主线程; Java Web 开发里面的定时任务、定时器、JSP 和 Servlet、异步消息处理机制,远程访问接口 RM 等, 任何一个监听事件，onclick 的触发事件等都离不开线程和并发的知识。

面试题:进程间的通信

同一台计算机的进程通信称为 IPC（Inter-process communication），不同计算机之间的进程通信被称为 R(mote)PC需要通过网络，并遵守共同的协议，比如大家熟悉的 Dubbo 就是一个 RPC[R远程 P进程 C通信] 框架，而 Http 协议也经常用在 RPC 上，比如 SpringCloud 微服务。

大厂常见的面试题就是，进程间通信有几种方式？(*背)

管道，分为匿名管道（pipe）及命名管道（named pipe）：匿名管道可用于具有亲缘关系的父子进程间的通信，命名管道除了具有管道所具有的功能外，它还允许无亲缘关系进程间的通信。
信号（signal）：信号是在软件层次上对中断机制的一种模拟，它是比较复杂的通信方式，用于通知进程有某事件发生，一个进程收到一个信号与处理器收到一个中断请求效果上可以说是一致的。
消息队列（message queue）：消息队列是消息的链接表，它克服了上两种通信方式中信号量有限的缺点，具有写权限得进程可以按照一定得规则向消息队列中添加新信息；对消息队列有读权限得进程则可以从消息队列中读取信息。
共享内存（shared memory）：可以说这是最有用的进程间通信方式。它使得多个进程可以访问同一块内存空间，不同进程可以及时看到对方进程中对共享内存中数据得更新。这种方式需要依靠某种同步操作，如互斥锁和信号量等。
信号量（semaphore）：主要作为进程之间及同一种进程的不同线程之间得同步和互斥手段。
套接字（socket）：这是一种更为一般得进程间通信机制，它可用于网络中不同机器之间的进程间通信，应用非常广泛。同一机器中的进程还可以使用 Unix domain socket（比如同一机器中 MySQL 中的控制台 mysql shell 和 MySQL 服务程序的连接），这种方式不需要经过网络协议栈，不需要打包拆包、计算校验和、维护序号和应答等，比纯粹基于网络的进程间通信肯定效率更高。

3.3 CPU 核心数和线程数的关系

前面说过，目前主流 CPU 都是多核的，线程是 CPU 调度的最小单位。同一时刻，一个 CPU 核心只能运行一个线程，也就是 CPU 内核和同时运行的线程数是 1:1 的关系，也就是说 8 核 CPU 同时可以执行 8 个线程的代码。但 Intel 引入超线程技术后，产生了逻辑处理器的概念，使核心数与线程数形成 1:2 的关系。在我们前面的 Windows 任务管理器贴图就能看出来，内核数是 6 而逻辑处理器数是 12。

在 Java 中提供了 Runtime.getRuntime().availableProcessors()，可以让我们获取当前的 CPU 核心数，注意这个核心数指的是逻辑处理器数。

获得当前的 CPU 核心数在并发编程中很重要，并发编程下的性能优化往往和 CPU 核心数密切相关。

3.4 上下文切换（Context switch）（*重要）

既然操作系统要在多个进程（线程）之间进行调度，而每个线程在使用 CPU 时总是要使用 CPU 中的资源，比如 CPU 寄存器和程序计数器。这就意味着，操作系统要保证线程在调度前后的正常执行，所以，操作系统中就有上下文切换的概念，它是指 CPU(中央处理单元)从一个进程或线程到另一个进程或线程的切换。

上下文是 CPU 寄存器和程序计数器在任何时间点的内容。

寄存器是 CPU 内部的一小部分非常快的内存(相对于 CPU 内部的缓存和 CPU 外部较慢的 RAM 主内存)，它通过提供对常用值的快速访问来加快计算机程序的执行。

程序计数器是一种专门的寄存器，它指示 CPU 在其指令序列中的位置，并保存着正在执行的指令的地址或下一条要执行的指令的地址，这取决于具体的系统。

上下文切换可以更详细地描述为内核(即操作系统的核心)对 CPU 上的进程 (包括线程)执行以下活动:

暂停一个进程的处理，并将该进程的 CPU 状态(即上下文)存储在内存中的某个地方
从内存中获取下一个进程的上下文，并在 CPU 的寄存器中恢复它
返回到程序计数器指示的位置(即返回到进程被中断的代码行)以恢复进程。

从数据来说，以程序员的角度来看，是方法调用过程中的各种局部的变量与资源；以线程的角度来看，是方法的调用栈中存储的各类信息

引发上下文切换的原因一般包括：线程、进程切换、系统调用等等。上下文切换通常是计算密集型的，因为涉及一系列数据在各种寄存器、缓存中的来回拷贝。就 CPU 时间而言，一次上下文切换大概需要 5000~20000 个时钟周期，相对一个简单指令几个乃至十几个左右的执行时钟周期，可以看出这个成本的巨大。(在性能优化当中如果一个进程或线程在做大量的上下文切换那么意味着这个程序的优化)

问:在什么情况下synchronized的速度会超过CAS(*提示:围绕上下文切换来思考vmstat)

3.5 并行和并发

并发 Concurrent:指应用能够交替执行不同的任务,比如单 CPU 核心下执行多线程并非是同时执行多个任务,如果你开两个线程执行,就是在你几乎不可能察觉到的速度不断去切换这两个任务,已达到"同时执行效果",其实并不是的,只是计算机的速度太快,我们无法察觉到而已.

并行 Parallel:指应用能够同时执行不同的任务,例:吃饭的时候可以边吃饭边打电话,这两件事情可以同时执行

两者区别:一个是交替执行,一个是同时执行

四、认识Java中的线程

4.1 Java 程序天生就是多线程的

一个 Java 程序从 main()方法开始执行，然后按照既定的代码逻辑执行，看似没有其他线程参与，但实际上 Java 程序天生就是多线程程序，因为执行 main() 方法的是一个名称为 main 的线程。而一个 Java 程序的运行就算是没有用户自己开启的线程，实际也有有很多 JVM 自行启动的线程.

一般来说有：

[6] Monitor Ctrl-Break //监控 Ctrl-Break 中断信号的

[5] Attach Listener //内存 dump，线程 dump，类信息统计，获取系统属性等

[4] Signal Dispatcher // 分发处理发送给 JVM 信号的线程

[3] Finalizer // 调用对象 finalize 方法的线程

[2] Reference Handler//清除 Reference 的线程

[1] main //main 线程，用户程序入口

尽管这些线程根据不同的 JDK 版本会有差异，但是依然证明了 Java 程序天生就是多线程的。

4.2 线程的启动与终止

4.2.1 启动

启动线程的方式有：

1、X extends Thread;，然后 X.start

 /** 扩展Thread类 */
    private class UserThread extends Thread{
        @Override
        public void run() {
            super.run();
            System.out.println("I am extend Thread");
        }
    }

 UserThread userThread = new UserThread();
 userThread.start();

2、X implements Runnable；然后交给 Thread 运行

 /** 实现Runnable接口*/
    private class UserRunnable implements Runnable{
        @Override
        public void run() {
            System.out.println("I am implements Runnable");
        }
    }

 UserRunnable userRunnable = new UserRunnable();
 new Thread(userRunnable).start();

Thread 和 Runnable 的区别

Thread 才是 Java 里对线程的唯一抽象，Runnable 只是对任务（业务逻辑）的抽象。Thread 可以接受任意一个 Runnable 的实例并执行。

Callable、Future 和 FutureTask

Runnable 是一个接口，在它里面只声明了一个 run()方法，由于 run()方法返回值为 void 类型，所以在执行完任务之后无法返回任何结果。

Callable 位于 java.util.concurrent 包下，它也是一个接口，在它里面也只声明了一个方法，只不过这个方法叫做 call()，这是一个泛型接口，call()函数返回的类型就是传递进来的 V 类型。

Future 就是对于具体的 Runnable 或者 Callable 任务的执行结果进行取消、查询是否完成、获取结果。必要时可以通过 get 方法获取执行结果，该方法会阻塞直到任务返回结果。

问:新启线程有几种方式？(*****)

这个问题的答案其实众说纷纭，有 2 种，3 种，4 种等等答案，建议比较好的回答是：

按照 Java 源码中 Thread 上的注释：

There are two ways to create a new thread of execution. One is to declare a class to be a subclass of Thread. This subclass should override the run method of class Thread. An instance of the subclass can then be allocated and started. For example, a thread that computes primes larger than a stated value could be written as follows:

官方说法是在 Java 中有两种方式创建一个线程用以执行，一种是派生自 Thread 类，另一种是实现 Runnable 接口。

当然本质上 Java 中实现线程只有一种方式，都是通过 new Thread()创建线程对象，调用 Thread#start 启动线程。

至于基于 callable 接口的方式，因为最终是要把实现了 callable 接口的对象通过 FutureTask 包装成 Runnable，再交给 Thread 去执行，所以这个其实可以和实现 Runnable 接口看成同一类。

而线程池的方式，本质上是池化技术，是资源的复用，和新启线程没什么关系。所以，比较赞同官方的说法，有两种方式创建一个线程用以执行

4.2.2 中止

线程自然终止 要么是 run 执行完成了，要么是抛出了一个未处理的异常导致线程提前结束。

stop

暂停、恢复和停止操作对应在线程 Thread 的 API 就是 suspend()、resume() 和 stop()。但是这些 API 是过期的，也就是不建议使用的。不建议使用的原因主要有：以 suspend()方法为例，在调用后，线程不会释放已经占有的资源（比如锁），而是占有着资源进入睡眠状态，这样容易引发死锁问题。同样，stop()方法在终结一个线程时不会保证线程的资源正常释放，通常是没有给予线程完成资源释放工作的机会，因此会导致程序可能工作在不确定状态下。正因为 suspend()、 resume()和 stop()方法带来的副作用，这些方法才被标注为不建议使用的过期方法。

中断

安全的中止则是其他线程通过调用某个线程 A 的 **interrupt()**方法对其进行中断操作, 中断好比其他线程对该线程打了个招呼，“A，你要中断了”，不代表线程 A 会立即停止自己的工作，同样的 A 线程完全可以不理会这种中断请求。线程通过检查自身的中断标志位是否被置为 true 来进行响应，

线程通过方法 **isInterrupted()**来进行判断是否被中断，也可以调用静态方法 **Thread.interrupted()**来进行判断当前线程是否被中断，不过 Thread.interrupted() 会同时将中断标识位改写为 false。

如果一个线程处于了阻塞状态（如线程调用了 thread.sleep、thread.join、 thread.wait 等），则在线程在检查中断标示时如果发现中断标示为 true，则会在这些阻塞方法调用处抛出 InterruptedException 异常，并且在抛出异常后会立即将线程的中断标示位清除，即重新设置为 false。

不建议自定义一个取消标志位来中止线程的运行。因为 run 方法里有阻塞调用时会无法很快检测到取消标志，线程必须从阻塞调用返回后，才会检查这个取消标志。这种情况下，使用中断会更好，因为，

一、一般的阻塞方法，如 sleep 等本身就支持中断的检查，

二、检查中断位的状态和检查取消标志位没什么区别，用中断位的状态还可以避免声明取消标志位，减少资源的消耗。

注意：处于死锁状态的线程无法被中断

4.3 深入理解 run()和 start()

Thread类是Java里对线程概念的抽象，可以这样理解：我们通过new Thread() 其实只是 new 出一个 Thread 的实例，还没有操作系统中真正的线程挂起钩来。只有执行了 start()方法后，才实现了真正意义上的启动线程。

从 Thread 的源码可以看到，Thread 的 start 方法中调用了 **start0()**方法，而 **start0()**是个 native 方法，这就说明 Thread#start 一定和操作系统是密切相关的。

start()方法让一个线程进入就绪队列等待分配 cpu，分到 cpu 后才调用实现的 run()方法，start()方法不能重复调用，如果重复调用会抛出异常（注意，此处可能有面试题：多次调用一个线程的 start 方法会怎么样？）。

而 run 方法是业务逻辑实现的地方，本质上和任意一个类的任意一个成员方法并没有任何区别，可以重复执行，也可以被单独调用。

五、深入学习JAVA中的线程

5.1 线程的状态/生命周期

Java 中线程的状态分为 6 种：

初始(NEW)：新创建了一个线程对象，但还没有调用 start()方法。
运行(RUNNABLE)：Java 线程中将就绪（ready）和运行中（running）两种状态笼统的称为“运行”。

线程对象创建后，其他线程(比如 main 线程）调用了该对象的 start()方法。该状态的线程位于可运行线程池中，等待被线程调度选中，获取 CPU 的使用权，此时处于就绪状态（ready）。就绪状态的线程在获得 CPU 时间片后变为运行中状态（running）。
阻塞(BLOCKED)：表示线程阻塞于锁。
等待(WAITING)：进入该状态的线程需要等待其他线程做出一些特定动作（通知或中断）。
超时等待(TIMED_WAITING)：该状态不同于 WAITING，它可以在指定的时间后自行返回。
终止(TERMINATED)：表示该线程已经执行完毕。

状态之间的变迁

在这里插入图片描述

`其他的线程相关方法`

yield()方法：使当前线程让出 CPU 占有权，但让出的时间是不可设定的。也不会释放锁资源。同时执行 yield()的线程有可能在进入到就绪状态后会被操作系统再次选中马上又被执行。

比如，ConcurrentHashMap#initTable 方法中就使用了这个方法

这是因为 ConcurrentHashMap 中可能被多个线程同时初始化 table，但是其实这个时候只允许一个线程进行初始化操作，其他的线程就需要被阻塞或等待，但是初始化操作其实很快，这里 Doug Lea 大师为了避免阻塞或者等待这些操作引发的上下文切换等等开销，就让其他不执行初始化操作的线程干脆执行 yield() 方法，以让出 CPU 执行权，让执行初始化操作的线程可以更快的执行完成。

5.2 线程的优先级

在 Java 线程中，通过一个整型成员变量 priority 来控制优先级，优先级的范围从 1~10，在线程构建的时候可以通过 setPriority(int)方法来修改优先级，默认优先级是 5，优先级高的线程分配时间片的数量要多于优先级低的线程。

设置线程优先级时，针对频繁阻塞（休眠或者 I/O 操作）的线程需要设置较高优先级，而偏重计算（需要较多 CPU 时间或者偏运算）的线程则设置较低的优先级，确保处理器不会被独占。在不同的 JVM 以及操作系统上，线程规划会存在差异，有些操作系统甚至会忽略对线程优先级的设定。

5.3 线程的调度

线程调度是指系统为线程分配 CPU 使用权的过程，主要调度方式有两种：

协同式线程调度(Cooperative Threads-Scheduling)
抢占式线程调度(Preemptive Threads-Scheduling)

使用协同式线程调度的多线程系统，线程执行的时间由线程本身来控制，线程把自己的工作执行完之后，要主动通知系统切换到另外一个线程上。使用协同式线程调度的最大好处是实现简单，由于线程要把自己的事情做完后才会通知系统进行线程切换，所以没有线程同步的问题，但是坏处也很明显，如果一个线程出了问题，则程序就会一直阻塞。

使用抢占式线程调度的多线程系统，每个线程执行的时间以及是否切换都由系统决定。在这种情况下，线程的执行时间不可控，所以不会有「一个线程导致整个进程阻塞」的问题出现。

Java 线程调度就是抢占式调度，为什么？

在 Java 中，Thread.yield()可以让出 CPU 执行时间，但是对于获取执行时间，线程本身是没有办法的。对于获取 CPU 执行时间，线程唯一可以使用的手段是设置线程优先级，Java 设置了 10 个级别的程序优先级，当两个线程同时处于 Ready 状态时，优先级越高的线程越容易被系统选择执行。

5.4 线程和协程

为什么 Java 线程调度是抢占式调度？这需要我们了解 Java 中线程的实现模式。

我们已经知道线程其实是操作系统层面的实体，Java 中的线程怎么和操作系统层面对应起来呢？

任何语言实现线程主要有三种方式：使用内核线程实现（1:1 实现)，使用用户线程实现(1:N 实现），使用用户线程加轻量级进程混合实现(N:M 实现）。

5.4.1 内核线程实现

使用内核线程实现的方式也被称为 1： 1 实现。内核线程（Kernel-Level Thread， KLT）就是直接由操作系统内核（Kernel，下称内核）支持的线程，这种线程由内核来完成线程切换，内核通过操纵调度器（Scheduler）对线程进行调度，并负责将线程的任务映射到各个处理器上。

由于内核线程的支持，每个线程都成为一个独立的调度单元，即使其中某一个在系统调用中被阻塞了，也不会影响整个进程继续工作，相关的调度工作也不需要额外考虑，已经由操作系统处理了。

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

5.4.2 用户线程实现

严格意义上的用户线程指的是完全建立在用户空间的线程库上，系统内核不能感知到用户线程的存在及如何实现的。用户线程的建立、同步、销毁和调度完全在用户态中完成，不需要内核的帮助。如果程序实现得当，这种线程不需要切换到内核态，因此操作可以是非常快速且低消耗的，也能够支持规模更大的线程数量，部分高性能数据库中的多线程就是由用户线程实现的。

用户线程的优势在于不需要系统内核支援，劣势也在于没有系统内核的支援，所有的线程操作都需要由用户程序自己去处理。线程的创建、销毁、切换和调度都是用户必须考虑的问题，而且由于操作系统只把处理器资源分配到进程，那诸如“阻塞如何处理”“多处理器系统中如何将线程映射到其他处理器上”这类问题解决起来将会异常困难，甚至有些是不可能实现的。因为使用用户线程实现的程序通常都比较复杂，所以一般的应用程序都不倾向使用用户线程。Java 语言曾经使用过用户线程，最终又放弃了。但是近年来许多新的、以高并发为卖点的编程语言又普遍支持了用户线程，譬如 Golang。

5.4.3 混合实现

线程除了依赖内核线程实现和完全由用户程序自己实现之外，还有一种将内核线程与用户线程一起使用的实现方式，被称为 N：M 实现。在这种混合实现下，既存在用户线程，也存在内核线程。

用户线程还是完全建立在用户空间中，因此用户线程的创建、切换、析构等操作依然廉价，并且可以支持大规模的用户线程并发。

同样又可以使用内核提供的线程调度功能及处理器映射，并且用户线程的系统调用要通过内核线程来完成。在这种混合模式中，用户线程与轻量级进程的数量比是不定的，是 N：M 的关系。

5.4.4 Java 线程的实现

Java 线程在早期的 Classic 虚拟机上（JDK 1.2 以前），是用户线程实现的，但从 JDK 1.3 起，主流商用 Java 虚拟机的线程模型普遍都被替换为基于操作系统原生线程模型来实现，即采用 1： 1 的线程模型。

以 HotSpot 为例，它的每一个 Java 线程都是直接映射到一个操作系统原生线程来实现的，而且中间没有额外的间接结构，所以 HotSpot 自己是不会去干涉线程调度的，全权交给底下的操作系统去处理。

所以，这就是我们说 Java 线程调度是抢占式调度的原因。而且 Java 中的线程优先级是通过映射到操作系统的原生线程上实现的，所以线程的调度最终取决于操作系统，操作系统中线程的优先级有时并不能和 Java 中的一一对应，所以 Java 优先级并不是特别靠谱。

5.5 协程

5.5.1 出现的原因

随着互联网行业的发展，目前内核线程实现在很多场景已经有点不适宜了。比如，互联网服务架构在处理一次对外部业务请求的响应，往往需要分布在不同机器上的大量服务共同协作来实现，，也就是我们常说的微服务，这种服务细分的架构在减少单个服务复杂度、增加复用性的同时，也不可避免地增加了服务的数量，缩短了留给每个服务的响应时间。这要求每一个服务都必须在极短的时间内完成计算，这样组合多个服务的总耗时才不会太长；也要求每一个服务提供者都要能同时处理数量更庞大的请求，这样才不会出现请求由于某个服务被阻塞而出现等待。

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

另外我们常见的 Java Web 服务器，比如 Tomcat 的线程池的容量通常在几十个到两百之间，当把数以百万计的请求往线程池里面灌时，系统即使能处理得过来，但其中的切换损耗也是相当可观的。

这样的话，对 Java 语言来说，用户线程的重新引入成为了解决上述问题一个非常可行的方案。

其次，Go 语言等支持用户线程等新型语言给 Java 带来了巨大的压力，也使得 Java 引入用户线程成为了一个绕不开的话题。

5.5.2 协程简介

为什么用户线程又被称为协程呢？我们知道，内核线程的切换开销是来自于保护和恢复现场的成本，那如果改为采用用户线程，这部分开销就能够省略掉吗？答案还是“不能”。但是，一旦把保护、恢复现场及调度的工作从操作系统交到程序员手上，则可以通过很多手段来缩减这些开销。

由于最初多数的用户线程是被设计成协同式调度（Cooperative Scheduling）的，所以它有了一个别名——“协程”（Coroutine）完整地做调用栈的保护、恢复工作，所以今天也被称为“有栈协程”（Stackfull Coroutine）。

协程的主要优势是轻量，无论是有栈协程还是无栈协程，都要比传统内核线程要轻量得多。如果进行量化的话，那么如果不显式设置，则在 64 位 Linux 上 HotSpot 的线程栈容量默认是 1MB，此外内核数据结构（Kernel Data Structures）还会额外消耗 16KB 内存。与之相对的，一个协程的栈通常在几百个字节到几 KB 之间，所以 Java 虚拟机里线程池容量达到两百就已经不算小了，而很多支持协程的应用中，同时并存的协程数量可数以十万计。

协程当然也有它的局限，需要在应用层面实现的内容（调用栈、调度器这些）特别多，同时因为协程基本上是协同式调度，则协同式调度的缺点自然在协程上也存在。

总的来说，协程机制适用于被阻塞的，且需要大量并发的场景（网络 io），不适合大量计算的场景，因为协程提供规模(更高的吞吐量)，而不是速度(更低的延迟)。

5.5.3 纤程-Java 中的协程

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

所以 Java 开发组就 Java 中协程的实现也做了很多努力，OpenJDK 在 2018 年创建了 Loom 项目，这是 Java 的官方解决方案，并用了“纤程（Fiber）”这个名字。

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

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

目前 Java 中比较出名的协程库是 Quasar[ˈkweɪzɑː®]（Loom 项目的 Leader 就是 Quasar 的作者 Ron Pressler）， Quasar 的实现原理是字节码注入，在字节码层面对当前被调用函数中的所有局部变量进行保存和恢复。这种不依赖 Java 虚拟机的现场保护虽然能够工作，但影响性能。

5.6 Quasar实战

5.7 JDK19 的虚拟线程

2022 年 9 月 22 日，JDK19（非 LTS 版本）正式发布，引入了协程，并称为轻量级虚拟线程。但是这个特性目前还是预览版，还不能引入生成环境。因为环境所限，本课程不提供实际的范例，只讲述基本用法和原理。

javac --release 19 --enable-preview XXX.java 编译程序
并使用 java --enable-preview XXX 运行该程序

在具体使用上和原来的 Thread API 差别不大：java.lang.Thread.Builder，可以创建和启动虚拟线程，例如：

Thread thread = Thread.ofVirtual().name("duke").unstarted(runnable);
// Thread.ofPlatform() 则创建传统意义的实际
或者
Thread.startVirtualThread(Runnable)
并通过 Executors.newVirtualThreadPerTaskExecutor()提供了虚拟线程池功能。

在具体实现上，虚拟线程当然是基于用户线程模式实现的，JDK 的调度程序不直接将虚拟线程分配给处理器，而是将虚拟线程分配给实际线程，是一个 M: N 调度，具体的调度程序由已有的 ForkJoinPool 提供支持。

但是虚拟线程不是协同调度的，JDK 的虚拟线程调度程序通过将虚拟线程挂载到平台线程上来分配要在平台线程上执行的虚拟线程。在运行一些代码之后，虚拟线程可以从其载体卸载。此时平台线程是空闲的，因此调度程序可以在其上挂载不同的虚拟线程，从而使其再次成为载体。

通常，当虚拟线程阻塞 I/O 或 JDK 中的其他阻塞操作(如 BlockingQueue.take ())时，它将卸载。当阻塞操作准备完成时(例如，在套接字上已经接收到字节) ，它将虚拟线程提交回调度程序，调度程序将在运营商上挂载虚拟线程以恢复执行。虚拟线程的挂载和卸载频繁且透明，并且不会阻塞任何 OS 线程。

5.8 守护线程

Daemon（守护）线程是一种支持型线程，因为它主要被用作程序中后台调度以及支持性工作。这意味着，当一个 Java 虚拟机中不存在非 Daemon 线程的时候，Java 虚拟机将会退出。可以通过调用 Thread.setDaemon(true)将线程设置为 Daemon 线程。我们一般用不上，比如垃圾回收线程就是 Daemon 线程。

Daemon 线程被用作完成支持性工作，但是在 Java 虚拟机退出时 Daemon 线程中的 finally 块并不一定会执行。在构建 Daemon 线程时，不能依靠 finally 块中的内容来确保执行关闭或清理资源的逻辑。