你将学到：
Java 虚拟机如何决定编译内容及时机 · C1 与 C2 之间的真正区别 · 什么是代码缓存以及它为何可能拖垮你的性能 · GraalVM：即时编译对比原生镜像 · Leyden 项目：Java 25 如何彻底解决预热问题
目录
-
1. 原始问题
- 每位 Java 开发者都经历过的场景
- 方法对比
-
2. 即时编译
- Java 虚拟机中方法的完整处理流程
- 可视化流程图
- 为何编译过程不会阻塞应用程序
- 去优化——课程中未提及的内容
-
3. 两款编译器：C1 与 C2
- C2 能应用而 C1 无法实现的优化
-
4. 代码缓存
- 各版本的默认大小
- 生产环境中最令人担忧的警告
- 用于诊断和调优的关键标志参数
- 关于编译阈值的重要细节
-
5. GraalVM
- 5.1 Graal 即时编译器 —— C2 的替代品
- 5.2 原生镜像 —— 完全提前编译
- 对比：传统即时编译与 GraalVM 原生镜像
- 为何原生镜像的峰值性能较低
-
6. Leyden 项目
- 工作原理 —— 两步走
- Leyden 相关增强提案的时间线
- 最终对比：三个世界
-
7. 何时不再担心预热问题
- 直接回答：Java 25 及以上版本
- Kubernetes 的实际应用场景
-
8. 时间线与执行摘要
- Java 虚拟机性能的完整演进
- 执行摘要 —— 快速参考
-
9. 使用 GraalVM 与不使用 GraalVM —— 基于真实数据的分析
- 数据揭示的生产环境采用情况
- 场景 1 —— 不使用 GraalVM：纯 HotSpot 即时编译
- 场景 2 —— GraalVM 即时编译模式
- 场景 3 —— GraalVM 原生镜像
- 快速决策指南
- 参考文献
第一节 —— 原始问题
为何 Java 曾经缓慢，以及它是如何解决这一问题的
每位 Java 开发者都经历过的场景
💡 你在应用程序刚启动时测量某个方法的性能：200 毫秒。
30 秒后再次测量：8 毫秒。
发生了什么？应用程序正在“预热”。
这种现象有名称、有机制，并且从 Java 25 开始，有了最终的解决方案。
Java 将源代码（.java）编译为字节码（.class）——一种平台无关的中间格式。Java 虚拟机在任何机器上解释执行该字节码。这就是著名的一次编写，到处运行。
代价是：逐条指令解释执行速度很慢。1996 年，Java 的运行速度比 C 语言慢 10 到 20 倍。
方法对比
| 方法 | 可移植性 | 性能 | 示例 |
|---|---|---|---|
| 原生编译 | ❌ 每个操作系统对应一个二进制文件 | ⭐⭐⭐⭐⭐ 最高 | C / C++ |
| 纯解释执行 | ✅ 通用字节码 | ⭐ 低 | Java 1.0 (1996) |
| 即时编译 —— 混合模式 | ✅ 通用字节码 | ⭐⭐⭐⭐⭐ 高 | Java 1.3+ (2000) |
| 提前编译缓存 (Leyden) | ✅ 通用字节码 | ⭐⭐⭐⭐⭐ 高 + 快速启动 | Java 24+ (2024) |
💬 催生即时编译技术的问题：如果 Java 虚拟机能够在运行时学习哪些部分值得编译为原生代码——而不必打
免责声明：本文内容来自互联网，该文观点不代表本站观点。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容，请到页面底部单击反馈，一经查实，本站将立刻删除。
