Comprehensive analysis of vb.net (6)

The differences in the system caused by the CLR are not just cross language inheritance, shared functionality, and managed code, but they also have a deeper meaning. The underlying system of Visual Studio.NET is no longer com; In addition, everything in vb.net is an object, even a string. For these reasons, and for many other reasons, Microsoft has changed the way the underlying system manages objects. The COM system manages objects by reference counting, and the reference count increases whenever the object is referenced. When an object reference is out of scope or released, the value of the counter is reduced, and once the reference count is 0, the object is freed. Microsoft claims that the reference count overhead in the. NET system is so large that. NET does not fit with reference counting, so it discards the reference count and uses garbage collection instead (garbage Collection).

About 40 years ago, John McCarthy designed the Lisp language, which was the first verifiable programming language. The Lisp runtime allocates and frees a large amount of small chunks of memory, and since the memory of the computer was far from being so large, early Lisp users quickly felt that there was not enough memory and many unused memory was not available. In order to solve this problem, McCarthy in 1959 for the first time put forward the idea of garbage collection.

In a truly object-oriented system, garbage collection is a good way to meet the need to allocate and release large amounts of small chunks of memory. As a result, Microsoft has implemented the garbage collection mechanism in vs.net.

The primary task of the CLR garbage collector (CLR garbage Collector) is to monitor the resources used by the program, to find objects that are no longer in use when the available resources reach a certain limit, and to release the resources they occupy if they are found to exist. A big advantage of garbage collection is that programmers don't have to worry about most common circular references. In a circular reference case, a child object has a reference to the parent object, and the parent object has a reference to the object. In reference count mode, circular references prevent the system from releasing and removing any object. However, the garbage collector can find such circular references and dismantle them. The garbage collection mechanism also means that when the last reference to an object is released, the object is not necessarily removed immediately.

One consequence of adopting the garbage collection mechanism is that we cannot hope that the terminate events of the class will always be triggered in due course. In fact, if the thread is blocked, the Terminate event may not be triggered at all. This is called an "indeterminate end" (non-deterministic finalization), while COM provides a "definite end". Because of the lack of a "determined end" and the inability to use pointers because the garbage collector reorganize and defragment the memory, there is a heated debate in newsgroups about the issue: Some people resent these new restrictions because they rely on "determined ends"; some feel irrelevant, Because they are not dependent on the Terminate event.

Switching from reference counting to garbage collection is just one of the many inevitable results of the Visual Studio.NET underlying system being no longer a COM change. Although COM objects can still be used within vb.net, these objects must be encapsulated (wrapper) to access them. At any time, encapsulation means a decrease in performance and even an exception that can cause object behavior. If you want to migrate a project that uses a large number of COM objects, you must plan and test carefully, and some parts of your application may need to be reconstructed.