本文探讨了Java在云原生时代的挑战，包括启动时间长、内存效率低下以及传统线程模型的问题。文章提到了Complie Native Code（AOT编译）以解决启动和性能问题，Memory Access Efficiency Improvement通过Valhalla项目改进内存访问效率，以及Coroutine（协程）来优化I/O密集型任务。Quarkus、Loom和Valhalla项目成为Java应对云原生挑战的关键，并有望在未来的Java版本中提供实质性改进。
| 版本 | 日期 | 备注 |
|---|---|---|
| 1.0 | 2022.7.4 | 文章首发 |
| 1.1 | 2022.7.4 | 根据反馈修改内容与标题 |
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 的程序都会有固定的内存开销与启动时间，而且
最低0.47元/天 解锁文章
扫一扫
211
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
