A virtual machine is a virtual computing environment with a specific set of atomic well defined instructions that are supported independent of any specific language and it is generally thought of as a sandbox unto itself. The VM is analogous to an instruction set of a specific CPU and tends to work at a more fundamental level with very basic building blocks of such instructions (or byte codes) that are independent of the next. An instruction executes deterministically based only on the current state of the virtual machine and does not depend on information elsewhere in the instruction stream at that point in time.

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

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

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

Because of the sophistication of the interpretation process, this can be a relatively slow process....specifically parsing and identifying the language tokens, etc. and understanding the context of the source to be able to undertake the execution process within the interpreter. To help accelerate such interpreted languages, this is where we can define intermediate forms of pre-parsed, pre-tokenized source code that is more readily directly interpreted. This sort of binary form is still interpreted at execution time, it is just starting from a much less human readable form to improve performance. However, the logic executing that form is not a virtual machine, because those codes still can't be taken in isolation - the context of the surrounding tokens still matter, they are just now in a different more computer efficient form.

解释器，翻译源代码为一些有效的中间表示(代码)，并立即执行。

虚拟机，显式地执行存储的预编译代码，由编译器构建，它是解释器系统的一部分。

虚拟机的一个非常重要的特征是，在虚拟机内部运行的软件，受限于虚拟机提供的资源。确切地说，它无法跳出它的虚拟世界。想想远程代码的安全执行，Java applet。

在python的情况下，如果我们保留pyc文件，就像这篇文章的评论中提到的，那么这个机制将变得更像一个虚拟机，并且这个字节码执行得更快——它仍然会被解释，但从一个更计算机友好的形式。如果我们从整体上看，PVM是Python解释器的最后一步。

底线是，当我们提到Python解释器时，这意味着我们将其作为一个整体来引用，而当我们说PVM时，这意味着我们只是在谈论Python解释器的一部分，一个运行时环境。类似于Java，我们引用不同的部分，JRE, JVM, JDK等。

有关更多信息，请参阅维基百科条目:解释器和虚拟机。这里还有一个。在这里您可以找到应用程序虚拟机的比较。它有助于理解编译器，解释器和vm之间的区别。

Python可以解释代码，而无需将其编译为字节码。Java不能。

Python是一种解释型语言，而不是编译型语言，尽管由于字节码编译器的存在，两者的区别可能很模糊。这意味着源文件可以直接运行，而无需显式地创建一个可执行文件，然后再运行。

(来自文档)。

在java中，每个文件都必须编译为.class文件，然后在JVM上运行。相反，python会通过主脚本导入这些文件，以帮助加快后续使用这些文件的速度。

然而，在典型的情况下，大多数python(至少是CPython)代码运行在模拟的堆栈机器中，它与JVM的指令几乎相同，因此没有太大的区别。

然而，这种区别的真正原因是，从一开始，java就把自己打上了“可移植的、可执行的字节码”的标签，而python则把自己打上了带有REPL的动态解释语言的标签。名字贴!

首先，你应该明白，编程或计算机科学一般不是数学，我们经常使用的大多数术语都没有严格的定义。

现在回答你的问题:

什么是解释器(计算机科学)

它按最小的可执行单元翻译源代码，然后执行该单元。

什么是虚拟机

对于JVM来说，虚拟机是一个包含解释器、类加载器、垃圾收集器、线程调度器、JIT编译器和许多其他东西的软件。

正如你所看到的，解释器是JVM的一部分，整个JVM不能被称为解释器，因为它包含许多其他组件。

为什么在谈论python时要用“解释器”这个词

在Java中，编译部分是显式的。 另一方面，Python的编译和解释过程不像Java那样明确，从最终用户的角度来看，解释是用于执行Python程序的唯一机制

for posts that mention that python does not need to generate byte code, I'm not sure that's true. it seems that all callables in Python must have a .__code__.co_code attribute which contains the byte code. I don't see a meaningful reason to call python "not compiled" just because the compiled artifacts may not be saved; and often aren't saved by design in Python, for example all comprehension compile new bytecode for it's input, this is the reason comprehension variable scope is not consistent between compile(mode='exec, ...) and compile compile(mode='single', ...) such as between running a python script and using pdb

HotSpot运行时被称为虚拟机，而CPython仅仅被称为解释器，这可能是有原因的

首先，CPython只是普通的、基于栈的字节码解释器。你向它输入Python操作码，CPython内部的软件堆栈机器就会计算你的代码，就像普通的解释器一样。

The Java HotSpot runtime is different. First and foremost, Java has 3 Just-in Time Compilers, C1, C2, and an experimental one that isn't in use yet. But that's not the main reason. The Interpreter inside the JVM is a very special kind of Interpreter called a Template Interpreter. Instead of just executing bytecode directly in a massive opcode switch case statement like CPython (And really almost every other interpreter does) does, the Template Interpreter inside the JVM contains an enormous arraylist. What does it contain? Key-value pairs of bytecodes and native CPU instructions! The arraylist is empty on startup and is filled with mappings of bytecodes pointing to native machine language to be directly run on the hardware just before your application starts up, what this means is that the "Interpreter" inside the JVM isn't actually an Interpreter at all- It's actually a discount Compiler! When Java bytecode is run, the "Interpreter" simply maps the input bytecode directly to native machine language and executes the native mapping directly, rather than implementing it in software. I'm not exactly sure why the JVM was made this way, but I suspect it was to easily execute "Interpreted" Code together with JIT Compiled Code seamlessly, and for speed/performance. If you pitted the JVM without JIT against CPython or most other interpreters it would still probably come out ahead of them, in virtue of its ingenious design which to my knowledge no other language has used before.