Java11占比第一?

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

参考资料

  1. 报告PDF:https://newrelic.com/sites/default/files/2022-04/new-relic-report-state-of-the-java-ecosystem-april-2022.pdf
  2. Oracle官网:https://www.oracle.com/java/technologies/javase/11-relnote-issues.html
  3. InfoQ:《架构师》2018年10月

声明:文中观点不代表本站立场。本文传送门:https://eyangzhen.com/221966.html

联系我们
联系我们
分享本页
返回顶部