共计 4507 个字符，预计需要花费 12 分钟才能阅读完成。
你好呀，我是歪歪。
敌人们，好消息，好消息，重磅好消息。
从今年年初就始终在喊的具备革命性、将来性、创始新纪元的 JDK 21 依照官网的工夫计划表，明天终于是要正式 GA 了：
https://openjdk.org/projects/jdk/21/
GA，就是我下面框起来的“General Availability”的缩写，直译成中文，尽管是“一般可用”的意思，然而在软件行业，它就代表正式版。
如果对外公布一个 GA 版本，就意味着这个版本曾经通过全面的测试，不存在任何重大的 bug，可供普通用户进行应用。
既然说到 GA 了，歪徒弟也顺便给大家遍及一下个别咱们看到的版本号的含意。
比方咱们常常会看到一些软件公布的时候都会带上 Alpha、Beta、Gamma、RC 等等这些莫名其妙的单词，它们代表什么意思呢？
- Alpha：软件或零碎的内部测试版本，仅内部人员应用。个别不向内部公布，通常会有很多 Bug，除非你也是测试人员，否则不倡议应用，alpha 就是 α，是希腊字母的第一位，示意最高级的版本，beta 就是 β，alpha 版就是比 beta 还早的测试版，个别都是内部测试的版本。
- Beta：公开测试版。β 是希腊字母的第二个，顾名思义，这一版本通常是在 Alpha 版本后，该版本绝对于 Alpha 版已有了很大的改良，打消了重大的谬误，但还是存在着一缺点，须要通过屡次测试来进一步打消。这个阶段的版本会始终退出新的性能。
- Gamma：
软件或零碎靠近于成熟的版本，只须要做一些小的改良就能发行。是 beta 版做过一些批改，成为正式公布的候选版本。 - RC：Release Candidate，发行候选版本。和 Beta 版最大的差异在于 Beta 阶段会始终退出新的性能，然而到了 RC 版本，简直就不会退出新的性能了，而次要着重于除错。RC 版本是最终发放给用户的最靠近正式版的版本，发行后改过 bug 就是正式版了，就是正式版之前的最初一个测试版。
- GA：General Available，正式公布的版本，这个版本就是正式的版本。在国外都是用 GA 来阐明 release 版本的。比方：MySQL Community Server 5.7.21 GA 这是 MySQL Community Server 5.7 第 21 个发行稳固的版本，GA 意味着 General Available，也就是官网开始举荐宽泛应用了。
- Release：这个版本通常就是所谓的“最终版本”，在后面版本的一系列测试版之后，终归会有一个正式版本，是最终交付用户应用的一个版本，该版本有时也称为标准版。个别状况下，Release 不会以单词模式呈现在软件封面上，取而代之的是符号 (R)。
- Stable：稳定版。在开源软件中，都有 stable 版，这个就是开源软件的最终发行版，用户能够放心大胆的用了。这一版本基于 Beta 版，已知 Bug 都被修复，个别状况下，更新比较慢。
除了下面的这些之外，咱们还常常看见一个 LTS 的版本号。
LTS，Long Term Support，长期反对版，是指针对软件的某一版本，提供长时间的技术支持、安全更新和谬误修复。
绝对于非 LTS 版本，LTS 版本被认为是更为稳固、牢靠和平安的版本。因而，在须要稳定性和安全性较高的场景中，如生产环境、企业级利用等，LTS 版本失去宽泛的利用。
在 Java 畛域，LTS 版本是指 Oracle 公司公布的 Java SE（Standard Edition，标准版）中，每隔一段时间公布一个长期反对版本。
自 2018 年开始，Oracle Java SE 8、Java SE 11、Java SE 17 成为了 LTS 版本，别离提供了 3 年、8 年、至多 3 年的反对。
你看，一个小小的 GA 外面，暗藏了这么多的小知识点，让歪徒弟一不小心就铺（水）垫（了）这么长。
说会到 JDK 21 明天的 GA 版本，一共公布了 15 个新个性：
一眼望去，其中最刺眼的，也是形容最短的一个 Feature 是 444 号 Virtual Threads：
https://openjdk.org/jeps/444
能够说这个个性就是 JDK 21 这个版本中最受注目、最值得期待的一个个性了。
Virtual Threads，就是虚构线程，从 JDK 19 吆喝到 JDK 20，终于在 JDK 21 现真身了。
后面我形容 JDK 21 的时候提到了一个词：创始新纪元。
值得就是它，依据官网介绍，虚构线程的呈现，的确是开启了并发编程的新纪元，轻量且高效，用更少的开销，解决更多的工作。
最重要的是看看这个：
来，翻译翻译，什么叫做“minimal change”？
minimal，就是小小的也很可恶，就是“极小的”。
change，就是变动。
官网示意，应用 java.lang.Thread API 的现有代码，只需做 极少改变（minimal change）即可启用虚构线程。
少到你降级到 JDK 21 之后，只须要把创立线程池的中央批改为这样就能启用虚构线程：
至于这个玩意到底有多牛逼，你能够轻易在网上检索一下，曾经有很多相干的文章了。
然而我还是倡议你间接看官网的这个形容，这才是第一手材料呈现的中央，如果让我来形容，我也只能是对于官网文章进行高明的翻译。
https://openjdk.org/jeps/444
除了 444 之外，也有其余的很多实用的个性。
依据官网的信息，它们把这 15 个新个性依照 JEP 的模式分为四类：外围 Java 库，Java 语言标准，HotSpot 和平安库。
https://www.infoq.com/news/2023/09/java-21-so-far/
纳入外围 Java 库的 6 个新个性别离是：
- JEP 431：序列汇合
- JEP 442：内部函数和内存 API(第三次预览)
- JEP 444：虚构线程
- JEP 446：作用域值 (预览)
- JEP 448：Vector API (第六次孵化器)
- JEP 453：结构化并发 (预览)
纳入 Java 语言标准的 5 个新个性别离是：
- JEP 430：字符串模板 (预览)
- JEP 440：记录模式
- JEP 441：switch 模式匹配
- JEP 443：未命名模式和变量 (预览)
- JEP 445：未命名类和实例主办法 (预览)
纳入 HotSpot 的 3 个新个性别离是：
- JEP 439：分代 ZGC
- JEP 449：弃用 Windows 32 位 x86 移植
- JEP 451：筹备禁止动静加载代理
纳入平安库的 1 个新个性是：
- JEP 452：密钥封装机制 API
其中 445 号提案，也小小的火了一把，因为它被大多数网友调侃为“卵用不大”。
因为这个提案是为了简化 Hello World 的写法。
https://openjdk.org/jeps/445
在这个提案中，作者认为咱们的 Hello World 太简单了，要写这么多代码：
public class HelloWorld {public static void main(String[] args) {System.out.println("Hello, World!");
}
}所以他提议，为了 students 和 beginner 更快更好的入门 Java，应该简化成这样，
然而这个提案也强调了：这是预览语言性能，默认禁用。
如果你要用，须要这样操作：
- 用 javac –release 21 –enable-preview Main.java 编译程序，用 java –enable-preview Main 运行程序。
- 或者，当应用源代码启动器 source code launcher, 时，用 java –source 21 –enable-preview Main.java 运行程序。
对于这个性能，怎么说的？
我的评估是：这很难评。
最初，再说一下编号为 439 的提案。
https://openjdk.org/jeps/439
ZGC，大家不生疏了吧？
这个提案提到它是干啥呢？
目前的版本中，ZGC 都是不分代 GC 的。在 JDK 21 的版本中，提供了分代 GC 的性能，然而默认是敞开状态，须要通过配置关上：
而且，留神最初这句话：
In a future release we intend to make Generational ZGC the default, at which point -XX:-ZGenerational will select non-generational ZGC. In an even later release we intend to remove non-generational ZGC, at which point the ZGenerational option will become obsolete.
在将来的版本中，官网会把 ZGenerational 设为默认值，即默认关上 ZGC 的分代 GC。
在更晚的版本中，官网会思考删除 ZGC 的不分代 GC 性能，到时候 ZGenerational 这个配置就会被一并“优化”。
说到这个 ZGC 的分代 GC，我忽然想起了一个有意思的问题。
就是 2018 年，在 JDK 11 的外面，刚刚开始宣传 ZGC 的时候，就有人问：ZGC 为什么不进行分代啊？
对于这个问题，我在 R 大那里看到了一个权威的答复：
https://www.zhihu.com/question/287945354/answer/458761494
没有什么特地的起因，就是“因为分代实现起来麻烦，想先实现出比较简单可用的版本”而已。
这句话，像不像咱们经常听到的：先跑起来再说？
然而人家的“跑起来再说”和咱们的“跑起来再说”齐全不是一个维度的货色。
至多，人家提供的“跑起来”的版本，从 2018 年跑到了 2023 年，5 年工夫。
而你的“跑起来再说”可能一周后就接到了全新的、不兼容的需要。
5 年就更别想了，业务可能都被砍了，跑不起来了。（手动狗头）
既然都提到了 ZGC 了，那就顺便提一嘴 Shenandoah 吧。
依据官网的音讯，最开始 JDK 21 的版本中是蕴含了 Shenandoah 的。
https://openjdk.org/jeps/404
然而为什么 GA 版本中没有看到它的影子呢？
能够看看官网 6 月份的这个邮件：
https://mail.openjdk.org/pipermail/jdk-dev/2023-June/007959.html
别问，问就是工夫紧，工作重，申请延期。
首先形容了起因：
Given the risks identified during the review process and the lack of time available to perform the thorough review that such a large contribution of code requires
因为 Shenandoah 在审查的过程中发现了明确的危险，并且没有足够的工夫来进行针对大量代码改变所需的评审。
而后画了一个新饼：
take the time to deliver the best Generational Shenandoah that we can.
Shenandoah 团队决定“尽他们所能提供最好的分代 Shenandoah”。
并给本人设置了一个新工作，将 JDK 22 作为公布指标：
We will seek to target JDK 22.
能怎么办，等着呗。
反正你发任你发，我用 Java 8！
话尽管是这么说，然而我还是心愿在我短暂的职业生涯中，有幸能在生产上应用到 JDK 21，领会一下虚构线程和 ZGC 带来的双重服务。
