在很多的场合我都遇到过一些群友提这样的一些问题：

为什么Java有GC调优而CLR没有据说过有GC调优呢？到底是Java的JVM GC比拟强还是C#应用的.NET CLR的GC比拟强呢？其实业内曾经有几位大佬的高赞文章和大家分享一下，次要探讨JVM和CLR还有GC调优，明天就借用大佬的答复给大家分享一下。

R大的答复
https://www.wenjuan.com/s/UZB...
https://www.wenjuan.com/s/UZB...
https://www.wenjuan.com/s/UZB...
https://www.wenjuan.com/s/UZB...
https://www.wenjuan.com/s/UZB...
https://www.wenjuan.com/s/UZB...
https://www.wenjuan.com/s/UZB...
https://www.wenjuan.com/s/UZB...
https://www.wenjuan.com/s/UZB...
https://www.wenjuan.com/s/UZB...
https://www.wenjuan.com/s/UZB...
https://www.wenjuan.com/s/UZB...
https://www.wenjuan.com/s/UZB...
https://www.wenjuan.com/s/UZB...
https://www.wenjuan.com/s/UZB...
https://www.wenjuan.com/s/UZB...
https://www.wenjuan.com/s/UZB...
https://www.wenjuan.com/s/UZB...
https://www.wenjuan.com/s/UZB...
https://www.wenjuan.com/s/UZB...
https://www.wenjuan.com/s/UZB...
https://www.wenjuan.com/s/UZB...
https://www.wenjuan.com/s/UZB...
https://www.wenjuan.com/s/UZB...
https://www.wenjuan.com/s/UZB...
https://www.wenjuan.com/s/UZB...
https://www.wenjuan.com/s/UZB...
https://www.wenjuan.com/s/UZB...
https://www.wenjuan.com/s/UZB...
https://www.wenjuan.com/s/UZB...
https://www.wenjuan.com/s/UZB...
https://www.wenjuan.com/s/UZB...
https://www.wenjuan.com/s/UZB...
https://www.wenjuan.com/s/UZB...
https://www.wenjuan.com/s/UZB...
https://www.wenjuan.com/s/UZB...
https://www.wenjuan.com/s/UZB...
https://www.wenjuan.com/s/UZB...
https://www.wenjuan.com/s/UZB...
https://www.wenjuan.com/s/UZB...
https://www.wenjuan.com/s/UZB...
https://www.wenjuan.com/s/UZB...
https://www.wenjuan.com/s/UZB...
https://www.wenjuan.com/s/UZB...
https://www.wenjuan.com/s/UZB...
https://www.wenjuan.com/s/UZB...
https://www.wenjuan.com/s/UZB...
https://www.wenjuan.com/s/UZB...
https://www.wenjuan.com/s/UZB...
https://www.wenjuan.com/s/UZB...
https://www.wenjuan.com/s/UZB...
https://www.wenjuan.com/s/UZB...
https://www.wenjuan.com/s/UZB...
https://www.wenjuan.com/s/UZB...
https://www.wenjuan.com/s/UZB...

首先给大家介绍一下R大，R大网名叫RednaxelaFX，南京大学毕业巨佬，主攻高级编程语言虚拟机的设计与实现，对于C# .NET CLR有十分深刻的钻研和理解。先后退出阿里、Oracle、Azul System从事JVM虚拟机开发的工作（HotSpot JVM and Zing JVM）。当初在Databricks从事Spark开发工作。

这里R大次要就CLR上几种调优形式和为什么CLR不须要xmx、xmn等参数给出了起因

因为题主您就是没听说过 >_<

假设题主说的是上面三个层面的调优的头两种状况：

对VM的配置参数调优（例如GC参数）对应用程序本身的代码调优对VM本身的实现调优

(2)的话无论什么语言什么环境都好，谋求性能的人必定都有在做。Java和.NET都有好用的profiler能够帮忙这方面的考察和调优。

有时候参数调优还不够的中央，也只能本人改本人的利用代码来解决问题了。请看一个经典案例：

In managed code we trust, our recent battles with the .NET Garbage Collector

(3)的话，CLR还没开源的时候，也无从调起。倒是有不少人给Mono奉献改良性能的patch，也算是狭义上“.NET”的VM实现层面调优吧。

在CoreCLR开源后，也有不少人给CoreCLR奉献各种patch呢，包含“调优”。

.NET码农们以前时不时会中招的一种中央是程序进入GC的耗时（time-to-GC），也就是从CLR说“我要开始做GC了”到“真正开始做GC”之间的耗时。这里次要开销来自申请所有利用线程暂停（SuspendEE），这些线程要多久才实现对该申请的响应。据说过这个过程中会产生“250ms的倍数的等待时间”不？请跳传送门：

Garbage Collection Thread Suspension Delay (250ms Multiples)

像这种问题就是不进到VM外部做批改的话无奈解决的。

(1)的话，其实就算当年CLR还没开源的时候，CLR也是有调优参数能够配置的呢。

最经典的就是抉择试用Workstation GC（WKS GC）或者Server GC（SVR GC）。见过<gcServer>参数不？

起初能够配置应用Concurrent GC、Background Workstation GC、Background Server GC等。

用户还能够在代码里通过 GCSettings.LatencyMode 属性来影响GC的行为。

看，调优参数列表之一：
Runtime Settings Schema
不过CLR跟HotSpot VM在配置上有一个显著的区别，就是CLR不须要用户指定一个“GC堆的最大大小”。这跟CLR的GC堆的根底设计思路有关系。

HotSpot VM的GC堆肯定要应用间断的虚拟地址空间。VM在启动的时候会一口气reserve GC所须要的整个地址空间，而后再按需commit。-Xmx会参加到GC堆最大大小的计算中。

CLR的GC堆则是分段式的（segemented），GC堆所用的空间会一个个segment调配，用满了一个再去调配一个新的；segment不须要在间断的地址空间上。这样GC堆能够按需主动增长或者缩减，能够始终增长到耗尽虚拟地址空间或者达到配额。

CLR这种分段式GC堆的益处是，在Windows上，特地是32位Windows上，虚拟地址空间中用户程序能够用的局部是比拟系统的，想要用到尽就不能对“间断的地址空间”有太多要求，这种条件下CLR跑在Windows上就能够充分利用资源。

而且这样一来，用户就不必头疼实现想好要配置多大的堆给CLR用了。反正它须要用多少会本人去增长。这用户体验就比搜索枯肠想个好-Xmx要爽。

这种做法的害处…怎能没有害处呢。害处也有若干。其中一个就是在这样的堆上实现的分代式GC的write barrier效率会比HotSpot那种用间断地址空间的要差一些。而且segmented heap实现起来也略微简单一些。
CLR 相比 JVM有哪些先进之处？

CLR 相比 JVM有哪些先进之处？ - RednaxelaFX的答复 - 知乎 https://www.zhihu.com/questio...

这里R大次要介绍了下CLR和JVM的不同，和上面hez大佬的答复能够对应起来

尽管只写了一半但还是先收回来省得坑掉。前面边探讨边更新吧…

这个问题原文是：

CLR 相比 JVM有哪些先进之处？

留下备份。

首先这个问题按其原样无法回答，因为CLR与JVM不是可比拟的对象。

CLR（Common Language Runtime）是CLI（Common Language Infrastructure）标准中的VES（Virtual Execution System）的一种具体实现，而“JVM”不指定实现的话只能说是一种形象的标准。

适宜比拟的对象是：

标准层面：CLI vs JVM实现层面：CLR / Mono 等 vs HotSpot VM / J9 VM / JRockit VM 等

从标准层面看的话，CLI标准

ECMA-335

以后最新的版本是2012年出的第6版。我没太跟进新的CLI标准所以不确定这个版本的CLI与哪个版本的.NET Framework里的CLR对应。

JVM标准

The Java® Virtual Machine Specification

以后最新的版本则是2015年出的Java SE 8版。

在标准层面上，以后的CLI完胜以后的JVM。

《Virtual Machines: Versatile Platforms for Systems and Processes》

一书中有一章专门比照介绍了CLI与JVM的设计，值得一读。

JVM标准由Sun最后的JVM实现（起初称为Classic VM）形象而来，而后简直没有大的改变。起初的更新次要增加了Class文件对泛型信息的无限记录、注解（annotation）反对、字节码校验器的更新（split verifier / type checking verifier）、invokedynamic及MethodHandle反对、default method反对等。

最后的JVM标准尽管也提到它“能够反对多种语言”，但次要目标还是反对Java一种语言的执行，直到Java 7增加了JSR 292（invokedynamic与MethodHandle）后才有了专门为Java以外的语言设计的性能。

CLI由.NET最后的CLR实现形象而来，而后与CLR一起逐步进化。它呈现的工夫毕竟比JVM标准晚许多，而且一开始就以反对多种语言、多种范型的执行与互操作为设计目标，天然设计得更欠缺。对历史有趣味的同学能够搜搜“Project 7”看。

Interviewer: I've heard that there was a project where Microsoft started to inte...

Don Syme: That's a small part of the sequence. The visional design of the .NET platform was very much expected to be a multi-language platform from the start. Right back in 1998, just in fact as our research group in programming languages started at Microsoft and I joined the team and then other 10 of us joined the team, we were approached by a guy called James Plamondon, who started the project called Project 7, which was about getting 7 academic and 7 industrial programming languages on each side to target the .NET common language runtime and really check out if it was good enough, to see if design changes could be made early on in the design process of .NET to make sure it was good enough for a range of programming languages.

Project 7的参与方尝试了将许多种语言移植到CLR上，包含C、Pascal、Cobol (Fujitsu)、Fortran (Salford)、Haskell、Standard ML、Eiffel、Active Oberon for .NET (ETH)、Gardens Point Component Pascal (QUT)等等。

起初还有更进一步的“Project 7+”。

Technical Overview of the Common Language Runtime

要追寻CLR更早的黑历史就不得不提微软的Visual J++。请跳传送门：

微软当年的 J++ 到底是什么？为什么 Sun 要告它？ - RednaxelaFX 的答复

上面先列举一些点揭示我回头更新…

Assembly vs Class文件

常量池以stream的形式存在能够有strong name

CIL（Common Intermediate Language） / MSIL vs Java字节码

CIL不仅有二进制模式的标准，而且还有规范的文本模式语法；Java字节码只有二进制模式的标准局部变量区里无论什么类型的值都应用1个slot，而JVM则是long和double用相邻的2个slot异样解决反对filter反对具现化泛型（reified generics）    OpenJDK: Valhalla泛型反对申明点协变/逆变（declaration-site variance）    Java语言层面的泛型则是反对应用点协变/逆变（use-site variance）反对无符号整数类型（unsigned）反对用户自定义值类型（value type）    OpenJDK: Valhalla反对对用户自定义值类型指定显式内存布局，能够模仿C的struct和union以便互操作（StructLayout）    OpenJDK: Panama反对查看溢出的算术运算（checked arithmetic）反对有保障的尾调用（tail call）反对unsafe verifiable代码反对轻量代码生成（LCG，Lightweight Code Generation）反对委托类型（Delegate / MulticastDelegate）CLI Delegate的single cast版本与Java 7的MethodHandle有相似之处反对不便的P/Invoke和Reverse P/Invoke    OpenJDK: Panama不反对自定义类加载器（custom class loader）。JVM上过于灵便的ClassLoader几乎是头疼的要命，不反对这个几乎好。

CLI里藏的私货：Assembly采纳PE（Portable Executable）格局。PE是Windows上原生的可执行文件格局。

CLR与Windows的整合

Windows Loader能够间接辨认.NET Assembly并启动CLR来执行程序。Windows对GAC（Global Assembly Cache）有文件系统层面的非凡解决，“Fusion”。与COM有良好的互操作能力。毕竟CLR本来就是心愿设计成下一代COM，本来还用过COR这个名字（COM Object Runtime）。分块式GC堆（Chunked GC Heap），能够主动扩张和膨胀GC堆的大小，并且在Windows这种地址空间比拟破碎的环境中能够无效的利用地址空间里的空隙。对应的，JRockit在Windows上则是用filler object来利用空隙。GC堆分为多个空间，特地是高频堆/低频堆（high-frequency heap / low-frequency heap）的划分很乏味。GC反对固定住对象（Object Pinning）GC提供API让应用程序能够指定native对象的内存压力，以便GC与native协调工作（System.GC.AddMemoryPressure Method (Int64)）反对Windows的结构化异样解决（SEH）。

CLR 与 一些JVM实现之间有对应物的

CLR：DAC / SOS扩大；HotSpot VM：Serviceability Agent；J9 VM：DTFJ / jdmpviewCLR：CAS（Code Access Security）与 JVM的沙箱