关于java:笔记追随云原生的Java

本文首发于泊浮目标掘金:https://juejin.cn/user/146860…

0. 前言

前阵子在 B 站刷到了周志明博士的视频，主题是云原生时代下 java，次要内容是云原生时代下的挑战与 Java 社区的对策。这个视频我在两年前看到过，过后也是印象粗浅。当初笔者也是想和大家一起看看相干我的项目的推动以及一些细节。这篇笔记会大量参考视频中提到的内容，如果读者看过相干视频，能够跳过这篇笔记。

视频分享中提到，Java 与云原生的矛盾大略起因有二：

首当其冲的是 Java 的“一次编写，到处运行”（Write Once,Run Anywhere）。在当年是十分好的做法，间接开启了许多托管语言的昌盛期。但云原生时代大家会抉择以隔离的形式，通过容器实现的不可变基础设施去解决。尽管容器的“一次构建，到处运行”（Build Once,Run Anywhere）和 Java 的“一次编写，到处运行”（Write Once,Run Anywhere）并不是一个 Level 的——容器只能提供环境兼容性和有局限的平台无关性（指零碎内核性能以上的 ABI 兼容），但服务端的利用都跑在 Linux 上，所以对于业务来说也无伤大雅。

其二，则是 Java 总体上是面向长时间的“巨塔式”服务端利用而设计的：

• 动态类型动静链接的语言构造，利于多人合作开发，让软件涉及更大规模；
• 即时编译器、性能制导优化、垃圾收集子系统等 Java 最具代表性的技术特色，都是为了便于长时间运行的程序能享受到硬件规模倒退的红利。

但在微服务时代是提倡服务围绕业务能力（不同的语言适宜不同的业务场景）而非技术来构建利用，不再谋求实现上的统一，一个零碎由不同语言、不同技术框架所实现的服务来组成是齐全正当的。服务化拆分后，很可能单个微服务不再须要再面对数十、数百 GB 乃至 TB 的内存。有了高可用的服务集群，也毋庸谋求单个服务要 7×24 小时不可间断地运行，它们随时能够中断和更新。不仅如此，微服务对镜像体积、内存耗费、启动速度，以及达到最高性能的工夫等方面提出了新的要求。这两年的网红概念 Serverless（以及衍生进去的 Faas）也进一步减少这些因素的思考权重，而这些却正好都是 Java 的弱项：哪怕再小的 Java 程序也要带着厚重的 Rumtime（Vm 和 StandLibrary）——基于 Java 虚拟机的执行机制，使得任何 Java 的程序都会有固定的内存开销与启动工夫，而且 Java 生态中宽泛采纳的依赖注入进一步将启动工夫拉长，使得容器的冷启动工夫很难缩短。

举两个例子。软件工业中曾经呈现过不止一起因 Java 这些弱点而导致失败的案例。如 JRuby 编写的 Logstash，本来是同时承当部署在节点上的收集端（Shipper）和专门转换解决的服务端（Master）的职责，起初因为资源占用的起因，被 Elstaic.co 用 Golang 的 Filebeat 代替了 Shipper 局部的职能。又如 Scala 语言编写的边车代理 Linkerd，作为服务网格概念的提出者，却最终被 Envoy 所取代，其次要弱点之一也是因为 Java 虚拟机的资源耗费所带来的劣势。

1. 改革之火

1.1 Complie Native Code

显然，如果将字节码间接编译成能够脱离 Java 虚拟机的原生代码则能够解决所有问题。

如果真的可能生成脱离 Java 虚拟机运行的原生程序，将意味着启动工夫长的问题可能彻底解决，因为此时曾经不存在初始化虚拟机和类加载的过程。也意味着程序马上就能达到最佳的性能，因为此时曾经不存在即时编译器运行时编译，所有代码都是在编译期编译和优化好的。同理，厚重的 Runtime 也不会呈现在镜像中。

Java 并非没有尝试走过这条路。从 GCJ 到 Excelsior JET 再到 GraalVM 中的 SubstrateVM 模块再到 2020 年中期建设的 Leyden 我的项目，都在朝着提前编译（Ahead-of-Time Compilation，AOT）生成原生程序这个指标迈进。Java 反对提前编译最大的艰难在于它是一门动静链接的语言，它假如程序的代码空间是凋谢的（Open World），容许在程序的任何时候通过类加载器去加载新的类，作为程序的一部分运行。要进行提前编译，就必须放弃这部分动态性，假如程序的代码空间是关闭的（Closed World），所有要运行的代码都必须在编译期全副可知。

这一点不仅仅影响到了类加载器的失常运作，除了无奈再动静加载外，反射（通过反射能够调用在编译期不可知的办法）、动静代理、字节码生成库（如 CGLib）等所有会运行时产生新代码的性能都不再可用——如果将这些根底能力间接抽离掉，Hello world 还是能跑起来，大部分的生产力工具都跑不起来，整个 Java 生态中绝大多数上层建筑都会轰然崩塌。轻易列两个 Case：Flink 的 SQL API 会解析 SQL 并生成执行打算，这个时候会通过 JavaCC 动静生成类加载到代码空间中去；Spring 也有相似的状况，当 AOP 通过动静代理的形式去生成相干逻辑时，实质还是在 Runtime 时生成代码并加载进去。

要取得有实用价值的提前编译能力，只有依附提前编译器、组件类库和开发者三方一起协同才可能办到——能够参考 Quarkus。

Quarkus 和咱们上述的办法一模一样，以 Dependency Inject 为例：所有要运行的代码都必须在编译期全副可知，在编译期就推导进去相干的 Bean，最初交给 GraalVM 来运行。

1.2 Memory Access Efficiency Improvement

Java 即时编译器的优化成果拔群，然而因为 Java“所有皆为对象”的前提假如，导致它在解决一系列不同类型的小对象时，内存拜访性能很差。这点是 Java 在游戏、图形处理等畛域始终难有建树的重要制约因素，也是 Java 建设 Valhalla 我的项目的指标初衷。

这里举个例子来阐明此问题，如果我想形容空间外面若干条线段的汇合，在 Java 中定义的代码会是这样的：

public record Point(float x, float y, float z) {}
public record Line(Point start, Point end) {}
Line[] lines;

面向对象的内存布局中，对象标识符（Object Identity）存在的目标是为了容许在不裸露对象构造的前提下，仍然能够援用其属性与行为，这是面向对象编程中多态性的根底。在 Java 中堆内存调配和回收、空值判断、援用比拟、同步锁等一系列性能都会波及到对象标识符，内存拜访也是依附对象标识符来进行 链式解决 的，譬如下面代码中的“若干条线段的汇合”，在堆内存中将形成如下图的援用关系：

计算机硬件通过 25 年的倒退，内存与处理器尽管都在提高，然而内存提早与处理器执行性能之间的冯诺依曼瓶颈（Von Neumann Bottleneck）不仅没有缩减，反而还在继续加大，“RAM Is the New Disk”曾经从讥嘲梗逐步成为了事实。

一次内存拜访（将主内存数据调入处理器 Cache）大概须要消耗数百个时钟周期，而大部分简略指令的执行只须要一个时钟周期而已。因而，在程序执行性能这个问题上，如果编译器能缩小一次内存拜访，可能比优化掉几十、几百条其余指令都来得更有成果。

额定常识：冯诺依曼瓶颈
不同处理器（古代处理器都集成了内存管理器，以前是在北桥芯片中）的内存提早大略是 40-80 纳秒（ns，十亿分之一秒），而依据不同的时钟频率，一个时钟周期大略在 0.2-0.4 纳秒之间，如此短暂的工夫内，即便真空中流传的光，也仅仅可能前进 10 厘米左右。

数据存储与处理器执行的速度矛盾是冯诺依曼架构的次要局限性之一，1977 年的图灵奖得主 John Backus 提出了“冯诺依曼瓶颈”这个概念，专门用来形容这种局限性。

Java 编译器确实在致力缩小内存拜访，从 JDK 6 起，HotSpot 的即时编译器就尝试通过逃逸剖析来做标量替换（Scalar Replacement）和栈上调配（Stack Allocations）优化，基本原理是如果能通过剖析，得悉一个对象不会传递到办法之外，那就不须要实在地在对象中创立残缺的对象布局，齐全能够绕过对象标识符，将它拆散为根本的原生数据类型来创立，甚至是间接在栈内存中调配空间（HotSpot 并没有这样做），办法执行结束后随着栈帧一起销毁掉。

不过，逃逸剖析是一种 过程间优化（Interprocedural Optimization），十分耗时，也很难解决那些实践上有可能但理论不存在的状况。这意味着它是 Runtime 时产生的。而雷同的问题在 C、C++ 中却并不存在，下面场景中，程序员只有将 Point 和 Line 都定义为 struct 即可，C# 中也有 struct，是依附 .NET 的值类型（Value Type）来实现的。这些语言在编译期就解决了这些问题。

而 Valhalla 的指标就是提供相似的值类型反对，提供一个新的关键字（inline），让用户能够在不须要向办法内部裸露对象、不须要多态性反对、不须要将对象用作同步锁的场合中，将类标识为值类型。此时编译器就可能绕过对象标识符，以平坦的、紧凑的形式去为对象分配内存。

Valhalla 目前还处于 Preview 阶段。能够在这里看到推动的状况。心愿能在下个 LTS 版本正式用上它吧。

1.3 Coroutine

Java 语言形象进去暗藏了各种操作系统线程差异性的对立线程接口，这已经是它区别于其余编程语言的一大劣势。不过，这也是已经。

Java 目前支流的线程模型是间接映射到操作系统内核上的 1:1 模型，这对于计算密集型工作这很适合，既不必本人去做调度，也利于一条线程跑满整个处理器外围。但对于 I/O 密集型工作，譬如拜访磁盘、拜访数据库占次要工夫的工作，这种模型就显得老本昂扬，次要在于内存耗费和上下文切换上。

举个例子。64 位 Linux 上 HotSpot 的线程栈容量默认是 1MB，线程的内核元数据（Kernel Metadata）还要额定耗费 2-16KB 内存，所以单个虚拟机的最大线程数量个别只会设置到 200 至 400 条，当程序员把数以百万计的申请往线程池外面灌时，零碎即使能解决得过去，其中的切换损耗也相当可观。

Loom 我的项目的指标是让 Java 反对 额定 的 N:M 线程模型，而不是像当年从绿色线程过渡到内核线程那样的间接替换，也不是像 Solaris 平台的 HotSpot 虚拟机那样通过参数让用户二选其一。

Loom 要做的是一种有栈协程（Stackful Coroutine），多条虚构线程能够映射到同一条物理线程之中，在用户空间中自行调度，每条虚构线程的栈容量也可由用户自行决定。此外，还有两个重点：

• 尽量兼容所有原接口。这意味着原来所有的线程接口都能够当作协程应用。但我感觉挺难的——如果外面的代码调到 Native 办法，这个 Stack 就和这个线程绑定了，毕竟 Coroutine 是个用户态的货色。
• 反对结构化并发：简略来说就是异步的代码写起来像同步的代码，这点 Go 做的很好。毕竟嵌套的回调函数着实让人苦楚。

上述的内容如果拆开来细说，根本就是：

• 协程的调度；
• 协程的同步、互斥与通信；
• 协程的零碎调用包装，尤其是网络 IO 申请的包装；
• 协程堆栈的自适应。

小常识：每个协程，都有一个本人专享的协程栈。这种须要一个辅助的栈来运行协程的机制，叫做 Stackful Coroutine；而在主栈上运行协程的机制，叫做 Stackless Coroutine。

Stackless Coroutine 意味着：

• 运行时：流动记录放在主线程的栈上
• 暂停时：堆中保留流动记录
• 能够调用其余函数
• 只能在顶层暂停运行，不能够在子函数 / 子协程里暂停

而 Stackfull Coroutine 意味着：

• 运行时：独自的运行栈
• 能够在调用栈的任何一级暂停
• 生命周期能够超过它的创建者
• 能够从一线程上跑到另一个线程上

因而，一个齐备的协程库根本顶得上一个操作系统里的过程局部了。只是它在用户态，过程在内核态。

这个我的项目能够在这里看到。目测 JDK19 就能够尝尝鲜了。

2. 小结

目前在云原生畛域，Java 可能未必是好的抉择——在这个畛域最让人难以忍受的就是其宏大的 Runtime 以及较长的 Startup 工夫，在以前这是 Java 长处的起源，但到了云原生时代，则成了 Java 不言而喻弱点。因而 Java 想在云原生时代持续放弃前几十年的趋势，解决这个问题火烧眉毛。从这个点来看，我很看好 Quarkus。

Valhalla 带来的优化很多场景都能够用上，一些长时间运行利用也能够取得更多的性能收益。

而协程针对的是 IO 密集型场景，自身也能够通过 NIO、AIO 形式来防止线程的大量耗费。因而 Loom 在笔者看来更像是精益求精的事。