问CLR是虚拟机吗？

EN

这里有很多误解。如果您真的想要的话，我想您可以将.Net看作一个虚拟机，但是让我们看看.Net框架是如何真正处理您的代码的。典型的场景如下

1. 您用C#、VB.Net、F#或其他兼容语言编写.Net程序。代码被编译成中间语言(IL)，类似于Java的字节码，分发给终端用户机器。终端用户
2. 第一次在安装了.Net正确版本的
3. 的计算机上调用该程序。计算机认为这是一个.Net程序集，而不是“原始”机器代码。并将其传递给JIT编译器execution.
4. The
5. JIT编译器将IL编译成完全本机代码。
6. 本机代码保存在内存中保存此程序的生命，调用保存的本机代码，IL不再重要。

。

这里有几个要点，但最重要的一点是，从来没有任何代码被解释过。相反，您可以在步骤5中看到它被编译成本机代码。这与将其加载到虚拟机中有很大的不同，原因如下：

完全编译的代码由cpu直接执行，而不是由额外的软件抽象层解释或翻译，这应该更快。JIT编译器denominator.

• If

• 可以利用特定于运行程序的单个计算机的优化，而不是满足您想要的最低通用的

• ，您甚至可以预编译代码，并且实际上可以将步骤5完全隐藏在用户面前。

我想您可以把这称为虚拟机，从某种意义上说，JITter从开发人员那里抽象出真正机器的细节。就我个人而言，我认为这是不对的，因为对于许多人来说，虚拟机意味着一个运行时抽象，而不是针对.Net程序的本机代码。

与“虚拟机”环境不同的是，整个过程的另一个关键点是，它只是典型的过程。如果您真的愿意，您可以在发布之前预编译一个.Net程序集，并将本机代码直接部署到最终用户(提示:在整个程序的生命周期中，它的聚合速度较慢，因为您失去了特定于机器的优化)。当然，您仍然需要安装.Net运行时，但在这一点上，它与任何其他运行时API并没有太大的不同；它更像是一个具有良好API链接的集合dll，就像附带的VB或C运行时一样。这种方式将IL从图片中剔除，使得VM名称更难被证明是正确的。(我说的“有点”是因为IL仍然被部署并用于验证保存的代码，但它本身从未为执行而被触及)。

另一个值得注意的问题是缺乏VM进程。当您运行您的应用程序，没有普通的“沙箱”进程运行。与Java相比，如果在运行程序时打开任务管理器，您将看到一个专门针对Java的进程，而应用程序的实际进程是VM创建的沙箱中的一个线程。在.Net中，您可以直接在Windows任务管理器中看到应用程序的进程。

总之:您可以说IL + CLR + JIT以某种方式组成了一个虚拟机。我个人不这么认为，但如果你相信的话，我不会跟你争论。我想指出的是，当您告诉某人.Net运行在虚拟机中而没有进一步解释时，您与该人通信的想法是“在主机进程中解释字节码”。这是不对的。

更新--这个答案现在有点老了，事情变了，使得.Net更不像虚拟机。在容器时代，冷启动时间可能会影响更多，我的理解是，.Net核心的最新版本有更多的工具可以使部署本机代码(并在每次启动时跳过JIT步骤)变得更加容易。