问Java“虚拟机”与Python“解释器”的说法？

EN

虚拟机是一个虚拟计算环境，它具有一组特定的原子定义良好的指令，这些指令独立于任何特定的语言而被支持，并且通常被认为是其自身的沙箱。VM类似于特定CPU的指令集，并且倾向于在更基本的级别上工作，这些指令(或字节码)的非常基本的构建块独立于下一个。指令仅基于虚拟机的当前状态来确定性地执行，并且不依赖于在该时间点的指令流中的其他信息。

另一方面，解释器更复杂，因为它被定制为解析特定语言和特定语法的某些语法流，这些语法流必须在周围标记的上下文中解码。您不能孤立地查看每一个字节，甚至每一行，并且确切地知道下一步要做什么。语言中的标记不能像相对于VM的指令(字节码)那样孤立地使用。

Java编译器将Java语言转换为字节码流，就像C编译器将C语言程序转换为汇编代码一样。另一方面，解释器并不真正将程序转换为任何定义良好的中间形式，它只是将程序操作视为解释源代码的过程。

VM和解释器之间的区别的另一个测试是您是否认为它是独立于语言的。我们所知道的Java VM实际上并不是Java特有的。您可以从其他语言生成可在JVM上运行的字节码的编译器。另一方面，我不认为我们真的会考虑将Python之外的其他语言“编译”成Python以供Python解释器解释。

由于解释过程的复杂性，这可能是相对较慢的process....specifically解析和识别语言标记等，并且理解源的上下文以便能够在解释器内进行执行过程。为了帮助加速这样的解释型语言，我们可以在这里定义更容易直接解释的预解析、预标记化源代码的中间形式。这种二进制形式在执行时仍然会被解释，它只是从一种人类可读的形式开始，以提高性能。然而，执行这种形式的逻辑不是虚拟机，因为这些代码仍然不能被孤立地处理-周围令牌的上下文仍然很重要，它们现在只是以一种不同的、更有效的计算机形式。

可能出现不同术语的原因之一是，人们通常会考虑向python解释器提供原始的、人类可读的源代码，而不是担心字节码之类的问题。

在Java中，您必须显式地编译成字节码，然后在VM上只运行字节码，而不运行源代码。

尽管Python在幕后使用虚拟机，但从用户的角度来看，大多数时候可以忽略这一细节。

术语解释器是一个遗留下来的术语，可以追溯到早期的shell脚本语言。随着“脚本语言”演变成功能齐全的语言，以及它们对应的平台变得更加复杂和沙箱，虚拟机和解释器(在Python意义上)之间的区别变得非常小或根本不存在。

Python解释器仍然以与shell脚本相同的方式工作，在这个意义上，它可以在没有单独的编译步骤的情况下执行。除此之外，Python的解释器(或Perl或Ruby)与Java的虚拟机之间的差异主要是实现细节。(有人可能会争辩说，Java比Python更完整的沙箱，但两者最终都通过本机C接口提供对底层体系结构的访问。)