CLR vs JVM：将Java和.NET之间的永无止境的战斗带到VM级别

CLR和JVM之间有一些相似之处-两者都是高性能的软件运行时，都包含垃圾回收方法，代码级安全性和丰富的框架以及开源库。但是也存在一些非常明显的差异。

我们都已经听到了Java和.NET之间的长期争论的争论，并且就许多事情而言，要确定最适合您的应用程序的因素有很多。但是，如果我们将其深入到虚拟机级别会怎样？

CLR和JVM之间有一些相似之处-两者都是高性能的软件运行时，都包含垃圾回收方法，代码级安全性和丰富的框架以及开源库。两者都采用基于堆栈的操作，这是存储和检索操作数及其结果的最常用方法。

但是也存在一些非常明显的差异。

对于这些VM共享的每个相似之处，可以发现实现上的差异。尽管如此，就像使用编程语言一样，这些VM的开发也以一种类似跳跃的方式前进。一种实现类似于“ mark-sweep-compact”的方法来进行垃圾回收，另一种很快就会出现。下面，我分解了几个最大的区别。

现在有一些主要差异

语言和平台兼容性

CLR和JVM之间潜在的表面差异（尽管可能会影响它们的开发方式）是JVM被创建为主要用于Java，而CLR被设计为与语言无关。相反，CLR最初仅设计为在Windows操作系统和硬件上运行，而JVM则设计为可移植到与操作系统无关的多个操作系统和硬件体系结构中。众所周知，时代已经改变了，现在有可以在Linux和Mac上运行的CoreCLR，并且已经开发了许多与JVM一起使用的语言。

这导致一个事实，即在大多数情况下，CLR和JVM之间的差异也是使用它们的语言之间的差异的标志。或者，您可以说，语言之间的一些最重要的区别（出于参数的缘故，假设C＃和Java）实际上是在VM级别实现的。

JIT编译

我们在VM级别上看到的最大区别是，尽管两者都使用JIT（即时）编译，但不会调用编译器同时运行。在运行时首次调用该方法时，CLR将MSIL代码编译为机器代码。JVM使用专用的JIT编译器引擎HotSpot将Java字节码编译为机器代码。该方法在代码中编译将实际使用的“热点”，以防止在运行时出现较长的编译时间。

这些编译策略中的每一个在性能方面都有其自身的权衡。因为CLR在执行之前会编译所有机器代码，所以从长远来看，可以缩短执行时间。但是，另一方面，如果运行方法只需要一小部分代码，则Java的HotSpot编译器可以节省时间。热点还可以应用高级优化，该优化与调整结果机器代码的执行时的动态行为有关。

综上所述，实际上有很多方法可以配置JVM和CLR –我们只是在本文中进行了介绍。

语言功能的实现

另一个较小的区别是，CLR是用指令来构建的，该指令用于处理泛型类型并在运行时在这些类型上应用参数专用化。基本上，这意味着CLR可以识别例如List <int>和List <String>之间的差异，而JVM无法识别。尽管有计划，但CLR还允许用户以Structs的形式定义新的值类型，而基于JVM的语言中的值类型是固定的（字节，短，整数，长，浮点，双精度，char，布尔型）。在工作中改变这一点。

像这样的差异还有一些，它们在语言层面表现出更多差异。其中一些包括：闭包，协程和指针，它们在CLR中可用，而在JVM中不可用。

生产监控和异常处理

尽管两者都包含用于异常处理的方法，但是两者之间的总体差异可能会影响与不同的异常监视和错误监视工具的兼容性。反过来，这会影响故障排除策略和工作流程。JVM具有非常强大的字节码检测框架，该框架同时支持Java和C ++代理，还允许多个代理并行执行。这使开发人员可以运行多个探查器，APM以及编写自己的自定义代理，以充分了解和优化其应用行为。CLR代理受到更多限制，并且仅允许在运行时将一个.NET分析器附加到CLR。JVM甚至在运行时通过内置的Java API支持附加和分离代理。

社区

说到竞争，我们知道.NET和Java都有强大的社区来支持它们。在这些社区中，开发人员在诸如StackOverflow之类的网站上提出问题并进行深入的对话。快速搜索每个VM的名称可以发现CLR被标记了3250次，而JVM被标记了8628次。

在StackOverflow之外，还有Microsoft和Oracle自己培养的广泛社区。在这里，用户不仅可以找到与CLR和JVM相关的其他信息和资源。那里的主题包括云中的实施，疑难解答等。

但是，除此之外，社区绝对更集中于单个语言，例如.NET，Java，C / C ++，Scala等。

最后的想法

从最高级别看这些VM，CLR和JVM之间的差异似乎几乎可以忽略不计。但是，在许多（如果不是大多数）情况下，VM级别的差异反映了使用它们的语言之间的主要差异。由于这些VM及其对应语言的构建方式，每个功能都有一些细微的差异，以提供其创建者想要提供的功能