深入概括VB.NET運行環(huán)境
隨著時代的變化，信息成為我們不可缺少的一部分，在這發(fā)展中我們開發(fā)的語言也隨之成長，不管應(yīng)用是用VB、C#還是其他.NET語言編寫，所有VS.NET代碼都是編譯成中間語言（Intermediate Language，IL）。當應(yīng)用運行時，一個實時編譯器（just-in-time compiler，或稱為JIT）就把IL代碼編譯成機器語言。在理論上，它意味著為非Windows的平臺構(gòu)造VB.NET運行環(huán)境是可能的，但目前還沒有出現(xiàn)有關(guān)這類系統(tǒng)的正式消息。IL有一個缺點：正如VB在5.0以前的版本，IL代碼對于類似的反向編譯工程很敏感。由于存在這種可能性，許多開發(fā)者對于.NET框架的整體安全性抱有懷疑。
對CLR進行優(yōu)化影響IL層次上的代碼，它使得所有使用CLR的語言受益。然而，對于特定語言的優(yōu)化涉及到如何把代碼編譯成IL代碼，它根據(jù)特定語言的語法進行。因此，.NET各種語言之間存在一定的性能差異是必然的。但不管如何，從整體上來看這仍舊是好事，例如CLR為VB帶來了和C#一樣的調(diào)試和分析工具——之所以能夠如此，是因為它們都使用一樣的工具。
CLR提供了前所未有的跨語言集成能力，其中包括跨語言繼承代碼的能力。所有使用CLR的語言都使用一個公共類型系統(tǒng)（Common Type System），它使得開發(fā)那些運用多種語言的應(yīng)用變得更為容易。在CLR之內(nèi)運行的代碼稱為“受管理的代碼”（Managed Code），受管理代碼所使用的內(nèi)存由CLR全面控制。受管理的代碼有著許多優(yōu)點，包括交叉語言集成、跨語言異?？刂埔约耙粋€組件交互的簡化模型。VB.NET運行環(huán)境只能以受管理代碼方式運行，與此相對應(yīng)，C#卻具有將代碼轉(zhuǎn)入非受管理方式運行的能力（運行在CLR之外），比如執(zhí)行指針處理之類的操作。這是VB.NET不能與C#相提并論的地方之一。然而，這種能力的是否重要，對于不同的人、不同的用途來說都有所不同。
由CLR導(dǎo)致的體系上的不同不僅僅是跨語言繼承、共享功能和受管理代碼，它還有更深刻的意義。Visual Studio.NET的底層體系不再是COM；另外，VB.NET運行環(huán)境中所有東西都是對象，甚至連字符串也一樣。由于這些原因以及其他許多原因，Microsoft改變了底層體系管理對象的方法。COM系統(tǒng)通過引用計數(shù)方式管理對象，每當對象被引用時，引用計數(shù)就增加。當對象引用超出作用范圍或者被釋放時，計數(shù)器的值就減少；一旦引用計數(shù)為0，對象就被釋放。Microsoft聲稱.NET體系中的引用計數(shù)開銷實在太大，使得.NET采用引用計數(shù)不再合適，因此它就放棄了引用計數(shù)，改用垃圾回收（Garbage Collection）。
大約40年前，John McCarthy設(shè)計了LISP語言，它是可考證的第一種編程語言。LISP運行時不斷地分配和釋放大量的小塊內(nèi)存，由于那時的計算機內(nèi)存遠遠沒有現(xiàn)在這么龐大，因此早期的LISP用戶很快感到內(nèi)存不足，同時許多不再使用的內(nèi)存卻未能利用起來。為了解決這個問題，McCarthy于1959年第一次提出了垃圾回收的思想。
在一個真正面向?qū)ο蟮南到y(tǒng)中，垃圾回收機制能夠很好地滿足分配和釋放大量小塊內(nèi)存的需要。因此，Microsoft在VS.NET中重新實現(xiàn)了垃圾回收機制。
CLR垃圾回收器（CLR Garbage Collector）的主要任務(wù)就是監(jiān)視程序使用的資源，當可用資源達到某個確定的極限時查找不再使用的對象，如發(fā)現(xiàn)有這類對象存在則釋放它們所占用的資源。垃圾回收的一個很大的優(yōu)點是程序員無需再為大多數(shù)常見的循環(huán)引用擔(dān)心。在循環(huán)引用情形下，子對象擁有對父對象的引用，同時父對象又擁有對子對象的引用。在引用計數(shù)模式下，循環(huán)引用阻止了系統(tǒng)釋放和拆除任意一個對象。然而，垃圾回收器能夠找出這類循環(huán)引用并拆除它們。垃圾回收機制同時也意味著，當對象的最后一個引用被釋放時，對象并不一定立即被拆除。
采用垃圾回收機制的一個后果是：我們不能再希望類的Terminate事件總是適時觸發(fā)。事實上，如果線程被阻塞的話，Terminate事件可能完全不會觸發(fā)。這就是所謂的“非確定的結(jié)束”（non-deterministic finalization），而COM提供的則是“確定的結(jié)束”。由于缺乏“確定的結(jié)束”，再加上因為垃圾回收器重新組織和整理內(nèi)存導(dǎo)致不能運用指針，新聞組中出現(xiàn)了對該問題激烈的爭論：有些人憎恨這些新的限制，因為他們依賴于“確定的結(jié)束”；有些人覺得無關(guān)緊要，因為他們并不依賴于Terminate事件。
從引用計數(shù)轉(zhuǎn)變到垃圾回收僅僅是Visual Studio.NET底層體系不再是COM這一變化的諸多必然結(jié)果之一。雖然VB.NET之內(nèi)仍舊可以使用COM對象，但這些對象必須通過封裝（Wrapper）才能訪問。任何時候，封裝都意味著性能的降低，甚至還有可能導(dǎo)致對象行為的異常。如果要遷移一個大量使用COM對象的工程，你必須認真地進行計劃和測試，應(yīng)用程序的某些部分可能還需要重新構(gòu)造。
【編輯推薦】
