VB.NET公共运行时的环境

来源：qqread 作者：佚名出处：巧巧读书 2008-03-27 进入讨论组

迄今为止，业界对VB.NET讨论得最多的特色或许就是CLR.VB.NET运行在CLR之上，正是CLR 为VB.NET带来了许多关键的新特色（包括缺点在内）。例如，CLR使得VB.NET支持跨语言的继承以及自由线程。

在VB6 中，分布式VB程序要求有VB运行时库msvbvm60.dll支持，即该运行时库必须随同应用一起分发。其他许多语言，比如C++ 和Java，也有类似的要求。

在。NET 中，所有Visual Studio 语言共享同样的运行时环境CLR.改用CLR带来了几个重要的结果：现在所有Visual Studio 语言都共用同样的IDE 、同样的窗体引擎、同样的异常处理机制，等等。它意味着Visual Basic在很大程度上已经可以和。NET 的其他语言相提并论，如C#等。然而，对于CLR 的异议仍旧存在，VB业界仍在激励地争辩它地价值。

不管应用是用VB、C#还是其他。NET 语言编写，所有VS.NET代码都是编译成中间语言（Intermediate Language ，IL）。当应用运行时，一个实时编译器（just-in-time compiler ，或称为JIT ）就把IL代码编译成机器语言。在理论上，它意味着为非Windows 的平台构造。NET 运行环境是可能的，但目前还没有出现有关这类系统的正式消息。IL有一个缺点：正如VB在5.0 以前的版本，IL代码对于类似的反向编译工程很敏感。由于存在这种可能性，许多开发者对于。NET框架的整体安全性抱有怀疑。

对CLR 进行优化影响IL层次上的代码，它使得所有使用CLR 的语言受益。然而，对于特定语言的优化涉及到如何把代码编译成IL代码，它根据特定语言的语法进行。因此，。NET 各种语言之间存在一定的性能差异是必然的。但不管如何，从整体上来看这仍旧是好事，例如CLR 为VB带来了和C#一样的调试和分析工具——之所以能够如此，是因为它们都使用一样的工具。

CLR 提供了前所未有的跨语言集成能力，其中包括跨语言继承代码的能力。

所有使用CLR 的语言都使用一个公共类型系统（Common Type System），它使得开发那些运用多种语言的应用变得更为容易。

在CLR 之内运行的代码称为“受管理的代码”（Managed Code），受管理代码所使用的内存由CLR 全面控制。受管理的代码有着许多优点，包括交叉语言集成、跨语言异常控制以及一个组件交互的简化模型。Visual Basic.NET只能以受管理代码方式运行，与此相对应，C#却具有将代码转入非受管理方式运行的能力（运行在CLR 之外），比如执行指针处理之类的操作。这是VB.NET不能与C#相提并论的地方之一。然而，这种能力的是否重要，对于不同的人、不同的用途来说都有所不同。

由CLR 导致的体系上的不同不仅仅是跨语言继承、共享功能和受管理代码，它还有更深刻的意义。Visual Studio.NET 的底层体系不再是COM ；另外，VB.NET中所有东西都是对象，甚至连字符串也一样。由于这些原因以及其他许多原因，Microsoft 改变了底层体系管理对象的方法。COM 系统通过引用计数方式管理对象，每当对象被引用时，引用计数就增加。当对象引用超出作用范围或者被释放时，计数器的值就减少；一旦引用计数为0 ，对象就被释放。Microsoft 声称。

NET 体系中的引用计数开销实在太大，使得。NET 采用引用计数不再合适，因此它就放弃了引用计数，改用垃圾回收（Garbage Collection）。

大约40年前，John McCarthy 设计了LISP语言，它是可考证的第一种编程语言。LISP运行时不断地分配和释放大量的小块内存，由于那时的计算机内存远远没有现在这么庞大，因此早期的LISP用户很快感到内存不足，同时许多不再使用的内存却未能利用起来。为了解决这个问题，McCarthy于1959年第一次提出了垃圾回收的思想。

在一个真正面向对象的系统中，垃圾回收机制能够很好地满足分配和释放大量小块内存的需要。因此，Microsoft 在VS.NET中重新实现了垃圾回收机制。

CLR 垃圾回收器（CLR Garbage Collector ）的主要任务就是监视程序使用的资源，当可用资源达到某个确定的极限时查找不再使用的对象，如发现有这类对象存在则释放它们所占用的资源。垃圾回收的一个很大的优点是程序员无需再为大多数常见的循环引用担心。在循环引用情形下，子对象拥有对父对象的引用，同时父对象又拥有对子对象的引用。在引用计数模式下，循环引用阻止了系统释放和拆除任意一个对象。然而，垃圾回收器能够找出这类循环引用并拆除它们。