Java 编译器编译成二进制，就像gcc 编译 C 代码？或者它只是编译成另一种将被另一事物解释的“语言”？
我无法运行它。应该是JVM吧？
那么，Java 实际上不是一种真正的编译语言，是解释型的吗？
只是为了澄清一个问题。
【问题讨论】：
标签： java gcc compiler-construction jvm
Java 实际上并不是真正的编译语言，是解释型的吗？
嗯……
Java 被编译。但不是机器码，而是编译为字节码。 JVM 可以解释的。或者，它可以反过来将其进一步编译为机器代码。这实际上发生在所谓的 Hotspot Just-In-Time 编译器中（至少对于部分代码而言），它是标准 JVM 的一部分。
它与 Perl 或 Python 等“真正的”解释型语言（即使它们也“编译”为内部表示）的不同之处在于，您发布的代码不再需要编译器来运行，只需运行。另一方面，Perl 和 Python 需要能够在运行时“评估”新程序。
【讨论】：
Java 是两者的混合体。 Java 代码被编译成 Java-Bytecode（它是一种中间语言并且独立于体系结构）。 它将在运行时编译成机器代码（就像编译 C 时生成的代码）。据我所知，Java 运行时也在运行时做了一些优化。
Java 最初是一种解释性语言，但仍然存在 JVM 使用解释器来执行字节码的情况。
查看此 fopr 更多信息：http://searchsoa.techtarget.com/definition/Java-virtual-machine
【讨论】：
Java 介于编译语言和解释语言之间。
在编译 Java 程序时，Java 源代码被翻译成平台无关的字节码。这个字节码既不是人类可读的（它非常类似于汇编程序），也不是大多数 CPU 可读的。
当编译的程序运行时，这个字节码被 Java 虚拟机解释并翻译成 JVM 运行平台的本地指令。
在性能方面，这种方法相对于编译为本地机器码既有缺点也有优点。
一个缺点是翻译成机器代码需要时间。它必须在应用程序首次执行时（导致启动时间变慢）或在执行时（导致运行时性能降低）完成。
但另一方面，运行时编译允许针对软件实际运行的平台优化生成的机器代码，而预编译软件通常针对特定 CPU 进行优化。运行时编译还允许即时优化。虽然普通编译器需要猜测程序的哪些部分最常执行，但 JIT 优化器可以在程序实际执行时对其进行观察，并使用此信息来更改程序以提高运行效率。
【讨论】：
希望对你有帮助
java 编译器的工作方式
【讨论】：
或者它只是编译成另一种类型的“语言” 被别的东西解释了？
所有编译语言就是这种情况——它们被编译成另一种语言，可以被某些东西解释——比如真机的处理器或模拟虚拟机的程序。 p>
【讨论】：
ADD A, B 这样的指令是描述晶体管级别发生的事情的一种非常高级的方式。至于“重大开销” - 相对于 what?
Java 在某种意义上既是解释型的又是编译型的，因为它必须被编译成一个独立于平台的 JAR 文件才能在主机 JVM 上执行。编译器将其转换为 Java 字节码，这是一组独立于平台的指令，类似于（但不是）主机 CPU 能够直接运行的机器语言。
当 Java 程序在 JVM 上执行时，第一遍编译的字节码在第一遍被解释器解释，之后它被输入到一个简写为 C1 的分析即时编译器，它实际上将代码编译成机器特定的语言，当 JVM 感觉像这样时，由 C1 编译和分析的代码然后被反编译回 Java 字节码，并馈送到称为 C2 的极其积极的优化 JIT 编译器。这是 Java 程序如何运行的一般要点，大多数情况下解释器根本不用于执行代码，因为运行时中的 C1 和 C2 编译并执行大部分代码以提供可能的最佳性能，所以从技术上讲，你可以说 Java 不是解释器——因为你编写的代码几乎都没有在解释器中结束
还有一件有趣的事情要注意，Java 的解释器不是标准的解释器，而是一种称为模板解释器的特殊解释器。我在一篇小文章中描述起来太复杂了，但本质上这意味着Java运行时中的“解释器”实际上是一个伪装成解释器的编译器。
【讨论】：