【文章內(nèi)容簡介】 jects that make up a DataSet. Releasing memory is the GC39。s responsibility. Because the .NET Framework designers did not need to free these objects, the plicated web of object references did not pose a problem. No decision needed to be made regarding the proper sequence of freeing this web of objects。 it39。s the GC39。s job. The GC39。s design simplifies the problem of identifying this kind of web of objects as garbage. After the application releases its reference to the dataset, none of the subordinate objects can be reached. It does not matter that there are still circular references to the DataSet, DataTables, and other objects in the web. Because these objects cannot be reached from the application, they are all garbage. The Garbage Collector runs in its own thread to remove unused memory from your program. It also pacts the managed heap each time it runs. Compacting the heap moves each live object in the managed heap so that the free space is located in one contiguous block of memory. Figure shows two snapshots of the heap before and after a garbage collection. All free memory is placed in one contiguous block after each GC operation. Figure . The Garbage Collector not only removes unused memory, but it moves other objects in memory to pact used memory and maximize free space. 10 As you39。ve just learned, memory management is pletely the responsibility of the Garbage Collector. All other system resources are your responsibility. You can guarantee that you free other system resources by defining a finalizer in your type. Finalizers are called by the system before an object that is garbage is removed from memory. You canand mustuse these methods to release any unmanaged resources that an object owns. The finalizer for an object is called at some time after it bees garbage and before the system reclaims its memory. This nondeterministic finalization means that you cannot control the relationship between when you stop using an object and when its finalizer executes. That is a big change from C++, and it has important ramifications for your designs. Experienced C++ programmers wrote classes that allocated a critical resource in its constructor and released it in its destructor: // Good C++, bad C: class CriticalSection { public: // Constructor acquires the system resource. CriticalSection( ) { EnterCriticalSection( )。 } // Destructor releases system resource. ~CriticalSection( ) { ExitCriticalSection( )。 } }。 // usage: 11 void Func( ) { // The lifetime of s controls access to // the system resource. CriticalSection s。 // Do work. //... // piler generates call to destructor. // code exits critical section. } This mon C++ idiom ensures that resource deallocation is exceptionproof. This doesn39。t work in C, howeverat least, not in the same way. Deterministic finalization is not part of the .NET environment or the C language. Trying to force the C++ idiom of deterministic finalization into the C language won39。t work well. In C, the finalizer eventually executes, but it doesn39。t execute in a timely fashion. In the previous example, the code eventually exits the critical section, but, in C, it doesn39。t exit the critical section when the function exits. That happens at some unknown time later. You don39。t know when. You can39。t know when. Relying on finalizers also introducesperformance penalties. Objects that require finalization put a performance drag on the Garbage Collector. When the GC finds that an object is garbage but also requires finalization, it cannot remove that item from memory just yet. First, it calls the finalizer. Finalizers are not executed by the same thread that collects garbage. Instead, the GC places each object that is ready for finalization in a queue and spawns yet another thread to execute all the finalizers. It continues with its business, removing other garbage from memory. On the next GC cycle, those objects that have been finalized are removed from memory. Figure shows three different GC operations and the difference in memory usage. Notice that the objects that require finalizers stay in memory for extra cycles. Figure . This sequence shows the effect of finalizers on the Garbage Collector. Objects stay in memory longer, and an extra thread needs to be spawned to run the Garbage Collector. 12 This might lead you to believe that an object that requires finalization lives in memory for one GC cycle more than necessary. But I simplified things. It39。s more plicated than that because of another GC design decision. The .NET Garbage Collector defines generations to optimize its work. Generations help the GC identify the likeliest garbage candidates more quickly. Any object created since the last garbage collection operation is a generation 0 object. Any object that has survived one GC operation is a