关于jdk:从-JDK-9-到-19我们帮您提炼了和云原生场景有关的能力列表上

在 JDK 9 之前，Java 基本上均匀每三年出一个版本。然而自从 2017 年 9 月分推出 JDK9 到当初，Java 开始了疯狂更新的模式，基本上放弃了每年两个大版本的节奏。从 2017 年至今，曾经公布了 十一个版本到了 JDK 19。其中包含了两个 LTS 版本（JDK11 与 JDK17）。除了版本更新节奏显著放慢之外，JDK 也围绕着云原生场景的能力，推出并加强了一系列诸如容器内资源动静感知、无进展 GC（ZGC、Shenandoah）、原生的运维能力等等。这篇文章是 EDAS 团队的同学在服务客户的过程中，从云原生的角度将相干的性能进行整顿和提炼而来。心愿能和给大家一起意识一个新的 Java 状态。

云原生场景定义

云原生的外在推动力之一是让咱们的业务工作负载最大化的利用云所带来的技术红利，云带来最大的技术红利就是通过弹性等相干技术，带来咱们资源的高效交付和利用，从而升高最终的资源的经济老本。所以如何最大化的利用资源的弹性能力是很多技术产品所谋求的其中一个指标

同时，另外一个外在推动力是如何去防止云厂商技术的锁定，实现伎俩就是推动各个领域的规范的建设。自从云原生诞生以来，随着 Kubernetes 的大获胜利，以开源为次要状态的技术产品，继续从各个领域中造成既定的标准和规范，是技术产品谋求的另外一个指标。

有了最终的指标，通过一直优化的规范，那么如何在这个新场景下利用上相干的规范能力，是很多产品一直往前演进的方向。以上两点，咱们本人的产品如此，Java 亦如此。

Java 针对性能力

针对 Java 的近十个版本更新，咱们将从运维、编程模型与运行时、内存三个场景进行解读。其中运维局部次要是如何利用现有的容器技术获取运维指标以及在这个场景下的一些原生能力的反对。同时 Java 也在字符串和新的 IO 模型与能力。另外一个最大的变动来自于内存局部，除了在容器场景下对于 CGroup 有更好的反对之外，还提供了令人期待的 ZGC 和 Shenandoah GC 两款无进展的垃圾回收器，除了提供低时延的 STW 之外，还具备偿还局部内存给操作系统，最大限度的提供了利用在云原生场景下利用硬件资源的能力。

整个解读分为高低两篇，除了内存会应用一个独自的文章进行解读之外，剩下的内容次要在这章解说。

更原生的运维场景

1 OperatingSystemMXBean

容器的其中一个能力是过程级别的隔离，默认状况下，容器内的 Java 程序如果基于 JMX 中提供的 OperatingSystemMXBean 中的办法进行拜访，会返回所在宿主机的所有资源数据。在 JDK 14 的版本之后，在容器或其余虚拟化操作环境中执行时，OperatingSystemMXBean 办法将返回容器特定信息（如：零碎可用内存、Swap、Cpu、Load 等），这项能力在基于 JMX 开发的很多能力（如：监控、零碎限流等）是一一项特地敌对的能力。JDK 14 中波及到的革新的 API 如下：

// Returns the amount of free memory in bytes
long getFreeMemorySize();

// Returns the total amount of memory in bytes.
long getTotalMemorySize();

// Returns the amount of free swap space in bytes.
long getFreeSwapSpaceSize();

// Returns the total amount of swap space in bytes
long getTotalSwapSpaceSize();

// Returns the "recent cpu usage" for the operating environment. 
double getCpuLoad();

2 Single File

咱们熟知的 Java 语言程序的执行过程个别状况都须要通过两步：

首先，应用编译工具将源代码编译成动态的字节码文件，如：执行 javac App.java 执行后会生成一个 App.class 文件。

而后，再通过应用 java 启动命令，配合加上相干的类门路并设置启动的主程序之后开始执行应用程序，如：应用 java -cp . App 的形式执行刚刚编译好的字节码程序。

很多其余的动态语言程序，是间接编译生成一个可执行文件，如：c++/go 等。而对于其余的动静脚本语言，Linux 也提供了 #shebang 这种形式，配合文件的可执行权限，达到简化执行形式的目标。

很显然，Java 的执行形式略微繁琐，这对于一些习惯应用脚本形式进行运维的同学就不是特地便当，所以长久以来 Java 语言都和运维没有太大的分割。而到了云原生场景下之后，受到 Code Base 和 Admin processes 理念的影响，很多的一次性工作都习惯性的通过 Job/CronJob + Single-file 的形式执行。JDK 11 中公布的 JEP 330 定义了这种能力，补齐了 Java 从源码执行的形式，即如果通过 java App.java 执行，相当于以下两行命令执行的后果：

$ javac App.java
$ java -cp . App

同时也反对 Linux 的 shebang 文件，即在脚本文件头中指定文件的执行引擎，并给予文件可执行权限后，就能间接执行的脚本的内容，相干脚本形式解释如下：

$ cat helloJava
#!/path/to/java --source version

// Java Source Code

$ chmod +x helloJava
$ ./hellJava

3 JDK_JAVA_OPTIONS

在容器环境中，一旦镜像确定，程序行为就只能通过配置的形式进行扭转了。这也是合乎云原生的因素 Config 的一种设计。然而对于 JVM 程序启动时，因为咱们有很多的配置须要通过启动参数进行配置（比方：对内存设置，- D 设置零碎参数等等）。除非咱们在 Dockerfile 编写阶段就反对 JVM 启动命令手动传入相干的环境变量来扭转 JVM 的行为，否则这种设计对于 Java 而言就很不敌对。好在 JVM 提供了一个零碎的环境变量 JAVA_TOOL_OPTIONS，来反对通过读取这个环境变量的值来设置的启动参数的默认值。可是这个参数存在以下的问题：

1. 不仅针对 java 命令失效：其余的管控命令如：jar, jstack, jmap 等也一样会失效。而容器内的过程默认都会读取内部传入的环境变量的值，即一旦设置，这个值会被容器内所有的过程共享，意味着当咱们想进入到容器进行一些 java 程序的排查工作时，默认都会受到 JAVA_TOOL_OPTIONS 这个变量的“净化”而得不到预期的后果。
2. 环境变量的长度限度：无论是在 Linux Shell 外部还是在 Kubernetes 编排的 yaml 中，针对环境变量的长度都不会是有限的，而 JVM 启动参数通常都会很长。所以很多时候会遇到因为 JAVA_TOOL_OPTIONS 的值过长而引起不可预知的行为。

在 JDK 9 中，提供了一个新的环境变量 JDK_JAVA_OPTIONS，它只会反对影响到 java 启动命令，不会净化其余命令；同时还反对了通过 export JDK_JAVA_OPTIONS=’@file’ 的形式从指定的文件读取的相干的内容；从而很好的躲避了以上两个问题。

4 ExitOnOutOfMemoryError

OutOfMemoryError 是 Java 程序员最不想遇到的一个场景，因为见到它可能意味着零碎中存在肯定水平的内存泄露。而且内存泄露的问题个别都须要很繁琐的步骤加上大量精力的进行剖析查出来。从发现问题，到定位到这个问题，往往须要消耗的大量的工夫和精力。为了保障业务的连续性，如何在产生谬误时及时的复原以止损是咱们解决故障时的首要准则；如果零碎产生了 OutOfMemoryError，咱们往往会抉择疾速重启进行复原。

在 Kubernetes 中定义了 Liveness 存活探针，让程序员有机会依据业务的衰弱水平来决定是否须要进行疾速重启。因为常见的 OutOfMemoryError 经常会随同着大量的 FullGC，随着 FullGC 引发 CPU/Load 飙高而引发申请工夫过长，咱们能够依据这一个性，抉择适合的业务 API 进行利用衰弱存活的探测。然而这个计划存在以下一些问题：

1. 首先，所抉择的 API 存在误判的可能性，API 超时可能因为很多的起因引起，内存只是其中一种。
2. 其次，产生 OutOfMemoryError 谬误时不肯定全是业务应用的堆内存的问题，如：元数据空间溢出、栈空间溢出、无奈创立零碎线程等都会有这个谬误呈现。
3. 第三，从产生问题到最初探活失败，通常须要经验间断多长时间的反复失败探测才会导致最终的失败。这个过程会有肯定的时延。

这个问题在 JDK9 中有了更好的解法，这个版本中引入了额定的零碎参数：

• ExitOnOutOfMemoryError：即遇到 OutOfMemoryError 时，JVM 马上退出。
• CrashOnOutOfMemoryError：除了继承了 ExitOnOutOfMemoryError 的语义之外，同时还会生成 JVM Crash 的日志文件，让程序能够在退出前进行现场的根本保留。
• OnOutOfMemoryError：能够在此参数后退出一个脚本，配合此脚本，能够在退出前进行一些状态的清理。

以上三个参数在云原生所推崇的 “Fail Fast” 理念中特地的有价值，尤其是在无状态的微服务利用场景（如在 EDAS 中）中，在退出前联合 OnOutOfMemoryError 的脚本做很多优雅下线的工作，同时能够将 JVM Crash 的文件输入到云盘 (如：NAS) 中。最大限度保障咱们的业务因为内存而受到烦扰，同时还能保留过后的现场。

5 CDS

云原生利用所践行另外一个理念是利用的疾速启动，在 Serverless 的推动下，云厂商都在为利用的冷启动指标致力，Java 利用始终因为初始化工夫过长而饱受锆病，在最近的 EDAS 2022 的年度报告中，EDAS 中托管利用 70% 的启动工夫要 30 秒以上。如果咱们仔细分析，Java 利用启动工夫除了应用程序自身的初始化之外，还有 JVM 的初始化过程，而 JVM 的初始化过程中中最长的要数 Class 文件的查找和加载。CDS 技术就是为减速 Class 文件启动速度而生，它为 Class-Data Sharing 的简称，即为利用间共享 Class-Data 数据信息的一种技术，原理是利用 Class 文件不会被轻易扭转的特点，能够将其中一个过程中产生的 Class 元数据信息间接 dump，在新启动的实例中进行共享复用。省去每个新实例都须要从 0 开始初始化的开销。

CDS 从 JDK 5 开始就有介绍，不过第一个版本只反对 Bootrap Class Loader 的 Class 共享能力。

到 JDK 10 引入 AppCDS，容许加载利用级别的 Class；JDK 13 中的 引入了两个 JVM 参数（-XX:ArchiveClassesAtExit=foo.jsa 与 -XX:ShareArchiveFile=foo.jsa），联合这个两个参数的应用，能够在程序退出前进行共享文件的动静 dump，在启动时加载；而在 JDK 19 中又简化了运维操作，通过 -XX:+AutoCreateSharedArchive 这个参数做到了运行时无需检测共享文件的幂等性，进一步的晋升了这项技术的易用性。

更敌对的运行时能力

1 Compact Strings

在 Java 外部，咱们所有的字符存储都是应用 char 类型 2 个字节 (16 个字节) 来进行存储，官网从很多不同的线上 Java 利用中已经剖析过，JVM 外部的堆的耗费次要是字符串的应用。然而大部分的字符串仅仅存储了一个拉丁字符，即 1 个字节就能残缺示意。所以实践上，绝大多数的字符串只须要一半的空间就能实现存储和示意。

从 JDK9 开始，JDK 中对于字符串的默认实现（java.lang.String, AbstractStringBuilder, StringBuilder, StringBuffer）的外部实现上，默认集成了这种机制，这个机制依据字符串的内容，自动编码成 一个字节的 ISO-8859-1/Latin- 1 或 两个字节的 UTF-16，从而大幅缩小堆内存的使用量。更小的堆应用同时也缩小了 GC 次数，从而系统性的晋升了整个零碎的性能。

字符串压缩 JDK 从 1.6 就开始摸索，过后在 JVM 参数层面提供了一个非开源 UseCompressedStrings 的开关来实现，关上之后它将通过扭转存储构造（byte[]或 char[]）来达到压缩的目标，因为这种形式只批改了 String 类的实现，没有系统性的梳理其余字符串应用的场景，在试验的过程中引发了一些不可预知的问题，起初在 JDK7 中被抹除。

2 Active Processor Count

Active Processor Count 是指获取 JVM 过程能利用上的 CPU 核数，对应 JDK 中的 API 是 Runtime.getRuntime().availableProcessors()，常见于一些零碎线程和 I/O（如：JVM 内默认的 GC 线程数、JIT 编译线程数、某些框架的 I/O、ForJoinPool 等）的场景中，咱们会习惯性的将的线程个数设置成 JVM 能获取到的这个数。然而一开始的默认实现是通过读取 /proc/cpuinfo 文件系统下的 CPU 数据来设置。容器场景中如果不做非凡默认读取到的是宿主机的 CPU 信息。而容器场景下，通过 cgroup 的隔离机制，咱们其实能够给容器设置一个远小于所在机器的实在核数。比方如果咱们在一台 4 核的机器上，在一个只设置了 2 个核的容器跑一个 JVM 程序的话，它取得的数据是 4，而不是冀望的 2。

容器内的资源感知不仅仅是 CPU 这一项，比拟驰名的版本是 JDK 8u191，这个版本中除了 CPU 之外，还减少了对于内存最大值的获取、宿主机上对于容器内 JVM 过程的 attach (jstack/jcmd 命令等) 的优化等。在 CPU 的改良点上，次要是做了以下两点加强：

1. 首先：新增了一个启动参数 -XX:ActiveProcessorCount，能够显示的指定处理器的数量。
2. 其次：依据 CGroup 文件系统进行主动的探测，其中主动探测的相干变量有 3 个，1）CPU Set（间接以绑核的形式进行 CPU 调配）；2）cpu.shares；3）cfs_quota+ cfs_period。其中的在 Kubernetes 场景下，默认优先级是 1) > 2) > 3)。

这里大家可能会有一个疑难，为什么在 Kubernetes 场景中会带来问题？比方咱们通过以下的配置来设置一个 POD 的资源应用状况：

    resources:
      limits:
        cpu: "4"
      requests:
        cpu: "2"

以上的配置示意这个 POD 最多能用 4 个核，而向零碎申请的资源则是 2 个核。在 Kubernetes 外部，CPU limit 局部最终是应用 CFS (quota + period) 的形式进行示意，而 CPU request 局部最终是通过 cpu.shares 来设置（具体 kubernetes 是如何进行的 cgroup 映射，不再本篇的叙述范畴）。则此时场景下，默认通过 Runtime.getRuntime().availableProcessors()能获取到的核数就是 2。而不是咱们预期中的 4。

如何防止这个问题？第一个最为简略的形式，就是默认通过 -XX:ActiveProcessorCount 显示进行 CPU 的传递，当然这里带来一点点须要重写启动命令上的运维动作。JVM 在 JDK19 中，默认去掉了依据 cpu.shares 来进行计算的逻辑，同时新增了一个启动参数 -XX:+UseContainerCpuShares 来兼容之前的行为。

3 JEP 380: Unix domain sockets

Unix domain socket (简称：UDS)是一种在 Unix 系列的零碎之下解决同一台机器中过程间 (IPC) 通信的一种形式。在很多方面，他的应用形式和 TCP/IP 相似，如：针对 Socket 的读写行为、链接的接管与建设等。然而也有诸多的不同，比方它没有理论的 IP 和端口，他不须要走一个 TCP/IP 的全栈解析和转发。同时相比拟间接应用 127.0.0.1 的形式进行传输，还有以下两个不言而喻的长处：

1. 平安：UDS 是一种严格在本机内过程间进行通信的设计，它不能承受任何近程拜访，所以它从设计上久防止了非本机过程的烦扰。同时它的权限管制也能间接应用到 Unix 中基于文件的权限访问控制，从而从零碎角度大大加强安全性。
2. 性能：尽管通过 127.0.0.1 进行 Loopback 的拜访形式在协定栈上做了很多优化，然而从实质上它还是一种 Socket 的通信形式，即他还是须要进行三次握手、协定栈的拆包解包、受零碎缓冲区的制约等。而 UDS 的链接建设无需那么简单，且数据传输上也不须要通过内核层面的屡次拷贝，传输数据的逻辑逻辑简化到：1）寻找对方的 Socket。2）间接将数据放给对方的收音讯的缓冲区。这样简练的设计，相比 Loopback 在小数据量发送的场景下效率高了一倍以上。

在 Java 中，始终没有反对对 UDS 的反对，然而到了 JDK 16 这一场面将迎来改观，然而为什么 Java 到当初才退出对 UDS 的反对呢？起因我感觉还是云原生场景的冲击。在 Kubnernetes 的场景下，在一个 POD 内编排多个容器一起应用的形式 (sidecar 模式) 将会变的越来越风行，在同一个 POD 外部的多个容器中进行数据传输时，因为默认都是在同一命名空间的文件系统下，UDS 的退出会大大晋升同一个 POD 内容器间数据传输的效率。

作者：孤戈

原文链接

本文为阿里云原创内容，未经容许不得转载。