进程和线程
进程
所谓计算机程序 Program,其实就是通过执行一系列指令来完成某一个任务。当你启动一个程序时,操作系统(OS)会将其加载到内存中,并在内存中申请一块固定地址的命名空间(address space),并在此命名空间内执行相关指令。聪明人应该已经听出来了,这不就是"进程 Process" 嘛。没有错,某种程度上我们确实可以将进程理解为一个程序的。
线程
线程就是在进程内部,一系列可执行的独立指令。而这些独立指令最终是被 CPU 执行。为了更大利益化的使用 CPU,在一个进程Process内,可以存在多个线程。这就让程序有了并发执行指令的能力,增加了程序的吞吐量。
CPU 和 并发
实际上大多数情况下,"并发"只是 CPU 给我们造成的一种"幻觉"。只有在线程数小于 CPU 核数时,才是真正意义的并发。
假设我们有一个 4 核CPU,然后同时开启4个线程执行任务,那在同一时间CPU的4核会分别执行1个线程的指令,如下图:
但是如果我们开启 8 个线程执行任务,因为CPU只有4核,所以只能通过切换上下文(switch-context)的方式来实现并发的"幻觉"。也就是在不同的线程间切换,因为切换时间极快,使用户从视觉上感知就是同时在执行的。如下图
Thread 奇技淫巧
线程是一把"双刃剑",使用合理能够提高系统效率,使用不当也会造成揠苗助长。
假设我们有一个 int 类型变量 count,我们分别使用 1000 个线程使其自增1,以及使用单个线程使其自增1000次。我们可以对比下这2种方式所耗的时间,代码如下:
public class SumOfNums {
volatile int count = 0;
static long start, end;
synchronized void increase_with_multi_thread() {
count++;
if (count == 2000) {
end = System.currentTimeMillis();
System.out.println("multi thread, start: " + start + " end:" + end + " time: " + (end - start));
}
}
void increase_with_single_thread() {
new Thread(() -> {
for (int i = 0; i < 1000; i++) {
count++;
}
end = System.currentTimeMillis();
System.out.println("single thread, start: " + start + " end:" + end + " time: " + (end - start));
}).start();
}
public static void main(String[] args) {
SumOfNums sumOfNums = new SumOfNums();
start = System.currentTimeMillis();
sumOfNums.increase_with_single_thread(); // 1. 单线程自增 1000 次
// 2. 创建 1000 个线程,使其自增1
for (int i = 1; i <= 1000; i++) {
Thread t = new Thread(sumOfNums::increase_with_multi_thread);
t.start();
}
}
}
执行上述代码,得到如下结果:
single thread, start: 1685429904704 end:1685429904706 time: 2
multi thread, start: 1685429904704 end:1685429904748 time: 44
可以看出,创建过多的线程并没有提高工作效率,反而比单线程慢超过20倍!
问题分析
在上述将 count 自增的操作属于 CPU密集型任务,计算结果高度依赖 CPU 的计算效率。之所以在之前的结果里多个线程的效率慢,是因为我们创建了 1000 个线程,个数已经完全超出了CPU核数,所以 CPU 不得不在多个线程中进行上下文切换,这个操作会严重影响程序运行效率。
除了 CPU 密集型任务,还有一种 IO 密集型任务。假设我们需要读取磁盘空间上的 20 个文件,并对其内容进行计算。在磁盘读取时,CPU是处于 IDLE(闲置) 状态。因为磁盘读取操作是发生在特殊硬件设备(disk 驱动)中。此时不需要 CPU 的参与,只有读完磁盘之后,剩下的操作才交给 CPU 进行处理。假设我们还是在4核CPU上,使用 4 个线程执行此任务,使用整个过程如下图所示:
可以看出,每一个线程被相应的分配给 CPU 的每个核。线程是充分利用了,但是当代码执行到磁盘读取操作时,CPU核就会处于 IDLE 状态,浪费了CPU资源。对于这种情况,如果我们就可以通过将线程数提高到8个来提高工作效率,如下图:
效率提高的原因是,在之前4个线程的 IDLE 状态,此时因为有额外线程需要执行。所以 CPU 会继续执行其它额外的线程任务,充分利用了 CPU 资源。总结就是:与其 IDLE,不如压榨!
Thread 挖一挖
在现代操作系统中,Thread一般有2种类型:Kernel Thread 和 User Thread。
Kernel Thread
内核线程,又可以被叫做 OS Thread,也就是操作系统线程。Kernel 线程是由操作系统内核来管理,每一个线程都需要包含线程状态、优先级,以及一些其它属性。这类线程相对较重,需要调用操作系统的API来创建、维护管理。
User Thread
User Thread就是用户线程,是处于应用层面的一种数据结构体,比如我们使用 Java SDK 中的 Thread就是User Thread。在这种数据结构内部,同样也定义了线程的状态、优先级等属性。
但实际上User Thread 无法被直接执行,User Thread 需要 mapping 到 Kernel Thread 之后,被解释成指令后再执行。一共有3种mapping方式:
M:1 model: 所有的User Thread 都与1个Kernel Thread进行mapping
1:1 model: 1个User Thread对应2个Kernel Thread
M:N model: 所有的User Thread 对应的是系统层的 Kernel Thread Pool
Java Thread
上面说的 mapping 方式是大多操作系统会使用的模型方式,那么在 Java JVM中是使用何种方式呢?
Green Thread
在 早期版本,Java 提供的是 Green Thread 模型方式,所有线程都是由 JVM 管理和调度。并且 Green Thread 与 Kernel Thread 的 mapping 模式是 M:1 方式,所以Green Thread的运行速度是极快的。但是 Green Thread 有一个比较大的缺陷:无法针对多核处理器进行扩展。
Native Thread
从 JDK 1.2 之后,Java 就放弃了 Green Thread 模型方式,改用 Native Thread 模型方式了。Native 同样也是有 JVM 管理,但是一定程度上对底层的Kernel有依赖;另外,Native Thread 与 Kenel Thread 的 mapping 模式是 1:1 模式。
改用 Native Thread之后,这几番操作下来,在一定程度上提高了线程的运行效率,但是带来的后果就是线程的创建和销毁操作变得异常笨重。这也是为什么我们在项目中会使用线程池来缓存线程、提高运行效率的原因。
虚拟线程
Java 19 版本引入了虚拟线程 Virtual Thread,它是一种轻量级的线程。虚拟线程解决了 Native Thread 的缺陷,创建和销毁过程不再那么笨重,不需要操作系统的参与。
可以通过如下方式,使用虚拟线程:
for (int i = 0; i < 5; i++) {
Thread vThread = Thread.ofVirtual().start(() -> System.out.println("Hello World"));
}
或者使用Executors创建虚拟线程:
public static void main(String[] args) {
var executor = Executors.newVirtualThreadExecutor();
for (int i = 0; i < 5; i++) {
executor.submit(() -> System.out.println("Hello World"));
}
executor.awaitTermination();
System.out.println("All virtual threads are finished");
}
如果你喜欢本文
长按二维码关注
文章来源:https://www.toymoban.com/news/detail-468499.html
文章来源地址https://www.toymoban.com/news/detail-468499.html
到了这里,关于每每聊到线程Thread的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!