Java虚拟机可以进行编译吗_Java能不能像C语言不通过JVM虚拟机直接编译成二进制机器码，让计算机直接运行？...

好像我回答过一亿个一样的问题了，但每次看到这种问题就想回复，我就再写一次毫无营养的回答吧……

首先回答问题，直接编译成机器码当然可行，以前有 GCJ、ExcelsiorJET，现在有 GraalVM 的 native-image，都能达成这个目的。我成功为我的 JavaFX 应用生成了 native-image：https://zhuanlan.zhihu.com/p/103606559​zhuanlan.zhihu.com

C 语言运行在虚拟机上也当然可行，编译成 LLVM IR 就能在 GraalVM 上运行，还能调用 Java、JS、Python 等其他语言：C 程序运行在 GraalVM 之上，并调用 GraalPython 执行 Python 代码

至于题目描述中的问题，事实上 Java 运行并不缓慢，现代 JVM 采用了 JIT 机制，运行时会将字节码编译为机器码，传统的解释运行只用于调用次数较少的非热点代码。JIT 编译相比在编译期就编译成机器码的 AOT 编译来说，一方面方便实现一次编译到处运行，一方面编译时能掌握更多程序相关信息便于优化，而且还能做一些激进的假设，不满足时再回退优化，这些都是 JIT 的优点。

当然，AOT 也有自己的优势。虽然 JIT 理论上能够利用掌握的运行时信息做更好的优化，使编译后的峰值性能超过 AOT 编译，但 AOT 编译也能使用 PGO 技术掌握一部分运行时的信息，也敢于做一些高开销的优化不用担心影响程序运行。至于 Java 这边折腾的 AOT 编译，虽然一般来说峰值性能比起正常用 JVM 运行还会更差，但是大大提高了启动速度，降低了内存等资源占用，而且能够单文件分发不依赖 JRE，这些都是 AOT 的优势。

话说回来，Java 的性能虽然不差，但相比 C++ 等语言一般还是有差距，不过这锅不能甩到 JVM 头上，这是有很多方面的原因的：安全性上，Java 默认会产生更多检测(譬如数组越界检测，还有 SecurityManager 相关的一套机制等等)，这些检测带来了不小的开销。

Java 有反射和 ClassLoader 等机制，带来了一定的动态性，这部分动态性会妨碍编译器优化。

Java 虚函数使用率很高，即使 JVM 在虚函数优化上做了很多工作，依然会带来很多不可避免地开销。

JNI 设计的很糟糕，开销也很大，影响了与本机代码交互时的性能。(Project Panama 在试图改进这方面)。

泛型不支持基本类型，经常会导致产生很多不必要的装箱拆箱操作影响性能。

不支持自定义值类型，额外占用不少内存，对缓存也不友好，对栈空间也难以利用，引用的解引用也损耗性能。(Project Valhalla 在改善这一条和上一条问题)。

GC。GC 性能影响倒不是关键，关键在不可控的 STW 对很多应用不友好。OpenJDK 新引入的 ZGC 和 Shenandoah GC 基本解决了暂停时间的问题，但是带来的吞吐量下降也是棘手的问题。

对象内存模型问题。Java 对象的对象头额外占用了不少内存空间，对于缓存不友好。

JIT 需要预热，导致 Java 应用的启动速度会慢，启动后的一段时间性能也会略差。

往往用 C++ 实现应用时会投入更多精力优化，而用 Java 实现虽然更快，但开发者往往不会把省下的精力花在优化上。

…………