AOT 去年发布的 .NET 7 中引入了该功能，只是在 .NET 8 中进一步进行了改进。新版本中通过 Native AOT 发布的“Hello, World”应用程序体积进一步缩小，只有 .NET 7 的一半。
以 CoreCLR 为例，不做 AOT 编译的 asp.net core 网站项目，通常冷启动时间需要 150ms左右，但是启动后随着程序运行，JIT 再次生成更优的代码，甚至会为频繁使用的泛型类特化出一套实现；而经过 ReadyToRun 技术编译初始化部分，可以既保留 JIT，同时将程序初始化的部分采用 AOT 技术加速，将启动时间减少到 80ms 左右；最后是纯 AOT，采用CoreRT 编译后，启动速度可以直接达到 10ms 以下。
AWS 的 FaaS 服务中，.NET Core 的函数计算服务利用 ReadyToRun/CoreRT 等技术，使得其启动速度成为冠军。
不过 .NET Core 内存占用本身就非常小，进行 AOT 编译带来的内存占用优势几乎可以忽略不计，然而 Full AOT 却使得很多高级特性无法实现，例如表达式树动态生成 IL 等。对于 .NET Core 来说，AOT 相对于 JIT 的优势，除了可以得到更小的程序之外，并不明显。
至于 Java/JVM，AOT 技术肯定也是有的，其相对原 JIT 方案，我觉得无论是启动速度还是内存占用上最应该都能有相当大的改善，因为现在的 Java 启动速度和内存占用实在是不忍直视。
JIT
JIT，即Just-in-time,动态(即时)编译，边运行边编译；
优
- 可以根据当前硬件情况实时编译生成最优机器指令（ps. AOT也可以做到，在用户使用是使用字节码根据机器情况在做一次编译）
- 可以根据当前程序的运行情况生成最优的机器指令序列
- 当程序需要支持动态链接时，只能使用JIT
- 可以根据进程中内存的实际情况调整代码，使内存能够更充分的利用
吞吐量高，有运行时性能加成，可以跑得更快，并可以做到动态生成代码
劣
- 编译需要占用运行时资源，会导致进程卡顿
- 由于编译时间需要占用运行时间，对于某些代码的编译优化不能完全支持，需要在程序流畅和编译时间之间做权衡
- 在编译准备和识别频繁使用的方法需要占用时间，使得初始编译不能达到最高性能
相对启动速度较慢，并需要一定时间和调用频率才能触发 JIT 的分层机制
AOT
AOT，Ahead Of Time，指运行前编译
优
- 在程序运行前编译，可以避免在运行时的编译性能消耗和内存消耗
- 可以在程序运行初期就达到最高性能
- 可以显著的加快程序的启动
内存占用低，启动速度快，可以无需 runtime 运行，直接将 runtime 静态链接至最终的程序中
劣
- 在程序运行前编译会使程序安装的时间增加
- 牺牲Java的一致性
- 将提前编译的内容保存会占用更多的内存
无运行时性能加成，不能根据程序运行情况做进一步的优化
二者区别
这两种编译方式的主要区别在于是否在“运行时”进行编译