作者：孤戈

在 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 言语程序的履行进程一般情况都需求通过两步：

  1. 首要，运用编译工具将源代码编译成静态的字节码文件，如：履行 javac App.java 履行后会生成一个 App.class 文件。
  2. 然后，再通过运用 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 内容器间数据传输的效率。

结语

本篇主要从运维和运行时上进行解读，下一篇咱们来讲讲内存。假如有感兴趣的内容，欢迎留言或参加钉群：21958624 与咱们进行沟通与沟通；预祝咱们新春快乐、阖家幸福、“兔”飞猛进！