Java 9~Java 17主要更新了什么？

强哥叨逼叨

已于 2022-01-28 23:34:00 修改

阅读量2.2k

点赞数 1

分类专栏： java 文章标签： java 开发语言后端

于 2022-01-28 23:32:15 首次发布

本文链接：https://blog.csdn.net/seanxwq/article/details/122738050

版权

java 专栏收录该内容

86 篇文章 11 订阅

订阅专栏

James Gosling：对继续坚守 Java8 的朋友，我想说“是时候作出改变了”。新系统全方位性更强、速度更快、错误也更少、扩展效率更高。无论从哪个角度看，大家都有理由接纳 JDK17。确实，大家在从 JDK8 升级到 JDK9 时会遇到一个小问题，这也是 Java 发展史中几乎唯一一次真正重大的版本更替。大多数情况下，Java 新旧版本更替都非常简单。只需要直接安装新版本，一切就能照常运作。长久以来，稳定、非破坏性的升级一直是 Java 的招牌特性之一，我们也不希望破坏这种良好的印象。

这是James Gosling最近在接受采访时，被问及“Java 的版本一直以来更新得比较快，几个月前发布了最新的 Java 17 版本，但 Java 8 仍然是开发人员使用的主要版本，新版本并未‘得宠’，您认为主要的原因是什么？”时的回答。

而随着即将正式发布的Spring framework 6 和Spring Boot 3，最低的Java版本就直接以Java 17起步：

这么一来，如果到时候为了使用最新版本的Spring功能，我们不得不从Java 8升级到Java 17，而期间跳过的版本主要内容如果我们不了解的话，必定会遇到许多问题。

所以，这里，强哥就帮大家总结了Java 9到Java 17的主要内容更新，值得大家收藏。

Java 9

主要更新内容：

平台模块系统（Jigsaw项目）
接口私有方法
Try-With Resources
@SafeVarargs注释
集合工厂方法
Process API改进
JShell:javashell（REPL）
流API改进

Java 9最大特性就是引入了模块化的概念。就是将类型和资源封装在模块中，并仅导出其他模块要访问其公共类型的软件包。有些类似前端框架中的export和import。

如果模块中的软件包未导出或打开，则表示模块的设计人员不想在模块外部使用这些软件包。这样的包可能会被修改或甚至从模块中删除，无需任何通知。

与此同时，模块化将rt.jar包做了拆分，导致了ClassLoader的相应调整：

Java 9之前的ClassLoader

Bootstrap ClassLoader加载rt.jar，jre/lib/endorsed
Ext ClassLoader加载jre/lib/ext
Application ClassLoader加载-cp指定的类

Java 9及之后的ClassLoader

Bootstrap ClassLoader加载lib/modules
Ext ClassLoader更名为Platform ClassLoader，加载lib/modules
Application ClassLoader加载-cp，-mp指定的类
Application ClassLoader父类不再是URLClassLoader

而接口私有方法，允许我们声明有助于在非抽象方法之间共享公共代码的私有方法。在Java 9之前，在接口中创建私有方法会导致编译时错误。

Java 10

主要更新内容：

局部变量的类型推断。
应用类数据共享。为改善启动和占用空间，在现有的类数据共享（“CDS”）功能上再次拓展，以允许应用类放置在共享存档中
向G1引入并行Full GC
线程局部管控。允许停止单个线程，而不是只能启用或停止所有线程
基于Java的JIT 编译器（试验版本）

局部变量类型推断是Java10中为开发人员提供的最大的新特性。它将类型推断添加到带有初始值设定项的局部变量声明中。局部类型推断只能在以下情况下使用：

仅限于具有初始值设定项的局部变量
增强for循环的索引
在for循环中声明的本地

其实就是类似JS的var变量，用法如下：


var numbers = List.of(1, 2, 3, 4, 5); // inferred value ArrayList<String>
// Index of Enhanced For Loop
for (var number : numbers) {
    System.out.println(number);
}
// Local variable declared in a loop
for (var i = 0; i < numbers.size(); i++) {
    System.out.println(numbers.get(i));
}

向G1引入并行FullGC：G1垃圾收集器在jdk9中是默认的。G1垃圾收集器避免了任何完全的垃圾收集，但是当用于收集的并发线程不能足够快地恢复内存时，用户的体验就会受到影响。

此更改通过使完全GC并行来改善G1最坏情况下的延迟。G1收集器的mark-sweep compact算法作为此更改的一部分被并行化，当用于收集的并发线程不能足够快地恢复内存时，它将被触发。

基于Java的实验性 JIT 编译器：Java 10 中开启了基于Java 的JIT编译器Graal，并将其用作Linux/x64平台上的实验性JIT编译器开始进行测试和调试工作。

Graal 是一个以 Java 为主要编程语言、面向Java bytecode 的编译器。与用C++实现的C1及C2相比，它的模块化更加明显，也更加容易维护。将 Graal 编译器研究项目引入到 Java 中，或许能够为 JVM 性能与当前 C++ 所写版本匹敌（或有幸超越）提供基础。

Java 11（LTS）

主要更新内容：

GC垃圾回收器
本地变量类型推断
字符串加强
集合加强
Stream 加强
Optional 加强
InputStream 加强
HTTP Client API
化繁为简，一个命令编译运行源代码

最大变化是Linux版本新增了ZGC。ZGC在Linux X64下的JDK 11以上可用，Mac和Windows上需要JDK 15可用。Java 11 ZGC实测gc时间稳定在3ms左右（当然也许跟场景有关，官方口径一般在10ms以下）。

ZGC一个并发，基于region，压缩型的垃圾收集器，只有root扫描阶段会STW，因此GC停顿时间不会随着堆的增长和存活对象的增长而变长。ZGC和G1停顿时间比较：


ZGC
  avg: 1.091ms (+/-0.215ms)
  95th percentile: 1.380ms
  99th percentile: 1.512ms
  99.9th percentile: 1.663ms
  99.99th percentile: 1.681ms
  max: 1.681ms  
G1
  avg: 156.806ms (+/-71.126ms)
  95th percentile: 316.672ms
  99th percentile: 428.095ms
  99.9th percentile: 543.846ms
  99.99th percentile: 543.846ms
  max: 543.846ms

同时，不得不提的一点是：随着Java 11的发布，在2018.9之后，Oracle JDK正式商用（开发不收费，但是运行线上业务收费）。但是与此同时，Oracle宣布，OpenJDK与Oracle JDK在功能上不会有区别。并且，OpenJDK 11 RTS将会由红帽社区进行维护。这样，更加增加了可靠性与保证问题的及时解决。

Java 12

主要更新内容：