前言

在 JDK 9 之前，Java 基本上平均每三年出一个版别。可是自从 2017 年 9 月份推出 JDK9 到现在，Java 开端了张狂更新的形式，基本上坚持了每年两个大版别的节奏。从 2017 年至今，现已发布了一个版别到了 JDK 19。其间包括了两个 LTS 版别（JDK11 与 JDK17）。除了版别更新节奏明显加快之外，JDK 也围绕着云原生场景的才能，推出并增强了一系列诸如容器内资源动态感知、无中止GC（ZGC、Shenandoah）、运维等等云原生场景方面的才能。这篇文章是 EDAS 团队的同学在服务客户的过程中，从云原生的视点将相关的功用进行收拾和提炼而来。期望能和我们一同知道一个新的 Java 形状。

上一篇 (《从 JDK 9 到 19，咱们帮您提炼了和云原生场景有关的才能列表（上）》)咱们讲了在整个演进过程中针对运转时模型和运维才能的一些重要改动，这一节咱们主要是来讲讲内存相关的改动。

JVM GC 开展回忆

JVM 自从诞生以来，以 “内存主动办理” 和 “一次编译到处运转” 两个杀手锏才能，外加 Spring 这个超级生态，在企业运用开发领域中一向处于“人人仿照，从未逾越”的江湖地位。内存的主动办理从技能视点，用一句浅显的言语进行简述便是：“依据规划好的堆内存布局模型，选用一定的跟踪识别与收拾的算法，到达内存主动收拾及收回的作用”。而一代代内存办理技能不断演进的方针，便是在不断提高并发与下降延时的一同，寻觅资源运用最优的计划，从某种意义上说，假如咱们不带来一些突破性的算法，这个三者的联系好像分布式中的 CAP 定理相同，很难兼得。如下图所示：

从 JDK 9 到 19，认识一个新的 Java 形态（内存篇）

在 JVM 中，内存办理 趋近等同于 GC，GC 也是 Java 程序员取得一份作业时必考的知识点。其间 CMS 从 1.4 版别(2002年)开端引进，一度成为最为经典的 GC 算法。可是从 JDK9 开端建议弃用 CMS 的 JEP 提案，到 2020 年初发布的 JDK14 彻底从代码中抹除，意味着在他成年之际正式宣告了他历史使命的完毕。那么到现在咱们又应该从什么视点上去了解这一技能领域的开展方向，往后面试官又会从哪些方面对咱们建议发问，是不论技能怎么演进，能确定的是改动主线是围绕着三个方向进行，别离是：堆内存布局、线程模型、搜集行为。EDAS 团队经过一段时刻收拾出来了这篇文章，咱们也将从三个点出发进行分享，期望能给我们一些启发。

堆内存布局的改动

JVM 堆内存布局最为经典的是分代模型，即年青代和老时代进行区分，不同的区域选用的收回算法和战略也彻底不相同。在一个在线运用（如微服务形状）的 request <-> response 模型中，所发生的方针(Object)绝大多数是瞬时存活的方针，所以大部分的方针在年青代就会被相对简略、轻量、且高频的 Minor GC 所收回。在年青代中经过几次 Minor GC 若依然存活则会将其晋升到老时代。在老时代中，比较较而言因为方针存活多、内存容量大，所以所需求的 GC 时刻相对也会很长，一同因为每一次的收回会伴跟着长期的 Stop-The-World (简称STW)出现。在内存需求比较大且关于时延和吞吐要求很高的运用中，其老时代的体现就会显得绰绰有余。并且因为不同的分代所选用的收回算法一般都不相同，跟着事务杂乱度的添加，GC 行为变得越来越难以了解，调优处理也就愈发的杂乱 。

从 JDK 9 到 19，认识一个新的 Java 形态（内存篇）

单纯从堆内存布局来了解，一个简略的逻辑是内存区域越小，收回效率越高，经典分代模型中的 Young 区现已印证了这一点。为了解决上述问题，G1 算法横空出世，引出根据区域（Region）的布局模型，带来的改动是内存在物理上不再依据方针的“年龄”来区分布局，而是默许悉数区分红等巨细的 Region 和专门用来办理超级大方针的独占 Region，年青代和老时代不再是一个物理区分，只是一个 Region 的一个特点。直观了解上，除了能办理的内存更大（G1 理论值 64G）之外，这样带来一个清楚明了的优点便是能够预操控一次 FullGC 的 STW 的时刻，因为 Region 巨细一致，则能够依据中止时刻来计算这次 GC 需求收回的 Region 个数，而没有必要每次都将一切的 Region 悉数收拾完毕。

从 JDK 9 到 19，认识一个新的 Java 形态（内存篇）

跟着这项技能的进一步开展，到了现代化的 Pauseless(ZGC) 的算法场景中，有些算法暂时没有了分代的概念，一同 Region 依照巨细区分了 Small/Medium/Large 三个等级，更精密的 Region 办理，也进一步来更少的内存碎片和内存运用率的提高、及其 STW 中止时刻更精准的预测与办理。

从 JDK 9 到 19，认识一个新的 Java 形态（内存篇）

线程模型改动

说线程模型之前，先简略提一下 GC 线程与事务线程，GC 线程是指 JVM 专门用来处理 GC 相关使命的线程，这在 JVM 启动时就现已决议。在传统的串行算法中，是指只要一个 GC 线程在作业。在并行(Parallel)的算法中，存在多个 GC 线程一同作业的状况（CMS 中 GC 线程个数默许是 CPU 的核数）。一同一些算法的某些阶段中(如：CMS 的并发标记阶段)，GC 线程也能够和事务线程一同作业；这个机制就缩短了全体 STW 的时刻，这也是咱们所说的并发(Concurrent) 形式。

从 JDK 9 到 19，认识一个新的 Java 形态（内存篇）

在现代化的 GC 算法中，并不是一切和 GC 相关的使命都只能由 GC 线程完成，如 ZGC 中的 Remap 阶段，事务线程能够经过内存读屏障(Read Barrier)，来纠正方针在此阶段因为被重新分配到新区域后的指针改动，然后进一步削减 STW 的时刻。

搜集行为改动

搜集行为是指的在识别出需求被搜集的方针之后，JVM 关于方针和地点内存区域怎么进行处理的行为。从前期版别至今，大致分为以下几个阶段：

  1. Mark Copy：是指直接将存活方针从本来的区域拷贝至别的一个区域。这是一种典型的空间换时刻的战略，优点清楚明了：算法简略、中止时刻短、且调参优化容易；但一同也带来了近乎一倍的空间搁置。在前期的 GC 算法运用的是经典的分代模型。其间关于年青代 Survivor 区的搜集行为便是这种战略。

从 JDK 9 到 19，认识一个新的 Java 形态（内存篇）

  1. Mark Sweep：为了削减空间成倍的浪费，其间一个战略便是在原有的区域直接对方针 Mark 后进行擦除。但因为是在本来的内存区域直接进行方针的擦除，运用进程运转久了之后，会带来许多的内存碎片，其结果是内存持续增长，但实在运用率趋低。

从 JDK 9 到 19，认识一个新的 Java 形态（内存篇）

  1. Mark Sweep-Compact: 这是关于 Mark Sweep 的一个改良行为，即擦除之后会对内存进行重新的压缩收拾，用以削减碎片然后提高内存运用率。可是假如每次都进行收拾，就会延长每次 FullGC 后的 STW 时刻。所以 CMS 的战略是经过一个开关(-XX:+UseCMSCompactAtFullCollection默许开) 和一个计数器(-XX:CMSFullGCsBeforeCompaction默许值为 0) 进行操控，表明 FullGC 是否需求做压缩，以及在多少次 FullGC 之后再做压缩。这个两个装备配合事务形状去做调优能起到很好的作用。

从 JDK 9 到 19，认识一个新的 Java 形态（内存篇）

  1. Mark Sweep-Compact-Free: JVM 的运用有一个“内存吞噬器”的恶名，原因之一便是在进程运转起来之后，他只会向操作体系要内存从来不会偿还(典型只借不还的渣男)。不过这些在现代化的分区模型算法中开端有了改善，这些算法在 FullGC 之后，能够将收拾之后的内存以区域(Region)为粒度偿还给操作体系，然后下降这一个进程的资源水位，以此来提高整个宿主机的资源运用率。

从 JDK 9 到 19，认识一个新的 Java 形态（内存篇）

云原生相关的重点才能

关于云原生场景云原生的内涵推动力之一是让咱们的事务作业负载最大化的运用云所带来的技能盈利，云带来最大的技能盈利便是经过弹性等相关技能，带来咱们资源的高效交付和运用，然后下降终究的经济本钱。所以怎么最大化的运用资源的弹性才能是许多技能产品所追求的其间一个方针。

这一末节，咱们抽取了 JDK9 – JDK 19 中内存相关的代表性才能，别离是：G1 NUMA-Aware、Elastic Metaspace、ZGC Uncommit Unused Memory。和我们一同感受一下 JVM 在新的技能趋势下怎么拥抱和改动。

JEP 345:G1 NUMA-Aware

现代化的服务器大多是属于多 Node 的架构，下图表明有 4 个 Node，每一个 Node 内部都会有相应的 CPU(有的架构会有多个 CPU) 和对应的物理内存条。当 CPU 拜访拜访本 Node 内部的物理内存进行“本地拜访”时，其速度是经过 QPI 拜访其他节点内存时的速度接近两倍，一同不同远近 Node 的拜访速度也都不相同。在敞开 NUMA 的状况下，每个 Node 内的 CPU 将优先运用同 Node 内的“本地”内存，不然体系将一切 Node 内的内存统一对待进行随机分配和拜访。

从 JDK 9 到 19，认识一个新的 Java 形态（内存篇）

已然 Numa 的作用是 CPU 将尽量拜访“本地”内存以加速内存拜访速度，惯例场景下假如咱们需求运用这个才能，在体系敞开 Numa 的前提下，咱们还需求对运转的程序进行绑核调优等操作，以将运用程序运转的进程和CPU有一个绑定联系。要到达这一作用，除了体系供给了一些运维办理东西(如 linux 中的 taskset 指令)之外，程序也能够经过调用体系 API (如 linux 中的 pthread_setaffinity)。在 JVM 多线程的模型中，假如想要经过主动编程的办法来进行 CPU 绑定，当下只能挑选带有特定才能的商业版别，在 OpenJDK 中还不能很便利的完成这一才能。

那 JVM 内关于 Numa 能做什么呢？这儿有一个假设，在一个线程内运转的方针大部分都是瞬时的（即这个方针的作用域跟随创立它的线程(或 Runnable)的运转完毕而消亡），原因和咱们在上面介绍堆内存布局模型时的新生代的挑选是相同逻辑。根据这个假设，JVM 主要聚焦在了解决新生代的内存分配和拜访的 Numa 感知上。其实 JVM 关于 Numa 的支撑许多年前就开端了，在 YoungGC 的并行(Parrallel)搜集器（经过-XX:+UseParallelGC敞开）中。敞开 Numa 之后，JVM 优先挑选 Node 内部的“本地”内存进行新方针的创立。

在云原生场景下，一个 Kubernetes 集群一般保管高标准的机器、一同高密的布置的小标准的作业负载，这个场景下，一个作业负载一向运转在同一个 CPU 或固定几个 CPU 的场景会变得越来越遍及。假如 JVM 再把整个 Worker 的内存不加区分的对待并进行分配，咱们的内存拜访性能势必会急剧跌落。如下图所示：

从 JDK 9 到 19，认识一个新的 Java 形态（内存篇）

G1 算法经过JEP 345 在 JDK 14 中得到了这一才能的支撑，可经过参数-XX:+UseNUMA敞开，敞开之后，G1 会尽量将固定巨细的各个 Region 均摊在一切能分配的 CPU Node 中，在分配新方针时，将优先运用同一 Node 内的“本地”内存的 Region，假如“本地”内存 Region 不行时，将对此 Region 触发一次 GC；假如还不行，再依照 CPU 的远近尽量获取相邻 Node 的 Region。此战略只针对 G1 中新生代的内存区域生效。老时代区域和大方针区域仍是沿袭默许的战略。

JEP387:Elastic Metaspace

Metaspace 是用来存储 JVM 中类的元数据信息，包括类中的运转时数据结构、类中运用到的成员以及办法信息。他的前身是永久代，也便是 PermGen。这一改动是 JDK 8 中重要的一个升级的才能之一。从 JEP 122 中提议并落地。这个 JEP 带来的具体的改动能够参阅下图：

从 JDK 9 到 19，认识一个新的 Java 形态（内存篇）

取消了永久代之后，带来两个改动如下：

  1. 只存储类元数据信息，即：a) Klass 信息，描述类的根底特点和类的继承联系等；b）NonKlass 信息，包括办法、内部类信息、成员变量定义等。

  2. 内存布局调整： 与之前在堆中开辟一块区域比较，Metaspace 是直接运用操作体系的本地内存进行分配，本地内存区分红多个 Chunk，以 ClassLoader 为维度进行分配和办理。

当一个 ClassLoader 加载一个方针时，所需求的空间从闲暇的 Chunk 中分配一个或多个固定巨细的块，如未找到则向操作体系重新请求一个 Chunk。当某一个 ClassLoader 中一切的类都被卸载的时候，就能够将它所引证的内存块都偿还给 Chunk。比及对应 Chunk 彻底处于“闲暇”状况的时候，这个 Chunk 也就就能够被操作体系收回。

看到这儿咱们先暂停一下，考虑两个问题：

  1. 合，而 JRockit 的规划中并没有永久代。而从时刻上看，正好是发生在 Oracle 收购 Sun 之后。所以一个猜测便是这个改动的根因应该是组织推动大于技能驱动。当然从技能上这样带来的优点也很清楚明了：不再有负载的 Perm 设置；元空间和堆空间彻底隔离后，两边的 GC 不会相互影响；单次 FullGC 因为扫描区域更小而使得 STW 时刻更短；依照 Chunk 规划的构想，在类被卸载时，有助于 JVM 开释一些内存给操作体系等等。

  2. 有没有带来新问题？ 有，便是在一些运用程序中会出现多种类频繁的 加载/卸载 的场景下， 导致 Metaspace 所办理的 Chunk 会不停的更新和开释而造成很严重的内存碎片，碎片收拾机制的缺失导致抱负中的作用并未到达。终究造成了更多的内存浪费。

在 JDK 16 中发布的 JEP 387 中，专门针对带来的新问题做了一些改善:

  • 首先：削减碎片，内存办理从内置的 Arena Chunk 内存办理算法，改为了简略且经典的伙伴算法，对，Linux 操作体系的内存办理便是根据伙伴算法的。

伙伴体系把一切的闲暇页框分组为固定个数的块链表，每个块链表别离包括固定巨细为 1K, 2K, 4K, …. 4M 巨细的块。当运用程序向体系请求对应的内存巨细时，体系将从最接近所需巨细的链表中进行分配。

  • 其次：按需运用，比及实在运用内存的时候才向操作体系建议内存请求，而不是一开端就请求出来一块很大的空间。

有一些 ClassLoader（如：BoostrapClassLoader）往往需求许多的空间，可是他实在运用并不是从一开端启动就需求，并且甚至是永久都不需求。

  • 第三：添加战略，为了避免频繁的向操作体系 请求/开释 内存带来额定的体系开支，新引进了一个指令行参数-XX:MetaspaceReclaimPolicy=(balanced|aggressive|none)来进行调整。

其间 balance 是默许选项，会在体系收回和时刻消耗之间做平衡，更多是兼容之前的行为。aggressive 是一种最为 “急进” 的收回战略，经过在收回时下降对应页框巨细至 16K（默许64K），使收回内存粒度更细来下降碎片。而 none 则是关闭收回行为。

JEP 351: ZGC Uncommit Unused Memory

ZGC 在 JDK 11 时被引进，它是一款根据内存区域(Region) 布局的垃圾收回器，咱们能够经过-XX:+UseZGC进行敞开。作为一款主打 Pauseless 的现代化的搜集器，ZGC 比较于 G1 除了供给了三个不同巨细的 Region (2M/4M/8M，而 G1 为一个固定巨细的值)进行办理之外，还因为在 GC 收拾阶段供给了内存读屏障来纠正方针指针的技能使得终究的 STW 时刻更短。可是在 JDK 14 之前，被收拾的 Region 仍是无法偿还给操作体系，比较 G1 在 JDK9 中就供给了类似的才能滞后了两年多。

简略概述一下，这个 JEP 指的是每次 GC 完毕，JVM 都会尝试将开释一部分内存偿还给操作体系。可是如上一章节介绍 Elastic Metaspace 章节相同，频繁的向操作体系 请求/偿还 只能带来更多的体系开支，怎么取舍是一门艺术。那么该怎么挑选是否有操作手段呢？请先看下面这张图：

从 JDK 9 到 19，认识一个新的 Java 形态（内存篇）

首先，体系供给了一个额定的 JVM 的调整参数(SoftMaxHeapSize)来操控收回的行为，这个值应该在 -Xms 和 -Xmx 之间，当体系运用的内存低于这个值时，便是正常的搜集行为，即只会进行收拾和压缩。而大于这个值可是小于 -Xmx 时，FullGC 完毕之后就会尝试收回闲暇的内存区域(Region) 偿还给操作体系。到达的作用是 ZGC 将尽量保证全体堆内存水位处于这个值之下。默许状况下这个值和 -Xmx 的巨细是一致的。一同因为这个值是一个可动态调整(managable)的变量，跟着体系的运转，当咱们发现需求进行调整的时，在认真评估之后，能够经过jcmd VM.set_flag SoftMaxHeapSize 指令动态进行调整。

其次，上述计划虽然很完美的将挑选权交给了运用办理人员，可是运转的过程中也会出来一种状况：假如运用实在的运用量假如恰好在SoftMaxHeapSize上下徜徉的时候，会造成很频繁的体系内存的请求和开释。这个时候供给了别的一个战略，便是能够经过-XX:ZUncommitDelay来设置一个收回之前的延时，即不在 GC 完毕马上进行尝试收回，而是等一段时刻(默许 5 分钟)后再进行收回，避免造成误伤。

结语

到这儿，一切相关的云原生场景解读就完了；整个读下来，自己的感觉是 JVM 在这个场景下除了更好的去融入到这个场景之外，并且还不断的摒弃自己原有的即使是很成熟经典的规划，层层蜕变，在云原生场景下不断的将技能价值开释出来。云原生潮涌来，我借用孙子兵法中的一句话与各位共勉：“故善战人之势，如转圆石于千仞之山者，势也。”。回到咱们的场景浅显了解便是你会看到你的合作伙伴、你的客户、你所运用的东西链、甚至你找的下一份作业时面试官的问题，都在受到这一理念与技能的影响而做出改动，这是技能浪潮中的大势。

如对上述论题感兴趣想深入探讨，欢迎留言或加入钉群：21958624 与咱们（ EDAS 团队）进行沟通与交流，云原生微服务运用平台 EDAS 始终致力于运用架构云原生化，2023 春季新推采购活动，新客户头两月不定量运用，助力我们缩短转型过程中的途径。