我读过一本提到 .net 的书CLR 作为虚拟机？任何人都可以证明这一点吗？为什么我们在某些开发平台上需要虚拟机的概念？
是否有可能开发一个完全面向对象且像.net一样强大的本机框架（没有虚拟机的框架）？
将 CLR 称为虚拟机的书是“专业.Net Framework 2.0".
这里存在很多误解。我想如果您确实愿意，您可以将 .Net 视为虚拟机，但让我们看看 .Net Framework 如何真正处理您的代码。典型的场景是这样的
- 您可以使用 C#、VB.Net、F# 或其他兼容语言编写 .Net 程序。
- 该代码被编译为中间语言 (IL)，类似于 Java 的字节码，并分发到最终用户计算机。
- 最终用户在安装了正确版本的 .Net 的计算机上首次调用该程序
- 计算机认为这是一个 .Net 程序集而不是“原始”机器代码，并将其传递给 JIT 编译器
- JIT 编译器将 IL 编译为完全本机代码.
- 本机代码在程序执行期间保存在内存中。
- 调用保存的本机代码，IL 不再重要。
这里有几个重要的点，但最重要的一点是，任何时候都不会解释任何代码。相反，您可以在步骤 5 中看到它被编译为本机代码。这是huge与将其加载到虚拟机中不同，原因如下：
- 完全编译的代码由CPU直接执行，而不是由额外的软件抽象层解释或翻译，这样应该更快。
- JIT 编译器可以利用特定于运行程序的单个机器的优化，而不是满足于最低公分母。
- 如果您愿意，您甚至可以预编译代码，本质上对用户完全隐藏步骤 5。
我想您可以将其称为虚拟机，从某种意义上说，JITter 从开发人员那里抽象出了真实机器的细节。就我个人而言，我认为这并不正确，因为对于许多人来说，虚拟机意味着远离本机代码的运行时抽象，而对于 .Net 程序来说，不存在。
关于整个过程的另一个关键点是，它真正区别于“虚拟机”环境typical过程。如果您确实愿意，您可以在分发之前预编译 .Net 程序集，并将本机代码直接部署给最终用户（提示：在程序的生命周期中，总体速度会更慢，因为您会失去特定于机器的优化）。当然，您仍然需要安装 .Net 运行时，但此时它实际上与任何其他运行时 API 没有太大区别；它更像是一个带有很好的 API 的 dll 集合，您可以链接到该 API，就像您可以使用 VB 或 C 运行时一样，Microsoft 也随 Visual Studio 一起提供了这些 API。这种方式将 IL 排除在外，使得 VM 的绰号更难证明其合理性。 （我说“有点”是因为 IL 仍然被部署并用于验证保存的代码，但它本身从未被触及来执行）。
另一点是缺乏虚拟机进程。当您运行应用程序时，不会运行常见的“沙箱”进程。与 Java 相比，如果在程序运行时打开任务管理器，您将看到专门针对 Java VM 的进程，而应用程序的实际进程是 VM 创建的沙箱内的线程。在.Net 中，您可以直接在Windows 任务管理器中看到应用程序的进程。
总之：您可以说 IL + CLR + JIT 一起以某种方式构成了虚拟机。我个人不这么认为，但如果你相信这一点，我不会与你争论。我想说的一点是，当你告诉某人 .Net 在虚拟机中运行而无需进一步解释时，你与该人传达的想法是“主机进程中解释的字节码”。那是错误的。
Update这个答案现在有点过时了，事情已经发生了变化，使得 .Net 不再像虚拟机。在容器时代，冷启动时间可能更重要，我的理解是最新版本的 .Net Core 有更多工具可以使部署本机代码（并在每次启动时跳过 JIT 步骤）变得更加容易。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
