我一直在研究解释器的精确工作方式，已经在谷歌上搜索了相关信息并得出了一些结论，只是希望有人能够更好地理解解释器的工作方式，并纠正我的理解。
我现在的理解是：
现在我仍然不清楚中间发生的子过程，即：
还有一些问题：
cc -O3的即时编译。1) 解释器是一种软件程序，将高级语言的代码转换为机器格式。
不正确。解释器是一种运行以某种语言表达的程序的程序，该程序不是计算机的本机机器代码。
在这个过程中，可能存在一步将源语言解析并翻译为中间语言的过程，但这不是解释器的基本要求。在Java的情况下，字节码语言已被设计为不需要解析或独立的中间语言。
2) 具体来说，关于java解释器，它会获得二进制格式的代码（该代码早先由java编译器从源代码转换为字节码）。
正确的。 "二进制格式" 是Java字节码。
3) 现在，java解释器的平台是JVM，在JVM中运行，所以基本上它会产生可以由JVM运行的代码。
不正确。字节码解释器是JVM的一部分。解释器不在JVM上运行。并且字节码解释器不生成任何内容。它只是运行字节码。
4) 因此，它获取字节码生成中间代码和目标机器代码，并将其提供给JVM。
不正确。
5) JVM转��在JVM实现或运行的操作系统平台上执行该代码。
不正确。
真正的故事是这样的：
1-典型的字节码解释器会做一些工作，将抽象堆栈帧和对象布局映射到涉及特定目标大小和偏移量的具体堆栈帧和对象布局中。但是将其称为"中间代码"是一种拉伸。解释器实际上只是增强了字节码。
Java应用程序有两个主要步骤：编译和运行时。每个过程都有非常不同的功能和目的。以下是它们的主要过程：
[com.sun.tools.javac][1]执行，通常可以在tools.jar文件中找到，传统上位于$JAVA_HOME - 与java.jar等相同的位置。编译步骤：
[com.sun.tools.JCTree][3]。总体思路是每个表达式和语句都有一个Java对象来表示。在这个时候，关于实际“类型”的了解还很少。在AST创建时唯一检查的是字面语法。根据我创建DSL的经验，我来回答这个问题。
C是编译型语言，因为你需要将源代码传递给gcc并运行存储在机器码中的程序。
Python是解释型语言，因为你需要通过将程序源代码传递给解释器来运行程序。解释器读取源文件并执行它。
Java是两者的混合，因为你需要将Java文件“编译”成字节码，然后调用JVM来运行它。字节码不是机器码，需要由JVM解释。Java处于C和Python之间的一个级别，因为你不能像Python那样做一些花哨的事情，比如“eval”（在运行时评估代码块或表达式）。但是，Java具有C程序无法实现的反射能力。简而言之，Java运行时设计处于纯编译语言和解释语言之间的中间层，以性能和灵活性方面提供了最佳（也是最差）的两种语言特点。
然而，Python也有自己的虚拟机和字节码格式。Perl、Lua等语言的解释器也是如此。这些解释器首先将源文件转换为字节码，然后再解释字节码。
我一直想知道为什么要这样做，直到我为一个模拟DSL创建了自己的解释器。我的解释器进行词法分析（将源代码分解为标记），将其转换为抽象语法树，然后通过遍历该树来评估它。出于软件工程的考虑，我使用了一些设计模式，并且我的代码大量使用多态性。与处理类似于实际计算机体系结构的高效字节码格式相比，这非常慢。例如，对于评估长数字表达式，将其转换为类似于汇编代码的东西要比处理抽象树的分支快得多，因为它需要调用许多多态方法。
.c）解析成机器代码，在Windows上为.exe。然后可以独立于编译器执行。.c文件编译为多个对象文件（中间产品），然后将它们链接到单个应用程序或库中来完成。.java）并“立即”执行程序。javac将.java编译为.class文件，并将其压缩为.jar（或.war、.ear等）。.class文件包含更抽象的字节码，适用于抽象堆栈机器。编译器 只是创建代码;
- 解释器 立即执行。