当你还在用 Java8 开发时,突然发现 Java21 已经发布了,Java22 已经在路上。Java 的版本变化也太快了吧。
在 Java9 之前,Java 的版本更新一直都是比较慢的。比如,Java9 和 Java8 之间的间隔时间长达3年半。如此长的发布间隔,显然不能满足当前的需求。
Java9 之后的版本更新
从 Java9 开始,Java 改变了之前的以功能特性为导向的发布周期,而是转为固定时间间隔的火车发布模式,也就是release train。火车定时发车,赶不上这次车的乘客,就只能等下一班火车。
Java的固定发布时间是每年的3月和9月。Java21 是2023年9月发布的,是一个近期发布的长期支持版本。
Java21 新特性
JDK 21 于 2023 年 9 月 19 日 发布,这是一个非常重要的版本,里程碑式。
JDK21 是 LTS(长期支持版),至此为止,目前有 JDK8、JDK11、JDK17 和 JDK21 这四个长期支持版了。
JDK 21 共有 15 个新特性,这篇文章会挑选其中较为重要的一些新特性进行详细介绍:
JEP 430:字符串模板(预览)
String Templates(字符串模板) 目前仍然是 JDK 21 中的一个预览功能。
String Templates 提供了一种更简洁、更直观的方式来动态构建字符串。通过使用占位符${}
,我们可以将变量的值直接嵌入到字符串中,而不需要手动处理。在运行时,Java 编译器会将这些占位符替换为实际的变量值。并且,表达式支持局部变量、静态/非静态字段甚至方法、计算结果等特性。
实际上,String Templates(字符串模板)再大多数编程语言中都存在:
1 | "Greetings {{ name }}!"; //Angular |
Java 在没有 String Templates 之前,我们通常使用字符串拼接或格式化方法来构建字符串:
1 | //concatenation |
这些方法或多或少都存在一些缺点,比如难以阅读、冗长、复杂。
Java 使用 String Templates 进行字符串拼接,可以直接在字符串中嵌入表达式,而无需进行额外的处理:
1 | String message = STR."Greetings \{name}!"; |
在上面的模板表达式中:
- STR 是模板处理器。
\{name}
为表达式,运行时,这些表达式将被相应的变量值替换。
Java 目前支持三种模板处理器:
- STR:自动执行字符串插值,即将模板中的每个嵌入式表达式替换为其值(转换为字符串)。
- FMT:和 STR 类似,但是它还可以接受格式说明符,这些格式说明符出现在嵌入式表达式的左边,用来控制输出的样式
- RAW:不会像 STR 和 FMT 模板处理器那样自动处理字符串模板,而是返回一个
StringTemplate
对象,这个对象包含了模板中的文本和表达式的信息
1 | String name = "Lokesh"; |
除了 JDK 自带的三种模板处理器外,你还可以实现 StringTemplate.Processor
接口来创建自己的模板处理器。
我们可以使用局部变量、静态/非静态字段甚至方法作为嵌入表达式:
1 | //variable |
还可以在表达式中执行计算并打印结果:
1 | int x = 10, y = 20; |
为了提高可读性,我们可以将嵌入的表达式分成多行:
1 | String time = STR."The current time is \{ |
JEP431:序列化集合
JDK 21 引入了一种新的集合类型:Sequenced Collections(序列化集合,也叫有序集合),这是一种具有确定出现顺序(encounter order)的集合(无论我们遍历这样的集合多少次,元素的出现顺序始终是固定的)。序列化集合提供了处理集合的第一个和最后一个元素以及反向视图(与原始集合相反的顺序)的简单方法。
Sequenced Collections 包括以下三个接口:
SequencedCollection
接口继承了 Collection
接口, 提供了在集合两端访问、添加或删除元素以及获取集合的反向视图的方法。
1 | interface SequencedCollection<E> extends Collection<E> { |
List
和 Deque
接口实现了SequencedCollection
接口。
这里以 ArrayList
为例,演示一下实际使用效果:
1 | ArrayList<Integer> arrayList = new ArrayList<>(); |
SequencedSet
接口直接继承了 SequencedCollection
接口并重写了 reversed()
方法。
1 | interface SequencedSet<E> extends SequencedCollection<E>, Set<E> { |
SortedSet
和 LinkedHashSet
实现了SequencedSet
接口。
这里以 LinkedHashSet
为例,演示一下实际使用效果:
1 | LinkedHashSet<Integer> linkedHashSet = new LinkedHashSet<>(List.of(1, 2, 3)); |
SequencedMap
接口继承了 Map
接口, 提供了在集合两端访问、添加或删除键值对、获取包含 key 的 SequencedSet
、包含 value 的 SequencedCollection
、包含 entry(键值对) 的 SequencedSet
以及获取集合的反向视图的方法。
1 | interface SequencedMap<K,V> extends Map<K,V> { |
SortedMap
和LinkedHashMap
实现了SequencedMap
接口。
这里以 LinkedHashMap
为例,演示一下实际使用效果:
1 | LinkedHashMap<Integer, String> map = new LinkedHashMap<>(); |
JEP 439:分代 ZGC
JDK21 中对 ZGC 进行了功能扩展,增加了分代 GC 功能。不过,默认是关闭的,需要通过配置打开:
1 | // 启用分代ZGC |
在未来的版本中,官方会把 ZGenerational 设为默认值,即默认打开 ZGC 的分代 GC。在更晚的版本中,非分代 ZGC 就被移除。
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.
在将来的版本中,我们打算将 Generational ZGC 作为默认选项,此时-XX:-ZGenerational 将选择非分代 ZGC。在更晚的版本中,我们打算移除非分代 ZGC,此时 ZGenerational 选项将变得过时。
分代 ZGC 可以显著减少垃圾回收过程中的停顿时间,并提高应用程序的响应性能。这对于大型 Java 应用程序和高并发场景下的性能优化非常有价值。
JEP 440:记录模式
记录模式在 Java 19 进行了第一次预览, 由 JEP 405 提出。JDK 20 中是第二次预览,由 JEP 432 提出。最终,记录模式在 JDK21 顺利转正。
Java 20 新特性概览已经详细介绍过记录模式,这里就不重复了。
JEP 441:switch 的模式匹配
增强 Java 中的 switch 表达式和语句,允许在 case 标签中使用模式。当模式匹配时,执行 case 标签对应的代码。
在下面的代码中,switch 表达式使用了类型模式来进行匹配。
1 | static String formatterPatternSwitch(Object obj) { |
JEP 442: 外部函数和内存 API(第三次预览)
Java 程序可以通过该 API 与 Java 运行时之外的代码和数据进行互操作。通过高效地调用外部函数(即 JVM 之外的代码)和安全地访问外部内存(即不受 JVM 管理的内存),该 API 使 Java 程序能够调用本机库并处理本机数据,而不会像 JNI 那样危险和脆弱。
外部函数和内存 API 在 Java 17 中进行了第一轮孵化,由 JEP 412 提出。Java 18 中进行了第二次孵化,由JEP 419 提出。Java 19 中是第一次预览,由 JEP 424 提出。JDK 20 中是第二次预览,由 JEP 434 提出。JDK 21 中是第三次预览,由 JEP 442 提出。
在 Java 19 新特性概览中,我有详细介绍到外部函数和内存 API,这里就不再做额外的介绍了。
JEP 443:未命名模式和变量(预览)
未命名模式和变量使得我们可以使用下划线 _
表示未命名的变量以及模式匹配时不使用的组件,旨在提高代码的可读性和可维护性。
未命名变量的典型场景是 try-with-resources
语句、 catch
子句中的异常变量和for
循环。当变量不需要使用的时候就可以使用下划线 _
代替,这样清晰标识未被使用的变量。
1 | try (var _ = ScopedContext.acquire()) { |
未命名模式是一个无条件的模式,并不绑定任何值。未命名模式变量出现在类型模式中。
1 | if (r instanceof ColoredPoint(_, Color c)) { ... c ... } |
JEP 444:虚拟线程
虚拟线程是一项重量级的更新,一定一定要重视!
虚拟线程在 Java 19 中进行了第一次预览,由JEP 425提出。JDK 20 中是第二次预览。最终,虚拟线程在 JDK21 顺利转正。
Java 20 新特性概览已经详细介绍过虚拟线程,这里就不重复了。
JEP 445:未命名类和实例 main 方法 (预览)
这个特性主要简化了 main
方法的的声明。对于 Java 初学者来说,这个 main
方法的声明引入了太多的 Java 语法概念,不利于初学者快速上手。
没有使用该特性之前定义一个 main
方法:
1 | public class HelloWorld { |
使用该新特性之后定义一个 main
方法:
1 | class HelloWorld { |
进一步精简(未命名的类允许我们不定义类名):
1 | void main() { |
参考
- Java 21 String Templates:https://howtodoinjava.com/java/java-string-templates/
- Java 21 Sequenced Collections:https://howtodoinjava.com/java/sequenced-collections/
Java20 新特性
JDK 20 于 2023 年 3 月 21 日发布,非长期支持版本。
根据开发计划,下一个 LTS 版本就是将于 2023 年 9 月发布的 JDK 21。
JDK 20 只有 7 个新特性:
- JEP 429:Scoped Values(作用域值)(第一次孵化)
- JEP 432:Record Patterns(记录模式)(第二次预览)
- JEP 433:switch 模式匹配(第四次预览)
- JEP 434: Foreign Function & Memory API(外部函数和内存 API)(第二次预览)
- JEP 436: Virtual Threads(虚拟线程)(第二次预览)
- JEP 437:Structured Concurrency(结构化并发)(第二次孵化)
- JEP 432:向量 API(第五次孵化)
JEP 429:作用域值(第一次孵化)
作用域值(Scoped Values)它可以在线程内和线程间共享不可变的数据,优于线程局部变量,尤其是在使用大量虚拟线程时。
1 | final static ScopedValue<...> V = new ScopedValue<>(); |
作用域值允许在大型程序中的组件之间安全有效地共享数据,而无需求助于方法参数。
关于作用域值的详细介绍,推荐阅读作用域值常见问题解答这篇文章。
JEP 432:记录模式(第二次预览)
记录模式(Record Patterns) 可对 record 的值进行解构,也就是更方便地从记录类(Record Class)中提取数据。并且,还可以嵌套记录模式和类型模式结合使用,以实现强大的、声明性的和可组合的数据导航和处理形式。
记录模式不能单独使用,而是要与 instanceof 或 switch 模式匹配一同使用。
先以 instanceof 为例简单演示一下。
简单定义一个记录类:
1 | record Shape(String type, long unit){} |
没有记录模式之前:
1 | Shape circle = new Shape("Circle", 10); |
有了记录模式之后:
1 | Shape circle = new Shape("Circle", 10); |
再看看记录模式与 switch 的配合使用。
定义一些类:
1 | interface Shape {} |
没有记录模式之前:
1 | Shape shape = new Circle(10); |
有了记录模式之后:
1 | Shape shape = new Circle(10); |
记录模式可以避免不必要的转换,使得代码更建简洁易读。而且,用了记录模式后不必再担心 null
或者 NullPointerException
,代码更安全可靠。
记录模式在 Java 19 进行了第一次预览, 由 JEP 405 提出。JDK 20 中是第二次预览,由 JEP 432 提出。这次的改进包括:
- 添加对通用记录模式类型参数推断的支持,
- 添加对记录模式的支持以出现在增强语句的标题中
for
- 删除对命名记录模式的支持。
注意:不要把记录模式和 JDK16 正式引入的记录类搞混了。
JEP 433:switch 模式匹配(第四次预览)
正如 instanceof
一样, switch
也紧跟着增加了类型匹配自动转换功能。
instanceof
代码示例:
1 | // Old code |
switch
代码示例:
1 | // Old code |
switch
模式匹配分别在 Java17、Java18、Java19 中进行了预览,Java20 是第四次预览了。每一次的预览基本都会有一些小改进,这里就不细提了。
JEP 434: 外部函数和内存 API(第二次预览)
Java 程序可以通过该 API 与 Java 运行时之外的代码和数据进行互操作。通过高效地调用外部函数(即 JVM 之外的代码)和安全地访问外部内存(即不受 JVM 管理的内存),该 API 使 Java 程序能够调用本机库并处理本机数据,而不会像 JNI 那样危险和脆弱。
外部函数和内存 API 在 Java 17 中进行了第一轮孵化,由 JEP 412 提出。Java 18 中进行了第二次孵化,由JEP 419 提出。Java 19 中是第一次预览,由 JEP 424 提出。
JDK 20 中是第二次预览,由 JEP 434 提出,这次的改进包括:
MemorySegment
和MemoryAddress
抽象的统一- 增强的
MemoryLayout
层次结构 MemorySession
拆分为Arena
和SegmentScope
,以促进跨维护边界的段共享。
在 Java 19 新特性概览中,我有详细介绍到外部函数和内存 API,这里就不再做额外的介绍了。
JEP 436: 虚拟线程(第二次预览)
虚拟线程(Virtual Thread)是 JDK 而不是 OS 实现的轻量级线程(Lightweight Process,LWP),由 JVM 调度。许多虚拟线程共享同一个操作系统线程,虚拟线程的数量可以远大于操作系统线程的数量。
在引入虚拟线程之前,java.lang.Thread
包已经支持所谓的平台线程,也就是没有虚拟线程之前,我们一直使用的线程。JVM 调度程序通过平台线程(载体线程)来管理虚拟线程,一个平台线程可以在不同的时间执行不同的虚拟线程(多个虚拟线程挂载在一个平台线程上),当虚拟线程被阻塞或等待时,平台线程可以切换到执行另一个虚拟线程。
虚拟线程、平台线程和系统内核线程的关系图如下所示(图源:How to Use Java 19 Virtual Threads):
关于平台线程和系统内核线程的对应关系多提一点:在 Windows 和 Linux 等主流操作系统中,Java 线程采用的是一对一的线程模型,也就是一个平台线程对应一个系统内核线程。Solaris 系统是一个特例,HotSpot VM 在 Solaris 上支持多对多和一对一。具体可以参考 R 大的回答: JVM 中的线程模型是用户级的么?。
相比较于平台线程来说,虚拟线程是廉价且轻量级的,使用完后立即被销毁,因此它们不需要被重用或池化,每个任务可以有自己专属的虚拟线程来运行。虚拟线程暂停和恢复来实现线程之间的切换,避免了上下文切换的额外耗费,兼顾了多线程的优点,简化了高并发程序的复杂,可以有效减少编写、维护和观察高吞吐量并发应用程序的工作量。
虚拟线程在其他多线程语言中已经被证实是十分有用的,比如 Go 中的 Goroutine、Erlang 中的进程。
知乎有一个关于 Java 19 虚拟线程的讨论,感兴趣的可以去看看:https://www.zhihu.com/question/536743167 。
Java 虚拟线程的详细解读和原理可以看下面这几篇文章:
虚拟线程在 Java 19 中进行了第一次预览,由JEP 425提出。JDK 20 中是第二次预览,做了一些细微变化,这里就不细提了。
最后,我们来看一下四种创建虚拟线程的方法:
1 | // 1、通过 Thread.ofVirtual() 创建 |
通过上述列举的 4 种创建虚拟线程的方式可以看出,官方为了降低虚拟线程的门槛,尽力复用原有的 Thread
线程类,这样可以平滑的过渡到虚拟线程的使用。
JEP 437: 结构化并发(第二次孵化)
Java 19 引入了结构化并发,一种多线程编程方法,目的是为了通过结构化并发 API 来简化多线程编程,并不是为了取代java.util.concurrent
,目前处于孵化器阶段。
结构化并发将不同线程中运行的多个任务视为单个工作单元,从而简化错误处理、提高可靠性并增强可观察性。也就是说,结构化并发保留了单线程代码的可读性、可维护性和可观察性。
结构化并发的基本 API 是StructuredTaskScope
。StructuredTaskScope
支持将任务拆分为多个并发子任务,在它们自己的线程中执行,并且子任务必须在主任务继续之前完成。
StructuredTaskScope
的基本用法如下:
1 | try (var scope = new StructuredTaskScope<Object>()) { |
结构化并发非常适合虚拟线程,虚拟线程是 JDK 实现的轻量级线程。许多虚拟线程共享同一个操作系统线程,从而允许非常多的虚拟线程。
JDK 20 中对结构化并发唯一变化是更新为支持在任务范围内创建的线程StructuredTaskScope
继承范围值 这简化了跨线程共享不可变数据,详见JEP 429。
JEP 432:向量 API(第五次孵化)
向量计算由对向量的一系列操作组成。向量 API 用来表达向量计算,该计算可以在运行时可靠地编译为支持的 CPU 架构上的最佳向量指令,从而实现优于等效标量计算的性能。
向量 API 的目标是为用户提供简洁易用且与平台无关的表达范围广泛的向量计算。
向量(Vector) API 最初由 JEP 338 提出,并作为孵化 API集成到 Java 16 中。第二轮孵化由 JEP 414 提出并集成到 Java 17 中,第三轮孵化由 JEP 417 提出并集成到 Java 18 中,第四轮由 JEP 426 提出并集成到了 Java 19 中。
Java20 的这次孵化基本没有改变向量 API ,只是进行了一些错误修复和性能增强,详见 JEP 438。
Java19 新特性
JDK 19 定于 2022 年 9 月 20 日正式发布以供生产使用,非长期支持版本。不过,JDK 19 中有一些比较重要的新特性值得关注。
JDK 19 只有 7 个新特性:
- JEP 405: Record Patterns(记录模式)(预览)
- JEP 422: Linux/RISC-V Port
- JEP 424: Foreign Function & Memory API(外部函数和内存 API)(预览)
- JEP 425: Virtual Threads(虚拟线程)(预览)
- JEP 426: Vector(向量)API(第四次孵化)
- JEP 427: Pattern Matching for switch(switch 模式匹配)
- JEP 428: Structured Concurrency(结构化并发)(孵化)
这里只对 424、425、426、428 这 4 个我觉得比较重要的新特性进行详细介绍。
相关阅读:OpenJDK Java 19 文档
JEP 424: 外部函数和内存 API(预览)
Java 程序可以通过该 API 与 Java 运行时之外的代码和数据进行互操作。通过高效地调用外部函数(即 JVM 之外的代码)和安全地访问外部内存(即不受 JVM 管理的内存),该 API 使 Java 程序能够调用本机库并处理本机数据,而不会像 JNI 那样危险和脆弱。
外部函数和内存 API 在 Java 17 中进行了第一轮孵化,由 JEP 412 提出。第二轮孵化由JEP 419 提出并集成到了 Java 18 中,预览由 JEP 424 提出并集成到了 Java 19 中。
在没有外部函数和内存 API 之前:
- Java 通过
sun.misc.Unsafe
提供一些执行低级别、不安全操作的方法(如直接访问系统内存资源、自主管理内存资源等),Unsafe
类让 Java 语言拥有了类似 C 语言指针一样操作内存空间的能力的同时,也增加了 Java 语言的不安全性,不正确使用Unsafe
类会使得程序出错的概率变大。 - Java 1.1 就已通过 Java 原生接口(JNI)支持了原生方法调用,但并不好用。JNI 实现起来过于复杂,步骤繁琐(具体的步骤可以参考这篇文章:Guide to JNI (Java Native Interface) ),不受 JVM 的语言安全机制控制,影响 Java 语言的跨平台特性。并且,JNI 的性能也不行,因为 JNI 方法调用不能从许多常见的 JIT 优化(如内联)中受益。虽然JNA、JNR和JavaCPP等框架对 JNI 进行了改进,但效果还是不太理想。
引入外部函数和内存 API 就是为了解决 Java 访问外部函数和外部内存存在的一些痛点。
Foreign Function & Memory API (FFM API) 定义了类和接口:
- 分配外部内存:
MemorySegment
、、MemoryAddress
和SegmentAllocator
); - 操作和访问结构化的外部内存:
MemoryLayout
,VarHandle
; - 控制外部内存的分配和释放:
MemorySession
; - 调用外部函数:
Linker
、FunctionDescriptor
和SymbolLookup
。
下面是 FFM API 使用示例,这段代码获取了 C 库函数的 radixsort
方法句柄,然后使用它对 Java 数组中的四个字符串进行排序。
1 | // 1. 在C库路径上查找外部函数 |
JEP 425: 虚拟线程(预览)
虚拟线程(Virtual Thread-)是 JDK 而不是 OS 实现的轻量级线程(Lightweight Process,LWP),许多虚拟线程共享同一个操作系统线程,虚拟线程的数量可以远大于操作系统线程的数量。
虚拟线程在其他多线程语言中已经被证实是十分有用的,比如 Go 中的 Goroutine、Erlang 中的进程。
虚拟线程避免了上下文切换的额外耗费,兼顾了多线程的优点,简化了高并发程序的复杂,可以有效减少编写、维护和观察高吞吐量并发应用程序的工作量。
知乎有一个关于 Java 19 虚拟线程的讨论,感兴趣的可以去看看:https://www.zhihu.com/question/536743167 。
Java 虚拟线程的详细解读和原理可以看下面这两篇文章:
JEP 426: 向量 API(第四次孵化)
向量(Vector) API 最初由 JEP 338 提出,并作为孵化 API集成到 Java 16 中。第二轮孵化由 JEP 414 提出并集成到 Java 17 中,第三轮孵化由 JEP 417 提出并集成到 Java 18 中,第四轮由 JEP 426 提出并集成到了 Java 19 中。
在 Java 18 新特性概览 中,我有详细介绍到向量 API,这里就不再做额外的介绍了。
JEP 428: 结构化并发(孵化)
JDK 19 引入了结构化并发,一种多线程编程方法,目的是为了通过结构化并发 API 来简化多线程编程,并不是为了取代java.util.concurrent
,目前处于孵化器阶段。
结构化并发将不同线程中运行的多个任务视为单个工作单元,从而简化错误处理、提高可靠性并增强可观察性。也就是说,结构化并发保留了单线程代码的可读性、可维护性和可观察性。
结构化并发的基本 API 是StructuredTaskScope
。StructuredTaskScope
支持将任务拆分为多个并发子任务,在它们自己的线程中执行,并且子任务必须在主任务继续之前完成。
StructuredTaskScope
的基本用法如下:
1 | try (var scope = new StructuredTaskScope<Object>()) { |
结构化并发非常适合虚拟线程,虚拟线程是 JDK 实现的轻量级线程。许多虚拟线程共享同一个操作系统线程,从而允许非常多的虚拟线程。
Java18 新特性
Java 18 在 2022 年 3 月 22 日正式发布,非长期支持版本。
Java 18 带来了 9 个新特性:
- JEP 400:UTF-8 by Default(默认字符集为 UTF-8)
- JEP 408:Simple Web Server(简易的 Web 服务器)
- JEP 413:Code Snippets in Java API Documentation(Java API 文档中的代码片段)
- JEP 416:Reimplement Core Reflection with Method Handles(使用方法句柄重新实现反射核心)
- JEP 417:Vector(向量) API(第三次孵化)
- JEP 418:Internet-Address Resolution(互联网地址解析)SPI
- JEP 419:Foreign Function & Memory API(外部函数和内存 API)(第二次孵化)
- JEP 420:Pattern Matching for switch(switch 模式匹配)(第二次预览)
- JEP 421:Deprecate Finalization for Removal
Java 17 中包含 14 个特性,Java 16 中包含 17 个特性,Java 15 中包含 14 个特性,Java 14 中包含 16 个特性。相比于前面发布的版本来说,Java 18 的新特性少了很多。
这里只对 400、408、413、416、417、418、419 这几个我觉得比较重要的新特性进行详细介绍。
相关阅读:
JEP 400:默认字符集为 UTF-8
JDK 终于将 UTF-8 设置为默认字符集。
在 Java 17 及更早版本中,默认字符集是在 Java 虚拟机运行时才确定的,取决于不同的操作系统、区域设置等因素,因此存在潜在的风险。就比如说你在 Mac 上运行正常的一段打印文字到控制台的 Java 程序到了 Windows 上就会出现乱码,如果你不手动更改字符集的话。
JEP 408:简易的 Web 服务器
Java 18 之后,你可以使用 jwebserver
命令启动一个简易的静态 Web 服务器。
1 | $ jwebserver |
这个服务器不支持 CGI 和 Servlet,只限于静态文件。
JEP 413:优化 Java API 文档中的代码片段
在 Java 18 之前,如果我们想要在 Javadoc 中引入代码片段可以使用 <pre>{@code ...}</pre>
。
1 | <pre>{ |
<pre>{@code ...}</pre>
这种方式生成的效果比较一般。
在 Java 18 之后,可以通过 @snippet
标签来做这件事情。
1 | /** |
@snippet
这种方式生成的效果更好且使用起来更方便一些。
JEP 416:使用方法句柄重新实现反射核心
Java 18 改进了 java.lang.reflect.Method
、Constructor
的实现逻辑,使之性能更好,速度更快。这项改动不会改动相关 API ,这意味着开发中不需要改动反射相关代码,就可以体验到性能更好反射。
OpenJDK 官方给出了新老实现的反射性能基准测试结果。
JEP 417: 向量 API(第三次孵化)
向量(Vector) API 最初由 JEP 338 提出,并作为孵化 API集成到 Java 16 中。第二轮孵化由 JEP 414 提出并集成到 Java 17 中,第三轮孵化由 JEP 417 提出并集成到 Java 18 中,第四轮由 JEP 426 提出并集成到了 Java 19 中。
向量计算由对向量的一系列操作组成。向量 API 用来表达向量计算,该计算可以在运行时可靠地编译为支持的 CPU 架构上的最佳向量指令,从而实现优于等效标量计算的性能。
向量 API 的目标是为用户提供简洁易用且与平台无关的表达范围广泛的向量计算。
这是对数组元素的简单标量计算:
1 | void scalarComputation(float[] a, float[] b, float[] c) { |
这是使用 Vector API 进行的等效向量计算:
1 | static final VectorSpecies<Float> SPECIES = FloatVector.SPECIES_PREFERRED; |
在 JDK 18 中,向量 API 的性能得到了进一步的优化。
JEP 418:互联网地址解析 SPI
Java 18 定义了一个全新的 SPI(service-provider interface),用于主要名称和地址的解析,以便 java.net.InetAddress
可以使用平台之外的第三方解析器。
JEP 419:Foreign Function & Memory API(第二次孵化)
Java 程序可以通过该 API 与 Java 运行时之外的代码和数据进行互操作。通过高效地调用外部函数(即 JVM 之外的代码)和安全地访问外部内存(即不受 JVM 管理的内存),该 API 使 Java 程序能够调用本机库并处理本机数据,而不会像 JNI 那样危险和脆弱。
外部函数和内存 API 在 Java 17 中进行了第一轮孵化,由 JEP 412 提出。第二轮孵化由JEP 419 提出并集成到了 Java 18 中,预览由 JEP 424 提出并集成到了 Java 19 中。
Java17 新特性
Java 17 在 2021 年 9 月 14 日正式发布,是一个长期支持(LTS)版本。
下面这张图是 Oracle 官方给出的 Oracle JDK 支持的时间线。可以看得到,Java
17 最多可以支持到 2029 年 9 月份。
Java 17 将是继 Java 8 以来最重要的长期支持(LTS)版本,是 Java 社区八年努力的成果。Spring 6.x 和 Spring Boot 3.x 最低支持的就是 Java 17。
这次更新共带来 14 个新特性:
- JEP 306:Restore Always-Strict Floating-Point Semantics(恢复始终严格的浮点语义)
- JEP 356:Enhanced Pseudo-Random Number Generators(增强的伪随机数生成器)
- JEP 382:New macOS Rendering Pipeline(新的 macOS 渲染管道)
- JEP 391:macOS/AArch64 Port(支持 macOS AArch64)
- JEP 398:Deprecate the Applet API for Removal(删除已弃用的 Applet API)
- JEP 403:Strongly Encapsulate JDK Internals(更强大的封装 JDK 内部元素)
- JEP 406:Pattern Matching for switch (switch 的类型匹配)(预览)
- JEP 407:Remove RMI Activation(删除远程方法调用激活机制)
- JEP 409:Sealed Classes(密封类)(转正)
- JEP 410:Remove the Experimental AOT and JIT Compiler(删除实验性的 AOT 和 JIT 编译器)
- JEP 411:Deprecate the Security Manager for Removal(弃用安全管理器以进行删除)
- JEP 412:Foreign Function & Memory API (外部函数和内存 API)(孵化)
- JEP 414:Vector(向量) API(第二次孵化)
- JEP 415:Context-Specific Deserialization Filters
这里只对 356、398、413、406、407、409、410、411、412、414 这几个我觉得比较重要的新特性进行详细介绍。
相关阅读:OpenJDK Java 17 文档 。
JEP 356:增强的伪随机数生成器
JDK 17 之前,我们可以借助 Random
、ThreadLocalRandom
和SplittableRandom
来生成随机数。不过,这 3 个类都各有缺陷,且缺少常见的伪随机算法支持。
Java 17 为伪随机数生成器 (pseudorandom number generator,PRNG,又称为确定性随机位生成器)增加了新的接口类型和实现,使得开发者更容易在应用程序中互换使用各种 PRNG 算法。
PRNG 用来生成接近于绝对随机数序列的数字序列。一般来说,PRNG 会依赖于一个初始值,也称为种子,来生成对应的伪随机数序列。只要种子确定了,PRNG 所生成的随机数就是完全确定的,因此其生成的随机数序列并不是真正随机的。
使用示例:
1 | RandomGeneratorFactory<RandomGenerator> l128X256MixRandom = RandomGeneratorFactory.of("L128X256MixRandom"); |
JEP 398:弃用 Applet API 以进行删除
Applet API 用于编写在 Web 浏览器端运行的 Java 小程序,很多年前就已经被淘汰了,已经没有理由使用了。
Applet API 在 Java 9 时被标记弃用(JEP 289),但不是为了删除。
JEP 406:switch 的类型匹配(预览)
正如 instanceof
一样, switch
也紧跟着增加了类型匹配自动转换功能。
instanceof
代码示例:
1 | // Old code |
switch
代码示例:
1 | // Old code |
对于 null
值的判断也进行了优化。
1 | // Old code |
JEP 407:删除远程方法调用激活机制
删除远程方法调用 (RMI) 激活机制,同时保留 RMI 的其余部分。RMI 激活机制已过时且不再使用。
JEP 409:密封类(转正)
密封类由 JEP 360 提出预览,集成到了 Java 15 中。在 JDK 16 中, 密封类得到了改进(更加严格的引用检查和密封类的继承关系),由 JEP 397 提出了再次预览。
在 Java 14 & 15 新特性概览 中,我有详细介绍到密封类,这里就不再做额外的介绍了。
JEP 410:删除实验性的 AOT 和 JIT 编译器
在 Java 9 的 JEP 295 ,引入了实验性的提前 (AOT) 编译器,在启动虚拟机之前将 Java 类编译为本机代码。
Java 17,删除实验性的提前 (AOT) 和即时 (JIT) 编译器,因为该编译器自推出以来很少使用,维护它所需的工作量很大。保留实验性的 Java 级 JVM 编译器接口 (JVMCI),以便开发人员可以继续使用外部构建的编译器版本进行 JIT 编译。
JEP 411:弃用安全管理器以进行删除
弃用安全管理器以便在将来的版本中删除。
安全管理器可追溯到 Java 1.0,多年来,它一直不是保护客户端 Java 代码的主要方法,也很少用于保护服务器端代码。为了推动 Java 向前发展,Java 17 弃用安全管理器,以便与旧版 Applet API ( JEP 398 ) 一起移除。
JEP 412:外部函数和内存 API(孵化)
Java 程序可以通过该 API 与 Java 运行时之外的代码和数据进行互操作。通过高效地调用外部函数(即 JVM 之外的代码)和安全地访问外部内存(即不受 JVM 管理的内存),该 API 使 Java 程序能够调用本机库并处理本机数据,而不会像 JNI 那样危险和脆弱。
外部函数和内存 API 在 Java 17 中进行了第一轮孵化,由 JEP 412 提出。第二轮孵化由JEP 419 提出并集成到了 Java 18 中,预览由 JEP 424 提出并集成到了 Java 19 中。
在 Java 19 新特性概览 中,我有详细介绍到外部函数和内存 API,这里就不再做额外的介绍了。
JEP 414:向量 API(第二次孵化)
向量(Vector) API 最初由 JEP 338 提出,并作为孵化 API集成到 Java 16 中。第二轮孵化由 JEP 414 提出并集成到 Java 17 中,第三轮孵化由 JEP 417 提出并集成到 Java 18 中,第四轮由 JEP 426 提出并集成到了 Java 19 中。
该孵化器 API 提供了一个 API 的初始迭代以表达一些向量计算,这些计算在运行时可靠地编译为支持的 CPU 架构上的最佳向量硬件指令,从而获得优于同等标量计算的性能,充分利用单指令多数据(SIMD)技术(大多数现代 CPU 上都可以使用的一种指令)。尽管 HotSpot 支持自动向量化,但是可转换的标量操作集有限且易受代码更改的影响。该 API 将使开发人员能够轻松地用 Java 编写可移植的高性能向量算法。
在 Java 18 新特性概览 中,我有详细介绍到向量 API,这里就不再做额外的介绍了。
Java16 新特性
Java 16 在 2021 年 3 月 16 日正式发布,非长期支持(LTS)版本。
相关阅读:OpenJDK Java 16 文档 。
JEP 338:向量 API(第一次孵化)
向量(Vector) API 最初由 JEP 338 提出,并作为孵化 API集成到 Java 16 中。第二轮孵化由 JEP 414 提出并集成到 Java 17 中,第三轮孵化由 JEP 417 提出并集成到 Java 18 中,第四轮由 JEP 426 提出并集成到了 Java 19 中。
该孵化器 API 提供了一个 API 的初始迭代以表达一些向量计算,这些计算在运行时可靠地编译为支持的 CPU 架构上的最佳向量硬件指令,从而获得优于同等标量计算的性能,充分利用单指令多数据(SIMD)技术(大多数现代 CPU 上都可以使用的一种指令)。尽管 HotSpot 支持自动向量化,但是可转换的标量操作集有限且易受代码更改的影响。该 API 将使开发人员能够轻松地用 Java 编写可移植的高性能向量算法。
在 Java 18 新特性概览 中,我有详细介绍到向量 API,这里就不再做额外的介绍了。
JEP 347:启用 C++ 14 语言特性
Java 16 允许在 JDK 的 C++ 源代码中使用 C++14 语言特性,并提供在 HotSpot 代码中可以使用哪些特性的具体指导。
在 Java 15 中,JDK 中 C++ 代码使用的语言特性仅限于 C++98/03 语言标准。它要求更新各种平台编译器的最低可接受版本。
JEP 376:ZGC 并发线程堆栈处理
Java16 将 ZGC 线程栈处理从安全点转移到一个并发阶段,甚至在大堆上也允许在毫秒内暂停 GC 安全点。消除 ZGC 垃圾收集器中最后一个延迟源可以极大地提高应用程序的性能和效率。
JEP 387:弹性元空间
自从引入了 Metaspace 以来,根据反馈,Metaspace 经常占用过多的堆外内存,从而导致内存浪费。弹性元空间这个特性可将未使用的 HotSpot 类元数据(即元空间,metaspace)内存更快速地返回到操作系统,从而减少元空间的占用空间。
并且,这个提案还简化了元空间的代码以降低维护成本。
JEP 390:对基于值的类发出警告
以下介绍摘自:实操 | 剖析 Java16 新语法特性,原文写的很不错,推荐阅读。
早在 Java9 版本时,Java 的设计者们就对 @Deprecated
注解进行了一次升级,增加了 since
和 forRemoval
等 2 个新元素。其中,since 元素用于指定标记了 @Deprecated
注解的 API 被弃用时的版本,而 forRemoval
则进一步明确了 API 标记 @Deprecated 注解时的语义,如果forRemoval=true
时,则表示该 API 在未来版本中肯定会被删除,开发人员应该使用新的 API 进行替代,不再容易产生歧义(Java9 之前,标记 @Deprecated 注解的 API,语义上存在多种可能性,比如:存在使用风险、可能在未来存在兼容性错误、可能在未来版本中被删除,以及应该使用更好的替代方案等)。
仔细观察原始类型的包装类(比如:java.lang.Integer
、java.lang.Double
),不难发现,其构造函数上都已经标记有@Deprecated(since="9", forRemoval = true)
注解,这就意味着其构造函数在将来会被删除,不应该在程序中继续使用诸如new Integer();
这样的编码方式(建议使用Integer a = 10;
或者Integer.valueOf()
函数),如果继续使用,编译期将会产生’Integer(int)’ is deprecated and marked for removal 告警。并且,值得注意的是,这些包装类型已经被指定为同 java.util.Optional
和 java.time.LocalDateTime
一样的值类型。
其次,如果继续在 synchronized
同步块中使用值类型,将会在编译期和运行期产生警告,甚至是异常。在此大家需要注意,就算编译期和运行期没有产生警告和异常,也不建议在 synchronized
同步块中使用值类型,举个自增的例子。示例 1-5:
1 | public void inc(Integer count) { |
当执行上述程序示例时,最终的输出结果一定会与你的期望产生差异,这是许多新人经常犯错的一个点,因为在并发环境下,Integer
对象根本无法通过 synchronized
来保证线程安全,这是因为每次的count++
操作,所产生的 hashcode
均不同,简而言之,每次加锁都锁在了不同的对象上。因此,如果希望在实际的开发过程中保证其原子性,应该使用 AtomicInteger
。
JEP 392:打包工具
在 Java 14 中,JEP 343 引入了打包工具,命令是 jpackage
。在 Java 15 中,继续孵化,现在在 Java 16 中,终于成为了正式功能。
这个打包工具允许打包自包含的 Java 应用程序。它支持原生打包格式,为最终用户提供自然的安装体验,这些格式包括 Windows 上的 msi 和 exe、macOS 上的 pkg 和 dmg,还有 Linux 上的 deb 和 rpm。它还允许在打包时指定启动时参数,并且可以从命令行直接调用,也可以通过 ToolProvider API 以编程方式调用。注意 jpackage 模块名称从 jdk.incubator.jpackage 更改为 jdk.jpackage。这将改善最终用户在安装应用程序时的体验,并简化了“应用商店”模型的部署。
关于这个打包工具的实际使用,可以看这个视频 Playing with Java 16 jpackage(需要梯子)。
JEP 393:外部内存访问 API(第三次孵化)
引入外部内存访问 API 以允许 Java 程序安全有效地访问 Java 堆之外的外部内存。
Java 14(JEP 370) 的时候,第一次孵化外部内存访问 API,Java 15 中进行了第二次复活(JEP 383),在 Java 16 中进行了第三次孵化。
引入外部内存访问 API 的目的如下:
- 通用:单个 API 应该能够对各种外部内存(如本机内存、持久内存、堆内存等)进行操作。
- 安全:无论操作何种内存,API 都不应该破坏 JVM 的安全性。
- 控制:可以自由的选择如何释放内存(显式、隐式等)。
- 可用:如果需要访问外部内存,API 应该是
sun.misc.Unsafe
.
JEP 394:instanceof 模式匹配(转正)
JDK 版本 | 更新类型 | JEP | 更新内容 |
---|---|---|---|
Java SE 14 | preview | JEP 305 | 首次引入 instanceof 模式匹配。 |
Java SE 15 | Second Preview | JEP 375 | 相比较上个版本无变化,继续收集更多反馈。 |
Java SE 16 | Permanent Release | JEP 394 | 模式变量不再隐式为 final。 |
从 Java 16 开始,你可以对 instanceof
中的变量值进行修改。
1 | // Old code |
JEP 395:记录类型(转正)
记录类型变更历史:
JDK 版本 | 更新类型 | JEP | 更新内容 |
---|---|---|---|
Java SE 14 | Preview | JEP 359 | 引入 record 关键字,record 提供一种紧凑的语法来定义类中的不可变数据。 |
Java SE 15 | Second Preview | JEP 384 | 支持在局部方法和接口中使用 record 。 |
Java SE 16 | Permanent Release | JEP 395 | 非静态内部类可以定义非常量的静态成员。 |
从 Java SE 16 开始,非静态内部类可以定义非常量的静态成员。
1 | public class Outer { |
在 JDK 16 之前,如果写上面这种代码,IDE 会提示你静态字段 age 不能在非静态的内部类中定义,除非它用一个常量表达式初始化。(The field age cannot be declared static in a non-static inner type, unless initialized with a constant expression)
JEP 396:默认强封装 JDK 内部元素
此特性会默认强封装 JDK 的所有内部元素,但关键内部 API(例如 sun.misc.Unsafe
)除外。默认情况下,使用早期版本成功编译的访问 JDK 内部 API 的代码可能不再起作用。鼓励开发人员从使用内部元素迁移到使用标准 API 的方法上,以便他们及其用户都可以无缝升级到将来的 Java 版本。强封装由 JDK 9 的启动器选项–illegal-access 控制,到 JDK 15 默认改为 warning,从 JDK 16 开始默认为 deny。(目前)仍然可以使用单个命令行选项放宽对所有软件包的封装,将来只有使用–add-opens 打开特定的软件包才行。
JEP 397:密封类(预览)
密封类由 JEP 360 提出预览,集成到了 Java 15 中。在 JDK 16 中, 密封类得到了改进(更加严格的引用检查和密封类的继承关系),由 JEP 397 提出了再次预览。
在 Java 14 & 15 新特性概览中,我有详细介绍到密封类,这里就不再做额外的介绍了。
其他优化与改进
- JEP 380:Unix-Domain 套接字通道:Unix-domain 套接字一直是大多数 Unix 平台的一个特性,现在在 Windows 10 和 Windows Server 2019 也提供了支持。此特性为 java.nio.channels 包的套接字通道和服务器套接字通道 API 添加了 Unix-domain(AF_UNIX)套接字支持。它扩展了继承的通道机制以支持 Unix-domain 套接字通道和服务器套接字通道。Unix-domain 套接字用于同一主机上的进程间通信(IPC)。它们在很大程度上类似于 TCP/IP,区别在于套接字是通过文件系统路径名而不是 Internet 协议(IP)地址和端口号寻址的。对于本地进程间通信,Unix-domain 套接字比 TCP/IP 环回连接更安全、更有效
- JEP 389:外部链接器 API(孵化): 该孵化器 API 提供了静态类型、纯 Java 访问原生代码的特性,该 API 将大大简化绑定原生库的原本复杂且容易出错的过程。Java 1.1 就已通过 Java 原生接口(JNI)支持了原生方法调用,但并不好用。Java 开发人员应该能够为特定任务绑定特定的原生库。它还提供了外来函数支持,而无需任何中间的 JNI 粘合代码。
- JEP 357:从 Mercurial 迁移到 Git:在此之前,OpenJDK 源代码是使用版本管理工具 Mercurial 进行管理,现在迁移到了 Git。
- JEP 369:迁移到 GitHub:和 JEP 357 从 Mercurial 迁移到 Git 的改变一致,在把版本管理迁移到 Git 之后,选择了在 GitHub 上托管 OpenJDK 社区的 Git 仓库。不过只对 JDK 11 以及更高版本 JDK 进行了迁移。
- JEP 386:移植 Alpine Linux:Alpine Linux 是一个独立的、非商业的 Linux 发行版,它十分的小,一个容器需要不超过 8MB 的空间,最小安装到磁盘只需要大约 130MB 存储空间,并且十分的简单,同时兼顾了安全性。此提案将 JDK 移植到了 Apline Linux,由于 Apline Linux 是基于 musl lib 的轻量级 Linux 发行版,因此其他 x64 和 AArch64 架构上使用 musl lib 的 Linux 发行版也适用。
- JEP 388:Windows/AArch64 移植:这些 JEP 的重点不是移植工作本身,而是将它们集成到 JDK 主线存储库中;JEP 386 将 JDK 移植到 Alpine Linux 和其他使用 musl 作为 x64 上主要 C 库的发行版上。此外,JEP 388 将 JDK 移植到 Windows AArch64(ARM64)。
参考文献
- Java Language Changes
- Consolidated JDK 16 Release Notes
- Java 16 正式发布,新特性一一解析
- 实操 | 剖析 Java16 新语法特性(写的很赞)
Java15 新特性
CharSequence
CharSequence
接口添加了一个默认方法 isEmpty()
来判断字符序列为空,如果是则返回 true。
1 | public interface CharSequence { |
TreeMap
TreeMap
新引入了下面这些方法:
putIfAbsent()
computeIfAbsent()
computeIfPresent()
compute()
merge()
ZGC(转正)
Java11 的时候 ,ZGC 还在试验阶段。
当时,ZGC 的出现让众多 Java 开发者看到了垃圾回收器的另外一种可能,因此备受关注。
经过多个版本的迭代,不断的完善和修复问题,ZGC 在 Java 15 已经可以正式使用了!
不过,默认的垃圾回收器依然是 G1。你可以通过下面的参数启动 ZGC:
1 | java -XX:+UseZGC className |
EdDSA(数字签名算法)
新加入了一个安全性和性能都更强的基于 Edwards-Curve Digital Signature Algorithm (EdDSA)实现的数字签名算法。
虽然其性能优于现有的 ECDSA 实现,不过,它并不会完全取代 JDK 中现有的椭圆曲线数字签名算法( ECDSA)。
1 | KeyPairGenerator kpg = KeyPairGenerator.getInstance("Ed25519"); |
输出:
1 | 0Hc0lxxASZNvS52WsvnncJOH/mlFhnA8Tc6D/k5DtAX5BSsNVjtPF4R4+yMWXVjrvB2mxVXmChIbki6goFBgAg== |
文本块(转正)
在 Java 15 ,文本块是正式的功能特性了。
隐藏类(Hidden Classes)
隐藏类是为框架(frameworks)所设计的,隐藏类不能直接被其他类的字节码使用,只能在运行时生成类并通过反射间接使用它们。
预览新特性
密封类
密封类(Sealed Classes) 是 Java 15 中的一个预览新特性。
没有密封类之前,在 Java 中如果想让一个类不能被继承和修改,我们可以使用final
关键字对类进行修饰。不过,这种方式不太灵活,直接把一个类的继承和修改渠道给堵死了。
密封类可以对继承或者实现它们的类进行限制,这样这个类就只能被指定的类继承。
1 | // 抽象类 Person 只允许 Employee 和 Manager 继承。 |
另外,任何扩展密封类的类本身都必须声明为 sealed
、non-sealed
或 final
。
1 | public final class Employee extends Person { |
如果允许扩展的子类和封闭类在同一个源代码文件里,封闭类可以不使用 permits 语句,Java 编译器将检索源文件,在编译期为封闭类添加上许可的子类。
instanceof 模式匹配
Java 15 并没有对此特性进行调整,继续预览特性,主要用于接受更多的使用反馈。
在未来的 Java 版本中,Java 的目标是继续完善 instanceof
模式匹配新特性。
其他
- Nashorn JavaScript 引擎彻底移除:Nashorn 从 Java8 开始引入的 JavaScript 引擎,Java9 对 Nashorn 做了些增强,实现了一些 ES6 的新特性。在 Java 11 中就已经被弃用,到了 Java 15 就彻底被删除了。
- DatagramSocket API 重构
- 禁用和废弃偏向锁(Biased Locking):偏向锁的引入增加了 JVM 的复杂性大于其带来的性能提升。不过,你仍然可以使用
-XX:+UseBiasedLocking
启用偏向锁定,但它会提示这是一个已弃用的 API。 - ……
Java14 新特性
空指针异常精准提示
通过 JVM 参数中添加-XX:+ShowCodeDetailsInExceptionMessages
,可以在空指针异常中获取更为详细的调用信息,更快的定位和解决问题。
1 | a.b.c.i = 99; // 假设这段代码会发生空指针 |
Java 14 之前:
1 | Exception in thread "main" java.lang.NullPointerException |
Java 14 之后:
1 | // 增加参数后提示的异常中很明确的告知了哪里为空导致 |
switch 的增强(转正)
Java12 引入的 switch(预览特性)在 Java14 变为正式版本,不需要增加参数来启用,直接在 JDK14 中就能使用。
Java12 为 switch 表达式引入了类似 lambda 语法条件匹配成功后的执行块,不需要多写 break ,Java13 提供了 yield
来在 block 中返回值。
1 | String result = switch (day) { |
预览新特性
record 关键字
record
关键字可以简化 数据类(一个 Java 类一旦实例化就不能再修改)的定义方式,使用 record
代替 class
定义的类,只需要声明属性,就可以在获得属性的访问方法,以及 toString()
,hashCode()
, equals()
方法。
类似于使用 class
定义类,同时使用了 lombok 插件,并打上了@Getter,@ToString,@EqualsAndHashCode
注解。
1 | /** |
文本块
Java14 中,文本块依然是预览特性,不过,其引入了两个新的转义字符:
\
: 表示行尾,不引入换行符\s
:表示单个空格
1 | String str = "凡心所向,素履所往,生如逆旅,一苇以航。"; |
instanceof 增强
依然是预览特性 ,Java 12 新特性中介绍过。
其他
- 从 Java11 引入的 ZGC 作为继 G1 过后的下一代 GC 算法,从支持 Linux 平台到 Java14 开始支持 MacOS 和 Windows(个人感觉是终于可以在日常开发工具中先体验下 ZGC 的效果了,虽然其实 G1 也够用)
- 移除了 CMS(Concurrent Mark Sweep) 垃圾收集器(功成而退)
- 新增了 jpackage 工具,标配将应用打成 jar 包外,还支持不同平台的特性包,比如 linux 下的
deb
和rpm
,window 平台下的msi
和exe
Java13 新特性
增强 ZGC(释放未使用内存)
在 Java 11 中实验性引入的 ZGC 在实际的使用中存在未能主动将未使用的内存释放给操作系统的问题。
ZGC 堆由一组称为 ZPages 的堆区域组成。在 GC 周期中清空 ZPages 区域时,它们将被释放并返回到页面缓存 ZPageCache 中,此缓存中的 ZPages 按最近最少使用(LRU)的顺序,并按照大小进行组织。
在 Java 13 中,ZGC 将向操作系统返回被标识为长时间未使用的页面,这样它们将可以被其他进程重用。
SocketAPI 重构
Java Socket API 终于迎来了重大更新!
Java 13 将 Socket API 的底层进行了重写, NioSocketImpl
是对 PlainSocketImpl
的直接替代,它使用 java.util.concurrent
包下的锁而不是同步方法。如果要使用旧实现,请使用 -Djdk.net.usePlainSocketImpl=true
。
并且,在 Java 13 中是默认使用新的 Socket 实现。
1 | public final class NioSocketImpl extends SocketImpl implements PlatformSocketImpl { |
FileSystems
FileSystems
类中添加了以下三种新方法,以便更容易地使用将文件内容视为文件系统的文件系统提供程序:
newFileSystem(Path)
newFileSystem(Path, Map<String, ?>)
newFileSystem(Path, Map<String, ?>, ClassLoader)
动态 CDS 存档
Java 13 中对 Java 10 中引入的应用程序类数据共享(AppCDS)进行了进一步的简化、改进和扩展,即:允许在 Java 应用程序执行结束时动态进行类归档,具体能够被归档的类包括所有已被加载,但不属于默认基层 CDS 的应用程序类和引用类库中的类。
这提高了应用程序类数据共享(AppCDS)的可用性。无需用户进行试运行来为每个应用程序创建类列表。
1 | java -XX:ArchiveClassesAtExit=my_app_cds.jsa -cp my_app.jar |
预览新特性
文本块
解决 Java 定义多行字符串时只能通过换行转义或者换行连接符来变通支持的问题,引入三重双引号来定义多行文本。
Java 13 支持两个 """
符号中间的任何内容都会被解释为字符串的一部分,包括换行符。
未支持文本块之前的 HTML 写法:
1 | String json ="{\n" + |
支持文本块之后的 HTML 写法:
1 | String json = """ |
未支持文本块之前的 SQL 写法:
1 | String query = "SELECT `EMP_ID`, `LAST_NAME` FROM `EMPLOYEE_TB`\n" + |
支持文本块之后的 SQL 写法:
1 | String query = """ |
另外,String
类新增加了 3 个新的方法来操作文本块:
formatted(Object... args)
:它类似于String
的format()
方法。添加它是为了支持文本块的格式设置。stripIndent()
:用于去除文本块中每一行开头和结尾的空格。translateEscapes()
:转义序列如 “\\t” 转换为 “\t”
由于文本块是一项预览功能,可以在未来版本中删除,因此这些新方法被标记为弃用。
1 |
|
增强 Switch(引入 yield 关键字到 Switch 中)
Switch
表达式中就多了一个关键字用于跳出 Switch
块的关键字 yield
,主要用于返回一个值
yield
和 return
的区别在于:return
会直接跳出当前循环或者方法,而 yield
只会跳出当前 Switch
块,同时在使用 yield
时,需要有 default
条件
1 | private static String descLanguage(String name) { |
补充
关于预览特性
先贴一段 oracle 官网原文:This is a preview feature, which is a feature whose design, specification, and implementation are complete, but is not permanent, which means that the feature may exist in a different form or not at all in future JDK releases. To compile and run code that contains preview features, you must specify additional command-line options.
这是一个预览功能,该功能的设计,规格和实现是完整的,但不是永久性的,这意味着该功能可能以其他形式存在或在将来的 JDK 版本中根本不存在。 要编译和运行包含预览功能的代码,必须指定其他命令行选项。
就以switch
的增强为例子,从 Java12 中推出,到 Java13 中将继续增强,直到 Java14 才正式转正进入 JDK 可以放心使用,不用考虑后续 JDK 版本对其的改动或修改
一方面可以看出 JDK 作为标准平台在增加新特性的严谨态度,另一方面个人认为是对于预览特性应该采取审慎使用的态度。特性的设计和实现容易,但是其实际价值依然需要在使用中去验证
JVM 虚拟机优化
每次 Java 版本的发布都伴随着对 JVM 虚拟机的优化,包括对现有垃圾回收算法的改进,引入新的垃圾回收算法,移除老旧的不再适用于今天的垃圾回收算法等
整体优化的方向是高效,低时延的垃圾回收表现
对于日常的应用开发者可能比较关注新的语法特性,但是从一个公司角度来说,在考虑是否升级 Java 平台时更加考虑的是JVM 运行时的提升
参考
- JDK Project Overview:https://openjdk.java.net/projects/jdk/
- Oracle Java12 ReleaseNote:https://www.oracle.com/java/technologies/javase/12all-relnotes.htm
- What is new in Java 12:https://mkyong.com/java/what-is-new-in-java-12/
- Oracle Java13 ReleaseNote https://www.oracle.com/technetwork/java/javase/13all-relnotes-5461743.html#NewFeature
- New Java13 Features https://www.baeldung.com/java-13-new-features
- Java13 新特性概述 https://www.ibm.com/developerworks/cn/java/the-new-features-of-Java-13/index.html
Java12 新特性
String 增强
Java 12 增加了两个的字符串处理方法,如以下所示。
indent()
方法可以实现字符串缩进。
1 | String text = "Java"; |
输出:
1 | Java |
transform()
方法可以用来转变指定字符串。
1 | String result = "foo".transform(input -> input + " bar"); |
Files 增强(文件比较)
Java 12 添加了以下方法来比较两个文件:
1 | public static long mismatch(Path path, Path path2) throws IOException |
mismatch()
方法用于比较两个文件,并返回第一个不匹配字符的位置,如果文件相同则返回 -1L。
代码示例(两个文件内容相同的情况):
1 | Path filePath1 = Files.createTempFile("file1", ".txt"); |
代码示例(两个文件内容不相同的情况):
1 | Path filePath3 = Files.createTempFile("file3", ".txt"); |
数字格式化工具类
NumberFormat
新增了对复杂的数字进行格式化的支持
1 | NumberFormat fmt = NumberFormat.getCompactNumberInstance(Locale.US, NumberFormat.Style.SHORT); |
输出:
1 | 1K |
Shenandoah GC
Redhat 主导开发的 Pauseless GC 实现,主要目标是 99.9% 的暂停小于 10ms,暂停与堆大小无关等
和 Java11 开源的 ZGC 相比(需要升级到 JDK11 才能使用),Shenandoah GC 有稳定的 JDK8u 版本,在 Java8 占据主要市场份额的今天有更大的可落地性。
G1 收集器优化
Java12 为默认的垃圾收集器 G1 带来了两项更新:
- 可中止的混合收集集合:JEP344 的实现,为了达到用户提供的停顿时间目标,JEP 344 通过把要被回收的区域集(混合收集集合)拆分为强制和可选部分,使 G1 垃圾回收器能中止垃圾回收过程。 G1 可以中止可选部分的回收以达到停顿时间目标
- 及时返回未使用的已分配内存:JEP346 的实现,增强 G1 GC,以便在空闲时自动将 Java 堆内存返回给操作系统
预览新特性
作为预览特性加入,需要在javac
编译和java
运行时增加参数--enable-preview
。
增强 Switch
传统的 switch
语法存在容易漏写 break
的问题,而且从代码整洁性层面来看,多个 break 本质也是一种重复。
Java12 增强了 switch
表达式,使用类似 lambda 语法条件匹配成功后的执行块,不需要多写 break 。
1 | switch (day) { |
instanceof 模式匹配
instanceof
主要在类型强转前探测对象的具体类型。
之前的版本中,我们需要显示地对对象进行类型转换。
1 | Object obj = "我是字符串"; |
新版的 instanceof
可以在判断是否属于具体的类型同时完成转换。
1 | Object obj = "我是字符串"; |
Java11 新特性
Java 11 于 2018 年 9 月 25 日正式发布,这是很重要的一个版本!Java 11 和 2017 年 9 月份发布的 Java 9 以及 2018 年 3 月份发布的 Java 10 相比,其最大的区别就是:在长期支持(Long-Term-Support)方面,Oracle 表示会对 Java 11 提供大力支持,这一支持将会持续至 2026 年 9 月。这是据 Java 8 以后支持的首个长期版本。
概览(精选了一部分):
HTTP Client 标准化
Java 11 对 Java 9 中引入并在 Java 10 中进行了更新的 Http Client API 进行了标准化,在前两个版本中进行孵化的同时,Http Client 几乎被完全重写,并且现在完全支持异步非阻塞。
并且,Java 11 中,Http Client 的包名由 jdk.incubator.http
改为java.net.http
,该 API 通过 CompleteableFuture
提供非阻塞请求和响应语义。使用起来也很简单,如下:
1 | var request = HttpRequest.newBuilder() |
String 增强
Java 11 增加了一系列的字符串处理方法:
1 | //判断字符串是否为空 |
Optional 增强
新增了isEmpty()
方法来判断指定的 Optional
对象是否为空。
1 | var op = Optional.empty(); |
ZGC(可伸缩低延迟垃圾收集器)
ZGC 即 Z Garbage Collector,是一个可伸缩的、低延迟的垃圾收集器。
ZGC 主要为了满足如下目标进行设计:
- GC 停顿时间不超过 10ms
- 即能处理几百 MB 的小堆,也能处理几个 TB 的大堆
- 应用吞吐能力不会下降超过 15%(与 G1 回收算法相比)
- 方便在此基础上引入新的 GC 特性和利用 colored 针以及 Load barriers 优化奠定基础
- 当前只支持 Linux/x64 位平台
ZGC 目前 处在实验阶段,只支持 Linux/x64 平台。
与 CMS 中的 ParNew 和 G1 类似,ZGC 也采用标记-复制算法,不过 ZGC 对该算法做了重大改进。
在 ZGC 中出现 Stop The World 的情况会更少!
详情可以看:《新一代垃圾回收器 ZGC 的探索与实践》
Lambda 参数的局部变量语法
从 Java 10 开始,便引入了局部变量类型推断这一关键特性。类型推断允许使用关键字 var 作为局部变量的类型而不是实际类型,编译器根据分配给变量的值推断出类型。
Java 10 中对 var 关键字存在几个限制
- 只能用于局部变量上
- 声明时必须初始化
- 不能用作方法参数
- 不能在 Lambda 表达式中使用
Java11 开始允许开发者在 Lambda 表达式中使用 var 进行参数声明。
1 | // 下面两者是等价的 |
启动单文件源代码程序
这意味着我们可以运行单一文件的 Java 源代码。此功能允许使用 Java 解释器直接执行 Java 源代码。源代码在内存中编译,然后由解释器执行,不需要在磁盘上生成 .class
文件了。唯一的约束在于所有相关的类必须定义在同一个 Java 文件中。
对于 Java 初学者并希望尝试简单程序的人特别有用,并且能和 jshell 一起使用。一定能程度上增强了使用 Java 来写脚本程序的能力。
其他新特性
- 新的垃圾回收器 Epsilon:一个完全消极的 GC 实现,分配有限的内存资源,最大限度的降低内存占用和内存吞吐延迟时间
- 低开销的 Heap Profiling:Java 11 中提供一种低开销的 Java 堆分配采样方法,能够得到堆分配的 Java 对象信息,并且能够通过 JVMTI 访问堆信息
- TLS1.3 协议:Java 11 中包含了传输层安全性(TLS)1.3 规范(RFC 8446)的实现,替换了之前版本中包含的 TLS,包括 TLS 1.2,同时还改进了其他 TLS 功能,例如 OCSP 装订扩展(RFC 6066,RFC 6961),以及会话散列和扩展主密钥扩展(RFC 7627),在安全性和性能方面也做了很多提升
- **飞行记录器(Java Flight Recorder)**:飞行记录器之前是商业版 JDK 的一项分析工具,但在 Java 11 中,其代码被包含到公开代码库中,这样所有人都能使用该功能了。
- ……
Java10 新特性
Java 10 发布于 2018 年 3 月 20 日,最知名的特性应该是 var
关键字(局部变量类型推断)的引入了,其他还有垃圾收集器改善、GC 改进、性能提升、线程管控等一批新特性。
概览(精选了一部分):
- JEP 286:局部变量类型推断
- JEP 304:垃圾回收器接口
- JEP 307:G1 并行 Full GC
- JEP 310:应用程序类数据共享(扩展 CDS 功能)
- JEP 317:实验性的基于 Java 的 JIT 编译器
局部变量类型推断(var)
由于太多 Java 开发者希望 Java 中引入局部变量推断,于是 Java 10 的时候它来了,也算是众望所归了!
Java 10 提供了 var
关键字声明局部变量。
1 | var id = 0; |
var 关键字只能用于带有构造器的局部变量和 for 循环中。
1 | var count=null; //❌编译不通过,不能声明为 null |
var 并不会改变 Java 是一门静态类型语言的事实,编译器负责推断出类型。
另外,Scala 和 Kotlin 中已经有了 val
关键字 ( final var
组合关键字)。
相关阅读:《Java 10 新特性之局部变量类型推断》。
垃圾回收器接口
在早期的 JDK 结构中,组成垃圾收集器 (GC) 实现的组件分散在代码库的各个部分。 Java 10 通过引入一套纯净的垃圾收集器接口来将不同垃圾收集器的源代码分隔开。
G1 并行 Full GC
从 Java9 开始 G1 就了默认的垃圾回收器,G1 是以一种低延时的垃圾回收器来设计的,旨在避免进行 Full GC,但是 Java9 的 G1 的 FullGC 依然是使用单线程去完成标记清除算法,这可能会导致垃圾回收期在无法回收内存的时候触发 Full GC。
为了最大限度地减少 Full GC 造成的应用停顿的影响,从 Java10 开始,G1 的 FullGC 改为并行的标记清除算法,同时会使用与年轻代回收和混合回收相同的并行工作线程数量,从而减少了 Full GC 的发生,以带来更好的性能提升、更大的吞吐量。
集合增强
List
,Set
,Map
提供了静态方法copyOf()
返回入参集合的一个不可变拷贝。
1 | static <E> List<E> copyOf(Collection<? extends E> coll) { |
使用 copyOf()
创建的集合为不可变集合,不能进行添加、删除、替换、 排序等操作,不然会报 java.lang.UnsupportedOperationException
异常。 IDEA 也会有相应的提示。
并且,java.util.stream.Collectors
中新增了静态方法,用于将流中的元素收集为不可变的集合。
1 | var list = new ArrayList<>(); |
Optional 增强
Optional
新增了orElseThrow()
方法来在没有值时抛出指定的异常。
1 | Optional.ofNullable(cache.getIfPresent(key)) |
应用程序类数据共享(扩展 CDS 功能)
在 Java 5 中就已经引入了类数据共享机制 (Class Data Sharing,简称 CDS),允许将一组类预处理为共享归档文件,以便在运行时能够进行内存映射以减少 Java 程序的启动时间,当多个 Java 虚拟机(JVM)共享相同的归档文件时,还可以减少动态内存的占用量,同时减少多个虚拟机在同一个物理或虚拟的机器上运行时的资源占用。CDS 在当时还是 Oracle JDK 的商业特性。
Java 10 在现有的 CDS 功能基础上再次拓展,以允许应用类放置在共享存档中。CDS 特性在原来的 bootstrap 类基础之上,扩展加入了应用类的 CDS 为 (Application Class-Data Sharing,AppCDS) 支持,大大加大了 CDS 的适用范围。其原理为:在启动时记录加载类的过程,写入到文本文件中,再次启动时直接读取此启动文本并加载。设想如果应用环境没有大的变化,启动速度就会得到提升。
实验性的基于 Java 的 JIT 编译器
Graal 是一个基于 Java 语言编写的 JIT 编译器,是 JDK 9 中引入的实验性 Ahead-of-Time (AOT) 编译器的基础。
Oracle 的 HotSpot VM 便附带两个用 C++ 实现的 JIT compiler:C1 及 C2。在 Java 10 (Linux/x64, macOS/x64) 中,默认情况下 HotSpot 仍使用 C2,但通过向 java 命令添加 -XX:+UnlockExperimentalVMOptions -XX:+UseJVMCICompiler
参数便可将 C2 替换成 Graal。
相关阅读:深入浅出 Java 10 的实验性 JIT 编译器 Graal - 郑雨迪
其他
- 线程-局部管控:Java 10 中线程管控引入 JVM 安全点的概念,将允许在不运行全局 JVM 安全点的情况下实现线程回调,由线程本身或者 JVM 线程来执行,同时保持线程处于阻塞状态,这种方式使得停止单个线程变成可能,而不是只能启用或停止所有线程
- 备用存储装置上的堆分配:Java 10 中将使得 JVM 能够使用适用于不同类型的存储机制的堆,在可选内存设备上进行堆内存分配
- ……
Java9 新特性
Java 9 发布于 2017 年 9 月 21 日 。作为 Java 8 之后 3 年半才发布的新版本,Java 9 带来了很多重大的变化其中最重要的改动是 Java 平台模块系统的引入,其他还有诸如集合、Stream
流……。
你可以在 Archived OpenJDK General-Availability Releases 上下载自己需要的 JDK 版本!官方的新特性说明文档地址:https://openjdk.java.net/projects/jdk/ 。
概览(精选了一部分):
JShell
JShell 是 Java 9 新增的一个实用工具。为 Java 提供了类似于 Python 的实时命令行交互工具。
在 JShell 中可以直接输入表达式并查看其执行结果。
JShell 为我们带来了哪些好处呢?
- 降低了输出第一行 Java 版”Hello World!”的门槛,能够提高新手的学习热情。
- 在处理简单的小逻辑,验证简单的小问题时,比 IDE 更有效率(并不是为了取代 IDE,对于复杂逻辑的验证,IDE 更合适,两者互补)。
- ……
JShell 的代码和普通的可编译代码,有什么不一样?
- 一旦语句输入完成,JShell 立即就能返回执行的结果,而不再需要编辑器、编译器、解释器。
- JShell 支持变量的重复声明,后面声明的会覆盖前面声明的。
- JShell 支持独立的表达式比如普通的加法运算
1 + 1
。 - ……
模块化系统
模块系统是Jigsaw Project的一部分,把模块化开发实践引入到了 Java 平台中,可以让我们的代码可重用性更好!
什么是模块系统? 官方的定义是:
A uniquely named, reusable group of related packages, as well as resources (such as images and XML files) and a module descriptor。
简单来说,你可以将一个模块看作是一组唯一命名、可重用的包、资源和模块描述文件(module-info.java
)。
任意一个 jar 文件,只要加上一个模块描述文件(module-info.java
),就可以升级为一个模块。
在引入了模块系统之后,JDK 被重新组织成 94 个模块。Java 应用可以通过新增的 jlink 工具 (Jlink 是随 Java 9 一起发布的新命令行工具。它允许开发人员为基于模块的 Java 应用程序创建自己的轻量级、定制的 JRE),创建出只包含所依赖的 JDK 模块的自定义运行时镜像。这样可以极大的减少 Java 运行时环境的大小。
我们可以通过 exports
关键词精准控制哪些类可以对外开放使用,哪些类只能内部使用。
1 | module my.module { |
想要深入了解 Java 9 的模块化,可以参考下面这几篇文章:
G1 成为默认垃圾回收器
在 Java 8 的时候,默认垃圾回收器是 Parallel Scavenge(新生代)+Parallel Old(老年代)。到了 Java 9, CMS 垃圾回收器被废弃了,G1(Garbage-First Garbage Collector) 成为了默认垃圾回收器。
G1 还是在 Java 7 中被引入的,经过两个版本优异的表现成为成为默认垃圾回收器。
快速创建不可变集合
增加了List.of()
、Set.of()
、Map.of()
和 Map.ofEntries()
等工厂方法来创建不可变集合(有点参考 Guava 的味道):
1 | List.of("Java", "C++"); |
使用 of()
创建的集合为不可变集合,不能进行添加、删除、替换、 排序等操作,不然会报 java.lang.UnsupportedOperationException
异常。
String 存储结构优化
Java 8 及之前的版本,String
一直是用 char[]
存储。在 Java 9 之后,String
的实现改用 byte[]
数组存储字符串,节省了空间。
1 | public final class String implements java.io.Serializable,Comparable<String>, CharSequence { |
接口私有方法
Java 9 允许在接口中使用私有方法。这样的话,接口的使用就更加灵活了,有点像是一个简化版的抽象类。
1 | public interface MyInterface { |
try-with-resources 增强
在 Java 9 之前,我们只能在 try-with-resources
块中声明变量:
1 | try (Scanner scanner = new Scanner(new File("testRead.txt")); |
在 Java 9 之后,在 try-with-resources
语句中可以使用 effectively-final 变量。
1 | final Scanner scanner = new Scanner(new File("testRead.txt")); |
什么是 effectively-final 变量? 简单来说就是没有被 final
修饰但是值在初始化后从未更改的变量。
正如上面的代码所演示的那样,即使 writer
变量没有被显示声明为 final
,但它在第一次被赋值后就不会改变了,因此,它就是 effectively-final 变量。
Stream & Optional 增强
Stream
中增加了新的方法 ofNullable()
、dropWhile()
、takeWhile()
以及 iterate()
方法的重载方法。
Java 9 中的 ofNullable()
方 法允许我们创建一个单元素的 Stream
,可以包含一个非空元素,也可以创建一个空 Stream
。 而在 Java 8 中则不可以创建空的 Stream
。
1 | Stream<String> stringStream = Stream.ofNullable("Java"); |
takeWhile()
方法可以从 Stream
中依次获取满足条件的元素,直到不满足条件为止结束获取。
1 | List<Integer> integerList = List.of(11, 33, 66, 8, 9, 13); |
dropWhile()
方法的效果和 takeWhile()
相反。
1 | List<Integer> integerList2 = List.of(11, 33, 66, 8, 9, 13); |
iterate()
方法的新重载方法提供了一个 Predicate
参数 (判断条件)来决定什么时候结束迭代
1 | public static<T> Stream<T> iterate(final T seed, final UnaryOperator<T> f) { |
两者的使用对比如下,新的 iterate()
重载方法更加灵活一些。
1 | // 使用原始 iterate() 方法输出数字 1~10 |
Optional
类中新增了 ifPresentOrElse()
、or()
和 stream()
等方法
ifPresentOrElse()
方法接受两个参数 Consumer
和 Runnable
,如果 Optional
不为空调用 Consumer
参数,为空则调用 Runnable
参数。
1 | public void ifPresentOrElse(Consumer<? super T> action, Runnable emptyAction) |
or()
方法接受一个 Supplier
参数 ,如果 Optional
为空则返回 Supplier
参数指定的 Optional
值。
1 | public Optional<T> or(Supplier<? extends Optional<? extends T>> supplier) |
进程 API
Java 9 增加了 java.lang.ProcessHandle
接口来实现对原生进程进行管理,尤其适合于管理长时间运行的进程。
1 | // 获取当前正在运行的 JVM 的进程 |
ProcessHandle
接口概览:
响应式流 ( Reactive Streams )
在 Java 9 中的 java.util.concurrent.Flow
类中新增了反应式流规范的核心接口 。
Flow
中包含了 Flow.Publisher
、Flow.Subscriber
、Flow.Subscription
和 Flow.Processor
等 4 个核心接口。Java 9 还提供了SubmissionPublisher
作为Flow.Publisher
的一个实现。
关于 Java 9 响应式流更详细的解读,推荐你看 Java 9 揭秘(17. Reactive Streams )- 林本托 这篇文章。
变量句柄
变量句柄是一个变量或一组变量的引用,包括静态域,非静态域,数组元素和堆外数据结构中的组成部分等。
变量句柄的含义类似于已有的方法句柄 MethodHandle
,由 Java 类 java.lang.invoke.VarHandle
来表示,可以使用类 java.lang.invoke.MethodHandles.Lookup
中的静态工厂方法来创建 VarHandle
对象。
VarHandle
的出现替代了 java.util.concurrent.atomic
和 sun.misc.Unsafe
的部分操作。并且提供了一系列标准的内存屏障操作,用于更加细粒度的控制内存排序。在安全性、可用性、性能上都要优于现有的 API。
其它
- 平台日志 API 改进:Java 9 允许为 JDK 和应用配置同样的日志实现。新增了
System.LoggerFinder
用来管理 JDK 使 用的日志记录器实现。JVM 在运行时只有一个系统范围的LoggerFinder
实例。我们可以通过添加自己的System.LoggerFinder
实现来让 JDK 和应用使用 SLF4J 等其他日志记录框架。 CompletableFuture
类增强:新增了几个新的方法(completeAsync
,orTimeout
等)。- Nashorn 引擎的增强:Nashorn 是从 Java8 开始引入的 JavaScript 引擎,Java9 对 Nashorn 做了些增强,实现了一些 ES6 的新特性(Java 11 中已经被弃用)。
- I/O 流的新特性:增加了新的方法来读取和复制
InputStream
中包含的数据。 - 改进应用的安全性能:Java 9 新增了 4 个 SHA- 3 哈希算法,SHA3-224、SHA3-256、SHA3-384 和 SHA3-512。
- 改进方法句柄(Method Handle):方法句柄从 Java7 开始引入,Java9 在类
java.lang.invoke.MethodHandles
中新增了更多的静态方法来创建不同类型的方法句柄。 - ……
Java8 新特性
Oracle 于 2014 发布了 Java8(jdk1.8),诸多原因使它成为目前市场上使用最多的 jdk 版本。虽然发布距今已将近 7 年,但很多程序员对其新特性还是不够了解,尤其是用惯了 Java8 之前版本的老程序员,比如我。
为了不脱离队伍太远,还是有必要对这些新特性做一些总结梳理。它较 jdk.7 有很多变化或者说是优化,比如 interface 里可以有静态方法,并且可以有方法体,这一点就颠覆了之前的认知;java.util.HashMap
数据结构里增加了红黑树;还有众所周知的 Lambda 表达式等等。本文不能把所有的新特性都给大家一一分享,只列出比较常用的新特性给大家做详细讲解。更多相关内容请看官网关于 Java8 的新特性的介绍。
Interface
interface 的设计初衷是面向抽象,提高扩展性。这也留有一点遗憾,Interface 修改的时候,实现它的类也必须跟着改。
为了解决接口的修改与现有的实现不兼容的问题。新 interface 的方法可以用default
或 static
修饰,这样就可以有方法体,实现类也不必重写此方法。
一个 interface 中可以有多个方法被它们修饰,这 2 个修饰符的区别主要也是普通方法和静态方法的区别。
default
修饰的方法,是普通实例方法,可以用this
调用,可以被子类继承、重写。static
修饰的方法,使用上和一般类静态方法一样。但它不能被子类继承,只能用Interface
调用。
我们来看一个实际的例子。
1 | public interface InterfaceNew { |
如果有一个类既实现了 InterfaceNew
接口又实现了 InterfaceNew1
接口,它们都有def()
,并且 InterfaceNew
接口和 InterfaceNew1
接口没有继承关系的话,这时就必须重写def()
。不然的话,编译的时候就会报错。
1 | public class InterfaceNewImpl implements InterfaceNew , InterfaceNew1{ |
在 Java 8 ,接口和抽象类有什么区别的?
很多小伙伴认为:“既然 interface 也可以有自己的方法实现,似乎和 abstract class 没多大区别了。”
其实它们还是有区别的
interface 和 class 的区别,好像是废话,主要有:
- 接口多实现,类单继承
- 接口的方法是 public abstract 修饰,变量是 public static final 修饰。 abstract class 可以用其他修饰符
interface 的方法是更像是一个扩展插件。而 abstract class 的方法是要继承的。
开始我们也提到,interface 新增default
和static
修饰的方法,为了解决接口的修改与现有的实现不兼容的问题,并不是为了要替代abstract class
。在使用上,该用 abstract class 的地方还是要用 abstract class,不要因为 interface 的新特性而将之替换。
记住接口永远和类不一样。
functional interface 函数式接口
定义:也称 SAM 接口,即 Single Abstract Method interfaces,有且只有一个抽象方法,但可以有多个非抽象方法的接口。
在 java 8 中专门有一个包放函数式接口java.util.function
,该包下的所有接口都有 @FunctionalInterface
注解,提供函数式编程。
在其他包中也有函数式接口,其中一些没有@FunctionalInterface
注解,但是只要符合函数式接口的定义就是函数式接口,与是否有
@FunctionalInterface
注解无关,注解只是在编译时起到强制规范定义的作用。其在 Lambda 表达式中有广泛的应用。
Lambda 表达式
接下来谈众所周知的 Lambda 表达式。它是推动 Java 8 发布的最重要新特性。是继泛型(Generics
)和注解(Annotation
)以来最大的变化。
使用 Lambda 表达式可以使代码变的更加简洁紧凑。让 java 也能支持简单的函数式编程。
Lambda 表达式是一个匿名函数,java 8 允许把函数作为参数传递进方法中。
语法格式
1 | (parameters) -> expression 或 |
Lambda 实战
我们用常用的实例来感受 Lambda 带来的便利
替代匿名内部类
过去给方法传动态参数的唯一方法是使用内部类。比如
1.Runnable
接口
1 | new Thread(new Runnable() { |
2.Comparator
接口
1 | List<Integer> strings = Arrays.asList(1, 2, 3); |
3.Listener
接口
1 | JButton button = new JButton(); |
4.自定义接口
上面的 3 个例子是我们在开发过程中最常见的,从中也能体会到 Lambda 带来的便捷与清爽。它只保留实际用到的代码,把无用代码全部省略。那它对接口有没有要求呢?我们发现这些匿名内部类只重写了接口的一个方法,当然也只有一个方法须要重写。这就是我们上文提到的函数式接口,也就是说只要方法的参数是函数式接口都可以用 Lambda 表达式。
1 |
|
我们自定义一个函数式接口
1 |
|
集合迭代
1 | void lamndaFor() { |
方法的引用
Java 8 允许使用 ::
关键字来传递方法或者构造函数引用,无论如何,表达式返回的类型必须是 functional-interface。
1 | public class LambdaClassSuper { |
访问变量
1 | int i = 0; |
lambda 表达式可以引用外边变量,但是该变量默认拥有 final 属性,不能被修改,如果修改,编译时就报错。
Stream
java 新增了 java.util.stream
包,它和之前的流大同小异。之前接触最多的是资源流,比如java.io.FileInputStream
,通过流把文件从一个地方输入到另一个地方,它只是内容搬运工,对文件内容不做任何CRUD。
Stream
依然不存储数据,不同的是它可以检索(Retrieve)和逻辑处理集合数据、包括筛选、排序、统计、计数等。可以想象成是 Sql 语句。
它的源数据可以是 Collection
、Array
等。由于它的方法参数都是函数式接口类型,所以一般和 Lambda 配合使用。
流类型
- stream 串行流
- parallelStream 并行流,可多线程执行
常用方法
接下来我们看java.util.stream.Stream
常用方法
1 | /** |
实战
本文列出 Stream
具有代表性的方法之使用,更多的使用方法还是要看 Api。
1 |
|
延迟执行
在执行返回 Stream
的方法时,并不立刻执行,而是等返回一个非 Stream
的方法后才执行。因为拿到 Stream
并不能直接用,而是需要处理成一个常规类型。这里的 Stream
可以想象成是二进制流(2 个完全不一样的东东),拿到也看不懂。
我们下面分解一下 filter
方法。
1 |
|
按执行顺序应该是先打印 4 次「Predicate.test
执行」,再打印「count
执行」。实际结果恰恰相反。说明 filter 中的方法并没有立刻执行,而是等调用count()
方法后才执行。
上面都是串行 Stream
的实例。并行 parallelStream
在使用方法上和串行一样。主要区别是 parallelStream
可多线程执行,是基于 ForkJoin 框架实现的,有时间大家可以了解一下 ForkJoin
框架和 ForkJoinPool
。这里可以简单的理解它是通过线程池来实现的,这样就会涉及到线程安全,线程消耗等问题。下面我们通过代码来体验一下并行流的多线程执行。
1 |
|
从结果中我们看到,for-each 用到的是多线程。
小结
从源码和实例中我们可以总结出一些 stream 的特点
- 通过简单的链式编程,使得它可以方便地对遍历处理后的数据进行再处理。
- 方法参数都是函数式接口类型
- 一个 Stream 只能操作一次,操作完就关闭了,继续使用这个 stream 会报错。
- Stream 不保存数据,不改变数据源
Optional
在阿里巴巴开发手册关于 Optional 的介绍中这样写到:
防止 NPE,是程序员的基本修养,注意 NPE 产生的场景:
1) 返回类型为基本数据类型,return 包装数据类型的对象时,自动拆箱有可能产生 NPE。
反例:public int f() { return Integer 对象}, 如果为 null,自动解箱抛 NPE。
2) 数据库的查询结果可能为 null。
3) 集合里的元素即使 isNotEmpty,取出的数据元素也可能为 null。
4) 远程调用返回对象时,一律要求进行空指针判断,防止 NPE。
5) 对于 Session 中获取的数据,建议进行 NPE 检查,避免空指针。
6) 级联调用 obj.getA().getB().getC();一连串调用,易产生 NPE。
正例:使用 JDK8 的 Optional 类来防止 NPE 问题。
他建议使用 Optional
解决 NPE(java.lang.NullPointerException
)问题,它就是为 NPE 而生的,其中可以包含空值或非空值。下面我们通过源码逐步揭开 Optional
的红盖头。
假设有一个 Zoo
类,里面有个属性 Dog
,需求要获取 Dog
的 age
。
1 | class Zoo { |
传统解决 NPE 的办法如下:
1 | Zoo zoo = getZoo(); |
层层判断对象非空,有人说这种方式很丑陋不优雅,我并不这么认为。反而觉得很整洁,易读,易懂。你们觉得呢?
Optional
是这样的实现的:
1 | Optional.ofNullable(zoo).map(o -> o.getDog()).map(d -> d.getAge()).ifPresent(age -> |
是不是简洁了很多呢?
如何创建一个 Optional
上例中Optional.ofNullable
是其中一种创建 Optional 的方式。我们先看一下它的含义和其他创建 Optional 的源码方法。
1 | /** |
ofNullable
方法和of
方法唯一区别就是当 value 为 null 时,ofNullable
返回的是EMPTY
,of 会抛出 NullPointerException
异常。如果需要把 NullPointerException
暴漏出来就用 of
,否则就用 ofNullable
。
map()
和 flatMap()
有什么区别的?
map
和 flatMap
都是将一个函数应用于集合中的每个元素,但不同的是map
返回一个新的集合,flatMap
是将每个元素都映射为一个集合,最后再将这个集合展平。
在实际应用场景中,如果map
返回的是数组,那么最后得到的是一个二维数组,使用flatMap
就是为了将这个二维数组展平变成一个一维数组。
1 | public class MapAndFlatMapExample { |
运行结果:
1 | Using map: |
最简单的理解就是flatMap()
可以将map()
的结果展开。
在Optional
里面,当使用map()
时,如果映射函数返回的是一个普通值,它会将这个值包装在一个新的Optional
中。而使用flatMap
时,如果映射函数返回的是一个Optional
,它会将这个返回的Optional
展平,不再包装成嵌套的Optional
。
下面是一个对比的示例代码:
1 | public static void main(String[] args) { |
在Stream
和Optional
中正确使用flatMap
可以减少很多不必要的代码。
判断 value 是否为 null
1 | /** |
获取 value
1 | /** |
过滤值
1 | /** |
小结
看完 Optional
源码,Optional
的方法真的非常简单,值得注意的是如果坚决不想看见 NPE
,就不要用 of()
、 get()
、flatMap(..)
。最后再综合用一下 Optional
的高频方法。
1 | Optional.ofNullable(zoo).map(o -> o.getDog()).map(d -> d.getAge()).filter(v->v==1).orElse(3); |
Date-Time API
这是对java.util.Date
强有力的补充,解决了 Date 类的大部分痛点:
- 非线程安全
- 时区处理麻烦
- 各种格式化、和时间计算繁琐
- 设计有缺陷,Date 类同时包含日期和时间;还有一个 java.sql.Date,容易混淆。
我们从常用的时间实例来对比 java.util.Date 和新 Date 有什么区别。用java.util.Date
的代码该改改了。
java.time 主要类
java.util.Date
既包含日期又包含时间,而 java.time
把它们进行了分离
1 | LocalDateTime.class //日期+时间 format: yyyy-MM-ddTHH:mm:ss.SSS |
格式化
Java 8 之前:
1 | public void oldFormat(){ |
Java 8 之后:
1 | public void newFormat(){ |
字符串转日期格式
Java 8 之前:
1 | //已弃用 |
Java 8 之后:
1 | LocalDate date = LocalDate.of(2021, 1, 26); |
Java 8 之前 转换都需要借助 SimpleDateFormat
类,而Java 8 之后只需要 LocalDate
、LocalTime
、LocalDateTime
的 of
或 parse
方法。
日期计算
下面仅以一周后日期为例,其他单位(年、月、日、1/2 日、时等等)大同小异。另外,这些单位都在 java.time.temporal.ChronoUnit 枚举中定义。
Java 8 之前:
1 | public void afterDay(){ |
Java 8 之后:
1 | public void pushWeek(){ |
获取指定日期
除了日期计算繁琐,获取特定一个日期也很麻烦,比如获取本月最后一天,第一天。
Java 8 之前:
1 | public void getDay() { |
Java 8 之后:
1 | public void getDayNew() { |
java.time.temporal.TemporalAdjusters
里面还有很多便捷的算法,这里就不带大家看 Api 了,都很简单,看了秒懂。
JDBC 和 java8
现在 jdbc 时间类型和 java8 时间类型对应关系是
Date
—>LocalDate
Time
—>LocalTime
Timestamp
—>LocalDateTime
而之前统统对应 Date
,也只有 Date
。
时区
时区:正式的时区划分为每隔经度 15° 划分一个时区,全球共 24 个时区,每个时区相差 1 小时。但为了行政上的方便,常将 1 个国家或 1 个省份划在一起,比如我国幅员宽广,大概横跨 5 个时区,实际上只用东八时区的标准时即北京时间为准。
java.util.Date
对象实质上存的是 1970 年 1 月 1 日 0 点( GMT)至 Date 对象所表示时刻所经过的毫秒数。也就是说不管在哪个时区 new Date,它记录的毫秒数都一样,和时区无关。但在使用上应该把它转换成当地时间,这就涉及到了时间的国际化。java.util.Date
本身并不支持国际化,需要借助 TimeZone
。
1 | //北京时间:Wed Jan 27 14:05:29 CST 2021 |
在新特性中引入了 java.time.ZonedDateTime
来表示带时区的时间。它可以看成是 LocalDateTime + ZoneId
。
1 | //当前时区时间 |
小结
通过上面比较新老 Date
的不同,当然只列出部分功能上的区别,更多功能还得自己去挖掘。总之 date-time-api 给日期操作带来了福利。在日常工作中遇到 date 类型的操作,第一考虑的是 date-time-api,实在解决不了再考虑老的 Date。
总结
我们梳理总结的 java 8 新特性有
- Interface & functional Interface
- Lambda
- Stream
- Optional
- Date time-api
这些都是开发当中比较常用的特性。梳理下来发现它们真香,而我却没有更早的应用。总觉得学习 java 8 新特性比较麻烦,一直使用老的实现方式。其实这些新特性几天就可以掌握,一但掌握,效率会有很大的提高。