CLR的首要目标
到目前我们已经对CLR有了初步的了解，对帮助了解CLR要解决的问题非常有用。从很高的层次上讲，CLR只有一个目标：
CLR的目标是使编程变得更简单。
有两个因素使得这个陈述很有用。首先，这是CLR后续升级中 非常 有用的指导原则。如，只有简单的东西才容易用，因此在CLR中添加一些 用户可见 的复杂度是有疑虑的。对添加一个新功能来说，比投资产出比更重要的是 复杂度/所有场景应用收益权重 比。理想情况是这个比例是负的，即添加一个新功能可以移除某些限制或者将某些特殊场景泛化。但一般情况下是通过最小化复杂度和最大化新功能支持的使用场景来尽量降低这个比值。
第二个原因是这个目标之所以重要，是因为 CLR的成功基于易于使用。CLR并不是因为其比原生程序更快或者更小（实际上，设计良好的原生程序经常是赢家）而获得成功，CLR也不是因为其包含某些特定功能而成功（如垃圾回收，平台无关，面向对象编程或者支持多版本）。CLR之所以成功是因为其整合这么多以及其他很多功能，使得编程比其他平台更简单，一些非常重要但是经常被忽视的功能如：
- 简化的编程语言（如C#和Visual Basic比C++简单不少）。
- 一套致力于易用使用的类库（如，我们只有一种字符串类型，而且它还是不可修改的，这个特性极大简化了处理字符串的API）。
- 严谨的类库命名规范（如要求API都使用完整单词并且统一命名规范）。
- 强大的编程工具链（如果Visual Studio是的编写CLR程序极其简单，智能感知也极大方便编程时查找正确类型和函数）。
就是这个致力于简单的做法成为CLR成功的重要因素。奇怪的是，很多重要的易用使用的功能都是相当乏味的。如，任何编程环境都要求统一命名规范，但是在一个很大的类库里做到这一点需要大量的工作。而且这个工作经常与其他目标冲突（如保持跟之前版本的接口的兼容性），或者就是有很高的成本（如在一个 非常 庞大的代码库里重命名一个函数的成本）。也就是这个目标时刻提醒我们并在工作中将其放在最优先的位置。
CLR的重要功能
CLR有很多功能，可以归类如下：
基础功能 - 是其他功能的设计的根基，包括：
a. 垃圾回收
b. 内存安全和类型安全
c. 对编程语言的高阶支持次要功能 - 基于基础功能，但不是被很多程序用到
a. 进程隔离的应用程序域（AppDomain）机制
b. 进程安全和沙盒环境其它功能 - 运行环境所需但是不基于基础功能，它们是为了创建一个完整的编程环境而设计：
a. 多版本
b. 调试/进程剖析
c. 互操作
CLR里的垃圾回收
在所有CLR提供的功能里，垃圾回收值得特别说明。垃圾回收是自动内存回收机制的普遍术语。在垃圾回收系统里，用户进程不需要调用特定的操作来清空内存。运行时负责在垃圾回收内存堆里实时跟踪所有引用，它会遍历内存找出仍被进程使用到的那些引用。而其它内存则被当作 垃圾 并可以用来处理新的内存分配请求。
垃圾回收是一个非常有用的功能，因为其简化了编程。显而易见的简化是不再需要显式的删除操作。虽然去掉删除操作的确很重要，但其给程序员带来其它更实质的价值：
- 垃圾回收简化了接口设计，因为你不再需要仔细设计接口的那一方负责删除接口传递的对象。如：CLR接口只简简单单的返回字符串，不附带字符串的缓存和长度。这也意味着不需要担心字符串缓存的长度是否过小。因此，垃圾回收使得运行时上的所有接口都比之前的简单。
- 垃圾回收消除了很多常见的错误。在处理一个对象的生命周期时很容易犯错，要么就是销毁太早了（导致内存破坏），要么就是太迟了（导致内存泄漏）。一般程序会用到百万级别的对象，导致发生这种错误的概率很高。而且，追踪这样的生命周期方面的bug非常难，特别是对于那些被很多对象引用到的对象。消除这类内存方面的错误避免了很多悲剧。
然而，不是因为垃圾回收以上有用的功能使得我们在这里特别说明它。它对运行时的简单要求使得其更重要：
垃圾回收要求所有指向GC堆的引用都是可跟踪的。
虽然这是一个非常简单的要求，其实它对运行时有着深远的意义。正如你想象的那样，在程序运行的任意时刻知道指向一个对象的每一个指针，是非常难的。于是我们采取了折中的办法，技术上来说，只要GC发生的时候才会满足这个要求（因此，在理论上将我们不需要随时知道所有的GC引用，只需要在GC的时候知道即可）。在实际操作中，就连这个折中的办法都因为CLR的另外一个功能而无法完全满足：
CLR支持在一个进程里运行多个并发线程。
在任意时刻，正在执行的其它线程的分配请求会触发一个GC。而多个并发的线程的执行顺序是无法准确获知的。我们无法精准获知如果一个线程触发了GC请求，另外一个线程正在干什么。因此，GC可以在任何时候触发。CLR不需要 立即 响应其它线程的GC请求，CLR需要一点“回旋空间”来避免实时追踪GC引用，但它需要在其它线程触发GC请求时有足够空间来“及时”响应。
这意味着CLR 几乎 需要实时追踪 所有 指向GC堆的引用。由于GC引用也许存在于机器的寄存器上、在局部变量里、静态或者其他字段里，有很多地方需要跟踪。最麻烦的地方是寄存器和局部变量，因为它们与用户代码的实际运行情况密切相关。事实上，这对操作GC引用的 机器代码 有一个额外的要求：它必须跟踪所有它用到的GC引用。这意味着编译器需要做一些额外工作来产生跟踪这些引用的指令。
请查看文章 垃圾回收设计文档 来了解更多信息。
