全面剖析VB.NET(6)

由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）的主要任務就是監視程序使用的資源，當可用資源達到某個確定的極限時查找不再使用的對象，如發現有這類對象存在則釋放它們所占用的資源。垃圾回收的一個很大的優點是程序員無需再為大多數常見的循環引用擔心。在循環引用情形下，子對象擁有對父對象的引用，同時父對象又擁有對子對象的引用。在引用計數模式下，循環引用阻止了系統釋放和拆除任意一個對象。然而，垃圾回收器能夠找出這類循環引用并拆除它們。垃圾回收機制同時也意味著，當對象的最后一個引用被釋放時，對象并不一定立即被拆除。

采用垃圾回收機制的一個后果是：我們不能再希望類的Terminate事件總是適時觸發。事實上，如果線程被阻塞的話，Terminate事件可能完全不會觸發。這就是所謂的“非確定的結束”（non-deterministic finalization），而COM提供的則是“確定的結束”。由于缺乏“確定的結束”，再加上因為垃圾回收器重新組織和整理內存導致不能運用指針，新聞組中出現了對該問題激烈的爭論：有些人憎恨這些新的限制，因為他們依賴于“確定的結束”；有些人覺得無關緊要，因為他們并不依賴于Terminate事件。

從引用計數轉變到垃圾回收僅僅是Visual Studio.NET底層體系不再是COM這一變化的諸多必然結果之一。雖然VB.NET之內仍舊可以使用COM對象，但這些對象必須通過封裝（Wrapper）才能訪問。任何時候，封裝都意味著性能的降低，甚至還有可能導致對象行為的異常。如果要遷移一個大量使用COM對象的工程，你必須認真地進行計劃和測試，應用程序的某些部分可能還需要重新構造。

原文轉自：http://www.anti-gravitydesign.com