Java11 新特性
根据软件服务公司New Relic 发布的《2022 年 Java 生态系统现状》报告中,Java 11已成为新的标准(占比48.44%)。
Java11是一个长期支持版本(Long-term supper version)。共包含17个JEP(JDK Enhancement Proposals,JDK增强提案)。
Java11 JEP:
- JEP 181 Nest-Based Access Control(基于嵌套的访问控制)
- JEP 309 Dynamic Class-File Constants(动态类文件常量)
- JEP 315 Improve Aarch64 Intrinsics(改进 Aarch64 函数)
- JEP 318 Epsilon, A No-Op Garbage Collector
- JEP 320 Remove the Java EE and CORBA Modules(移除 Java EE 和 CORBA 模块)
- JEP 321 HTTP Client (Standard)
- JEP 323 Local-Variable Syntax for Lambda Parameters
- JEP 324 Key Agreement with Curve25519 and Curve448(采用Curve25519 和 Curve448 算法实现的密钥协议)
- JEP 327 Unicode 10
- JEP 328 Flight Recorder
- JEP 329 ChaCha20 and Poly1305 Cryptographic Algorithms(实现ChaCha20 和 Poly1305 加密算法)
- JEP 330 Launch Single-File Source-Code Programs(启动单个Java源代码文件的程序)
- JEP 331 Low-Overhead Heap Profiling
- JEP 332 Transport Layer Security (TLS) 1.3(支持 TLS 1.3)
- JEP 333 ZGC A Scalable Low-Latency Garbage Collector (Experimental)
- JEP 335 Deprecate the Nashorn JavaScript Engine(弃用 Nashorn JavaScript 引擎)
- JEP 336 Deprecate the Pack200 Tools and API(弃用 Pack200 工具及其 API)
JEP 318 Epsilon, A No-Op Garbage Collector
开发一个处理内存分配但不实现任何实际内存回收机制的 GC。一旦可用的 Java 堆用完,JVM 就会关闭。
目标
以内存占用和内存吞吐量为代价,提供具有有限分配限制和尽可能低的延迟开销的完全被动 GC 实现。一个成功的实现是一个独立的代码更改,不涉及其他 GC,并对 JVM 的其余部分进行最小的更改。
JEP 321 HTTP Client (Standard)
标准化JDK 9 中引入的孵化HTTP 客户端 API 对Http客户端进行标准化
示例代码:
private void send() throws IOException, InterruptedException {
HttpRequest request = HttpRequest.newBuilder()
.uri(URI.create("https://www.baidu.com/"))
.timeout(Duration.ofSeconds(20))
.header("Content-Type", "application/json")
//.POST(HttpRequest.BodyPublishers.noBody())
.GET()
//.POST(HttpRequest.BodyPublishers.ofFile(Paths.get("file.json")))
.build();
HttpClient client = HttpClient.newBuilder()
.version(HttpClient.Version.HTTP_1_1)
.followRedirects(HttpClient.Redirect.NORMAL)
.connectTimeout(Duration.ofSeconds(20))
//.proxy(ProxySelector.of(new InetSocketAddress("https://www.baidu.com", 80)))
//.authenticator(Authenticator.getDefault())
.build();
//同步调用
HttpResponse response = client.send(request, HttpResponse.BodyHandlers.ofString());
System.out.println(response.statusCode());
System.out.println(response.body());
//异步调用
CompletableFuture future = client.sendAsync(request, HttpResponse.BodyHandlers.ofString())
.thenApply(HttpResponse::body)
.thenAccept(System.out::println);
}
JEP 323 Local-Variable Syntax for Lambda Parameters
允许var在声明隐式类型 lambda 表达式的形式参数时使用
目标
将隐式类型的 lambda 表达式中的形式参数声明的语法与局部变量声明的语法对齐。
对于隐式类型的 lambda 表达式的形式参数,允许使用保留的类型名称var,以便:
(var x, var y) -> x.process(y)
相当于:
(x, y) -> x.process(y)
JEP 328 Flight Recorder
概括
为 Java 应用程序和 HotSpot JVM 故障排除提供低开销数据收集框架。
目标
- 提供 API 用于将数据作为事件生成和使用
- 提供缓冲机制和二进制数据格式
- 允许配置和过滤事件
- 为操作系统、HotSpot JVM 和 JDK 库提供事件
动机
故障排除、监控和分析是开发生命周期的组成部分,但有些问题只发生在生产中,在涉及真实数据的高负载下。
Flight Recorder 记录源自应用程序、JVM 和操作系统的事件。事件存储在单个文件中,可以附加到错误报告并由支持工程师检查,从而允许在导致问题的期间对问题进行事后分析。工具可以使用 API 从记录文件中提取信息。
JEP 331 Low-Overhead Heap Profiling
概括
提供一种对 Java 堆分配进行采样的低开销方式,可通过 JVMTI 访问。
目标
提供一种从 JVM 获取有关 Java 对象堆分配信息的方法:
- 开销是否足够低,可以默认连续启用,
- 可通过定义明确的编程接口访问,
- 可以对所有分配进行采样(即,不限于在一个特定堆区域中或以一种特定方式分配的分配),
- 可以以独立于实现的方式定义(即,不依赖于任何特定的 GC 算法或 VM 实现),
- 并且可以提供关于存活的和死亡的 Java 对象的信息。
JEP 333 ZGC A Scalable Low-Latency Garbage Collector (Experimental)
概括
Z 垃圾收集器,也称为 ZGC,是一种可扩展的低延迟垃圾收集器。
目标
- GC 暂停时间不应超过 10ms
- 暂停时间不会随着堆或 live-set 的大小而增加
- 处理大小从几百兆字节到数 TB 不等的堆
- 与使用 G1 相比,应用程序吞吐量减少不超过 15%
ZGC 的核心是一个并发垃圾收集器,这意味着所有繁重的工作(标记、压缩、引用处理、字符串表清理等)都是在 Java 线程继续执行时完成的。这极大地限制了垃圾收集对应用程序响应时间的负面影响。
ZGC 作为一个实验特性被包含进来。因此,要启用它,该-XX:+UnlockExperimentalVMOptions选项需要与该-XX:+UseZGC选项结合使用。
以下是使用 128G 堆在复合模式下比较 ZGC 和 G1 的典型基准分数(以百分比表示,根据 ZGC 的 max-jOPS 标准化)。
(越高越好)
ZGC
max-jOPS: 100%
critical-jOPS: 76.1%
G1
max-jOPS: 91.2%
critical-jOPS: 54.7%
以下是来自同一基准测试的典型 GC 暂停时间。ZGC 设法保持远低于 10 毫秒的目标。请注意,确切的数字可能会有所不同(上下变化,但不显着),具体取决于所使用的确切机器和设置。
(越低越好)
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
参考资料
- 报告PDF:https://newrelic.com/sites/default/files/2022-04/new-relic-report-state-of-the-java-ecosystem-april-2022.pdf
- Oracle官网:https://www.oracle.com/java/technologies/javase/11-relnote-issues.html
- InfoQ:《架构师》2018年10月
声明:文中观点不代表本站立场。本文传送门:https://eyangzhen.com/221966.html