共计 7059 个字符，预计需要花费 18 分钟才能阅读完成。
前言
在 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 定理一样，很难兼得。如下图所示：
在 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 行为变得越来越难以了解，调优解决也就愈发的简单。
单纯从堆内存布局来了解，一个简略的逻辑是 内存区域越小，回收效率越高，经典分代模型中的 Young 区曾经印证了这一点。为了解决上述问题，G1 算法横空出世，引出基于区域（Region）的布局模型，带来的变动是内存在物理上不再依据对象的“年龄”来划分布局，而是默认全副划分成等大小的 Region 和专门用来治理超级大对象的独占 Region，年老代和老年代不再是一个物理划分，只是一个 Region 的一个属性。直观了解上，除了能治理的内存更大（G1 理论值 64G）之外，这样带来一个不言而喻的益处就是能够预管制一次 FullGC 的 STW 的工夫，因为 Region 大小统一，则能够依据进展工夫来推算这次 GC 须要回收的 Region 个数，而没有必要每次都将所有的 Region 全副清理结束。
随着这项技术的进一步倒退，到了现代化的 Pauseless(ZGC) 的算法场景中，有些算法临时没有了分代的概念，同时 Region 依照大小划分了 Small/Medium/Large 三个等级，更精密的 Region 治理，也进一步来更少的内存碎片和内存利用率的晋升、及其 STW 进展工夫更精准的预测与治理。
线程模型变动
说线程模型之前，先简略提一下 GC 线程与业务线程，GC 线程是指 JVM 专门用来解决 GC 相干工作的线程，这在 JVM 启动时就曾经决定。在传统的串行算法中，是指只有一个 GC 线程在工作。在并行 (Parallel) 的算法中，存在多个 GC 线程一起工作的状况（CMS 中 GC 线程个数默认是 CPU 的核数）。同时一些算法的某些阶段中(如：CMS 的并发标记阶段)，GC 线程也能够和业务线程一起工作；这个机制就缩短了整体 STW 的工夫，这也是咱们所说的并发(Concurrent) 模式。
在现代化的 GC 算法中，并不是所有和 GC 相干的工作都只能由 GC 线程实现，如 ZGC 中的 Remap 阶段，业务线程能够通过内存读屏障(Read Barrier)，来改正对象在此阶段因为被重新分配到新区域后的指针变动，进而进一步缩小 STW 的工夫。
收集行为变动
收集行为是指的在辨认出须要被收集的对象之后，JVM 对于对象和所在内存区域如何进行解决的行为。从晚期版本至今，大抵分为以下几个阶段：
- Mark Copy：是指间接将存活对象从原来的区域拷贝至另外一个区域。这是一种典型的空间换工夫的策略，益处不言而喻：算法简略、进展工夫短、且调参优化容易；但同时也带来了近乎一倍的空间闲置。在晚期的 GC 算法应用的是经典的分代模型。其中对于年老代 Survivor 区的收集行为便是这种策略。
- Mark Sweep：为了缩小空间成倍的节约，其中一个策略就是在原有的区域间接对对象 Mark 后进行擦除。但因为是在原来的内存区域间接进行对象的擦除，利用过程运行久了之后，会带来很多的内存碎片，其后果是内存持续增长，但实在利用率趋低。
- Mark Sweep-Compact: 这是对于 Mark Sweep 的一个改进行为，即擦除之后会对内存进行从新的压缩整顿，用以缩小碎片从而晋升内存利用率。然而如果每次都进行整顿，就会缩短每次 FullGC 后的 STW 工夫。所以 CMS 的策略是通过一个开关(-XX:+UseCMSCompactAtFullCollection 默认开) 和一个计数器(-XX:CMSFullGCsBeforeCompaction 默认值为 0) 进行管制，示意 FullGC 是否须要做压缩，以及在多少次 FullGC 之后再做压缩。这个两个配置配合业务状态去做调优能起到很好的成果。
- Mark Sweep-Compact-Free: JVM 的利用有一个“内存吞噬器”的恶名，起因之一就是在过程运行起来之后，他只会向操作系统要内存从来不会偿还 (典型只借不还的渣男)。不过这些在现代化的分区模型算法中开始有了改善，这些算法在 FullGC 之后，能够将整顿之后的内存以区域(Region) 为粒度归还给操作系统，从而升高这一个过程的资源水位，以此来晋升整个宿主机的资源利用率。
云原生相干的重点能力
对于云原生场景云原生的外在推动力之一是让咱们的业务工作负载最大化的利用云所带来的技术红利，云带来最大的技术红利就是通过弹性等相干技术，带来咱们资源的高效交付和利用，从而升高最终的经济老本。所以如何最大化的利用资源的弹性能力是很多技术产品所谋求的其中一个指标。
这一大节，咱们抽取了 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 内的内存对立看待进行随机调配和拜访。
既然 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 的内存不加区分的看待并进行调配，咱们的内存拜访性能势必会急剧上涨。如下图所示：
G1 算法通过 JEP 345 在 JDK 14 中失去了这一能力的反对，可通过参数 -XX:+UseNUMA 开启，开启之后，G1 会尽量将固定大小的各个 Region 均摊在所有能调配的 CPU Node 中，在调配新对象时，将优先应用同一 Node 内的“本地”内存的 Region，如果“本地”内存 Region 不够时，将对此 Region 触发一次 GC；如果还不够，再依照 CPU 的远近尽量获取相邻 Node 的 Region。此策略只针对 G1 中新生代的内存区域失效。老年代区域和大对象区域还是沿用默认的策略。
JEP 387: Elastic Metaspace
Metaspace 是用来存储 JVM 中类的元数据信息，包含类中的运行时数据结构、类中应用到的成员以及办法信息。他的前身是永恒代，也就是 PermGen。这一变动是 JDK 8 中重要的一个降级的能力之一。从 JEP 122 中提议并落地。这个 JEP 带来的具体的变动能够参考下图：
勾销了永恒代之后，带来两个变动如下：
- 只存储类元数据信息，即：a) Klass 信息，形容类的根底属性和类的继承关系等；b）NonKlass 信息，蕴含办法、外部类信息、成员变量定义等。
- 内存布局调整： 与之前在堆中开拓一块区域相比，Metaspace 是间接应用操作系统的本地内存进行调配，本地内存划分成多个 Chunk，以 ClassLoader 为维度进行调配和治理。
当一个 ClassLoader 加载一个对象时，所须要的空间从闲暇的 Chunk 中调配一个或多个固定大小的块，如未找到则向操作系统从新申请一个 Chunk。当某一个 ClassLoader 中所有的类都被卸载的时候，就能够将它所援用的内存块都归还给 Chunk。等到对应 Chunk 齐全处于“闲暇”状态的时候，这个 Chunk 也就就能够被操作系统回收。
看到这里咱们先暂停一下，思考两个问题：
- 合，而 JRockit 的设计中并没有永恒代。而从工夫上看，正好是产生在 Oracle 收买 Sun 之后。所以一个猜测就是这个变动的根因应该是组织推动大于技术驱动。当然从技术上这样带来的益处也很不言而喻：不再有负载的 Perm 设置；元空间和堆空间齐全隔离后，两边的 GC 不会相互影响；单次 FullGC 因为扫描区域更小而使得 STW 工夫更短；依照 Chunk 设计的构想，在类被卸载时，有助于 JVM 开释一些内存给操作系统等等。
- 有没有带来新问题？ 有，就是在一些应用程序中会呈现多品种频繁的 加载 / 卸载 的场景下，导致 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 章节一样，频繁的向操作系统 申请 / 偿还 只能带来更多的零碎开销，如何取舍是一门艺术。那么该如何抉择是否有操作伎俩呢？请先看上面这张图：
首先，零碎提供了一个额定的 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 秋季新推洽购流动，新客户头两月不限量应用，助力大家缩短转型过程中的门路。
