千呼万唤始出来 JDK 21 LTS, 久等了

平地起惊雷！！！

目录

• 英雄的迟暮
• 大人时代变了
• JDK 21 LTS 前 JAVA并发编程模型
• JDK 21 LTS 中的 JAVA 并发编程模型
• 虚拟线程 VS 线程池
• The Last

你可以称呼它为：JDK 8 之后的神，它也是很多人认为的 JDK 8 之后，最值得升级的版本。

以前大家都说：

他发任他发，我用JAVA 8

抱歉，这次JDK 21 我不得不使用了

已知使用较为广泛的几个 LTS版本是 (Long Term Support) ：

• JDK 8 LTS
• JDK 11 LTS
• JDK 17 LTS

那么为什么非得是 JDK 21呢？

英雄的迟暮

• ...
• Kafka 宣布弃用 Java 8 ...
• Jenkins 宣布弃用 Java 8 ...
• Spring6 强依赖 Java 17 ...
• Elasticsearch 使用的JDK 也不是 JDK8
• ......

JDK 8 的地位并非无可撼动的，如下所示为某个机构统计的，近几年一些线上 JAVA 应用使用的 JDK 版本情况：

• LTS j8 已经从 84% 一路迭到了 32%

• 而另两个 LTS 版本 J_11 和 J_17 的使用情况都有了长足的进步

所以别傻了，可能只有你在坚守JDK 8，你的小伙伴可能都已经转投别人温暖的怀抱了

JDK 21 LTS 可是迎来了史诗级的增强（后边详述），它的表现一定不会比 JDK_11 和 JDK_17弱。

spring系列作为绑定JAVA的头号玩家，期待Spring 的下一个大版本。

变革的大幕已经拉开，车轮已经开始滚滚先前; 昨日之日或西垂，夺目新日将大展光芒。

大人时代变了

JDK 21他来真的了，下边是我们的主角闪亮登场：

曾经在JDK 19中作为预览的虚拟线程，在JDK 21 LTS 中成为正式功能了

[PS * JDK 21 除了 虚拟线程 ，其实还有不少别的特性，但是我感觉都属于真正的平平无奇的水平，只有 虚拟线程 值得大动干戈。]

犹记得曾经阅读读 《深入理解Java虚拟机》一书时，关于Java 并发编程模型的章节，了解了 JAVA 的并发编程模型现状后，纯纯的 GoLang 薄纱啊，故此实引为一大遗憾。当时书中提到 JAVA 官方启动了 Loom 项目来弥补这一缺憾，当时都只觉得是在忽悠，这么多年的问题了，哪儿能那么容易解决呢，怕是画了老大一个饼吧？ 虽然是耿耿于怀，之后老长时间没有关注它了，然后，突然某天看到JDK 21来了， 虚拟线程 成为了正式功能了，当时看到这个消息时还是挺开心的

问题一: 不就是上下文切换么，我配置好线程池不就够了？

• 设置线程池在一定程度上，确实可以减少上下文切换，但是除了创建线程、线程销毁，线程的生命周期中的其它操作呢？

问题二，屎山怎么办？

• 屎山没必要动它，原样维持呗，可别给我说你本地装了 j21 之后j8 的项目就跑不起来了。
• 而且现在【微服务 + 容器平台】那么火爆，这同样也是解决之道啊

JDK 21 LTS 前 JAVA并发编程模型

JAVA 21之前的版本，用户态(JVM 态)下，JDK的并发编程模型的是，JVM线程与操作系统的内核线程 1：1 实现，缺点是在用户态（JVM态）下的每一个线程的，挂起、唤醒、销毁等调度操作，都会直接作用到操作系统的内核线程上。

• LWP (Light Weight Process) 轻量级进程, 也就是JDK 21 之前版本中 JAVA 线程了
• KLT (kernel Level Thread) 操作线程内核线程

LWP 与 KLT 之间是一对一的

从JVM 发起对内核线程的调度，相对来说是一个非常重的操作，资源消耗严重。

关于资源消耗，例如：

• LWP (轻量级进程) 会消耗一定的内核资源，比如内核线程的栈空间，因此操作系统支持的轻量级进程是有限的。
• 高损耗的内核线程调度，它直接影响高并发场景下，多个线程的执行效率，所以之前偶尔听到流传的一个说法: Java业务为王，GoLang高并发称雄。

JDK 21 LTS 中的 JAVA 并发编程模型

而到了JDK 21 LTS 中引入的 虚拟线程 呢，到了这里并发编程模型的实现发生了变化:

JVM 态线程跟操作系统内核态线程不再 {1：1} 实现，而是 { [1 (操作系统内核线程)] : [N (JVM 虚拟线程 )] }。这样在JVM态下，对每个 虚拟线程 的创建、调度、切换、销毁等操作，不再直接高度依赖操作系统内核线程，所以高并发常见下，线程的执行效率会有很大提升。

• UT: user thread 用户线程，也可以称呼它：虚拟线程

其实 GoLang 的协程就是类似 虚拟线程 的东西；不过 JAVA 的 虚拟线程 跟 GoLang 的协程还是有区别的：

• GoLang 的协程支持跨核(cpu)，内存管理更优
• Java 的虚拟线程不支持跨核，但是执行的效率更佳

具体要怎么选择，就是仁者见仁智者见智了。

回到前边提到的关于线程池的问题上来

虚拟线程 VS 线程池

先明确两个概念：

  - 轻量级进程：也就是 JDK 21 之前的 JAVA 线程，它的上下文切换直接关联到操作系统内核上。

  - 虚拟线程：JDK 21 新特性，纯JVM 用户态下的东西，它的执行、调度... 等操作不会强关联系统内核

线程池大行其道的原因：

• 每个 轻量级进程 的创建，都会直接去操作，操作系统的内核线程，并竞争CPU 的时间分片。所以聪明的大佬们想到了一个办法就是引入线程池，这样就可以大量节省去调度操作系统内核线程，执行 轻量级进程 创建、线程注销相关的操作开销了。

• JDK 21 之前 轻量级进程 自身占用的内存很高，也是线程池能够大行其道的原因之一，常见的64位的操作系统上一个 轻量级进程 默认占用 1MB 的内存空间，算算你的机器能创建多少个 轻量级进程 吧。

但是即使有了线程池，还是指标不治本。 轻量级进程 除了创建、销毁之外，还有：挂起、唤醒 ...... 等等一系列的操作的上下文切换还是要依赖操作系统内核来完成的。由于线程池是复用的，线程池的每个 轻量级进程 会经历无数次的挂起、唤醒、执行CPU 时间分片, 直至 轻量级进程 被线程池踢除。

然后就是 虚拟线程 了，它彻底解决了这些难点问题：

• 基于用户态实现的并发编程模型，决定了 虚拟线程 调度，不再强依赖系统内核
• 虚拟线程 空间占用极小，默认只有几百字节，在64位的系统上，比 轻量级进程 默认的 1MB 小了太多太多；同等内存占用下，创建的 虚拟线程 数绝对很容易达到 轻量级进程 数的指数倍。

The Last

总结来说就是：

减少了直接对操作系统内核线程的调度，将并发模型从操作系统内核 {1：1} 实现，转变为 {1：N} 实现，虚拟线程将完全由 JVM 自管理，执行效率，资源利用率都将得到提升。

综上所述直接吹爆 JDK 21，因为从 虚拟线程 开始，Java 在高并发领域也获得了入场券。越是了解JVM 并发编程的模型的人，越会知道 虚拟线程 的重量。

连挤牙膏式的 JDK 11 LTS 和 JDK 17 LTS 使用量都能上去，凭什么作为王牌的 JDK 21 LTS 会上不去？