Since .NET has a garbage collector why do we need

问题:

If I understand correctly the .net runtime will always clean up after me. So if I create new objects and I stop referencing them in my code, the runtime will clean up those objects and free the memory they occupied.

Since this is the case why then do some objects need to have a destructor or dispose method? Won’t the runtime clean up after them when they are not referenced anymore?

回答1:

Finalizers are needed to guarantee the release of scarce resources back into the system like file handles, sockets, kernel objects, etc. Since the finalizer always runs at the end of the objects life, it’s the designated place to release those handles.

The Dispose pattern is used to provide deterministic destruction of resources. Since the .net runtime garbage collector is non-deterministic (which means you can never be sure when the runtime will collect old objects and call their finalizer), a method was needed to ensure the deterministic release of system resources. Therefore, when you implement the Dispose pattern properly you provide deterministic release of the resources and in cases where the consumer is careless and does not dispose the object, the finalizer will clean up the object.

A simple example of why Dispose is needed might be a quick and dirty log method:

public void Log(string line)
{
    var sw = new StreamWriter(File.Open(
        "LogFile.log", FileMode.OpenOrCreate, FileAccess.Write, FileShare.None));

    sw.WriteLine(line);

    // Since we don't close the stream the FileStream finalizer will do that for 
    // us but we don't know when that will be and until then the file is locked.
}

In the above example, the file will remain locked until the garbage collector calls the finalizer on the StreamWriter object. This presents a problem since, in the meantime, the method might be called again to write a log, but this time it will fail because the file is still locked.

The correct way is to dispose the object when are done using it:

public void Log(string line)
{
    using (var sw = new StreamWriter(File.Open(
        "LogFile.log", FileMode.OpenOrCreate, FileAccess.Write, FileShare.None))) {

        sw.WriteLine(line);
    }

    // Since we use the using block (which conveniently calls Dispose() for us)
    // the file well be closed at this point.
}

BTW, technically finalizers and destructors mean the same thing; I do prefer to call c# destructors 'finalizers' since otherwise they tend to confuse people with C++ destructors, which unlike C#, are deterministic.

回答2:

The previous answers are good but let me emphasize the important point here once again. In particular, you said that

If I understand correctly the .net runtime will always clean up after me.

This is only partly correct. In fact, .NET only offers automatic management for one particular resource: main memory. All other resources need manual cleanup.¹⁾

Oddly, main memory gets special status in almost all discussions about program resources. There's of course a good reason for this – main memory is often the scarcest resource. But it's worth remembering that there are other types of resources as well, that also need managing.

---

¹⁾ The usual attempted solution is to couple the lifetime of other resources to the lifetime of memory locations or identifiers in the code – hence the existence of finalizers.

回答3:

The Garbage Collector will only run if the system is not under memory pressure, unless it really needs to free up some memory. That means, you can never be sure when the GC will run.

Now, Imagine you are a Database Connection. If you let the GC clean up after you, you may be connected to the database for much longer than needed, causing weird load situation. In that case, you want to implement IDisposable, so that the user can call Dispose() or use using() to really make sure that the connection is closed ASAP without having to rely on GC which may run much later.

Generally, IDisposable is implemented on any class that works with unmanaged resources.

回答4:

1. There are things the garbage collector can't clean up after you
2. Even with things it can cleanup, you can help it clean up sooner

回答5:

The real reason is because .net garbage collection is NOT designed to collect unmanaged resources, therefore the cleanup of these resources still lies in the hands of the developer. Also, object finalizers are not automatically called when the object goes out of scope. They are called by the GC at some undetermined time. And when they get called, GC doesn't run it right away, it waits for the next round to call it, increasing the time to clean up even more, not a good thing when your objects are holding scarce unmanaged resources (such as files or network connections). Enter the disposable pattern, where the developer can manually release scarce resources at a determined time (when calling yourobject.Dispose() or the using(...) statement). Keep in mind you should call GC.SuppressFinalize(this); in your dispose method to tell the GC that the object was manually disposed and shouldn't be finalized. I suggest you take a look at the Framework Design Guidelines book by K. Cwalina and B. Abrams. It explains the Disposable pattern very good.

Good Luck!

回答6:

The simplistic explanation:

• Dispose is designed for deterministic disposal of non-memory resources, especially scarce resources. For example, a window handle or a database connection.
• Finalize is designed for non-deterministic disposal of non-memory resources, usually as a backstop if Dispose wasn't called.

Some guidelines for implementing the Finalize method:

• Only implement Finalize on objects that require finalization, because there is a performance cost associated with Finalize methods.
• If you require a Finalize method, consider implementing IDisposable to allow users of your type to avoid the cost of invoking the Finalize method.
• Your Finalize methods should be protected rather than public.
• Your Finalize method should free any external resources that the type owns, but only those that it owns. It should not reference any other resources.
• The CLR doesn't make any guarantees as to the order in which Finalize methods are called. As Daniel notes in his comment, this means that a Finalize method should not access any member reference types if possible, because these may have (or may one day have) their own finalizers.
• Never call a Finalize method directly on any type other than the type's base type.
• Try to avoid any unhandled exception in your Finalize method, as that will terminate your process (in 2.0 or higher).
• Avoid doing any long-running task in your Finalizer method, as that will block the Finalizer thread and prevent other Finalizer methods being executed.

Some guidelines for implementing the Dispose method:

• Implement the dispose design pattern on a type that encapsulates resources that explicitly need to be freed.
• Implement the dispose design pattern on a base type that has one or more derived types that hold on to resources, even if the base type does not.
• After Dispose has been called on an instance, prevent the Finalize method from running by calling the GC.SuppressFinalize Method. The only exception to this rule is the rare situation in which work must be done in Finalize that is not covered by Dispose.
• Do not assume that Dispose will be called. Unmanaged resources owned by a type should also be released in a Finalize method in the event that Dispose is not called.
• Throw an ObjectDisposedException from instance methods on this type (other than Dispose) when resources are already disposed. This rule does not apply to the Dispose method because it should be callable multiple times without throwing an exception.
• Propagate the calls to Dispose through the hierarchy of base types. The Dispose method should free all resources held by this object and any object owned by this object.
• You should consider not allowing an object to be usable after its Dispose method has been called. Recreating an object that has already been disposed is a difficult pattern to implement.
• Allow a Dispose method to be called more than once without throwing an exception. The method should do nothing after the first call.

回答7:

Objects that need descructors and dispose methods is using un-managed resources. So the garbage collector cannot clean up those resources, and you have to do this on your own.

Look at the MSDN documentation for IDisposable; http://msdn.microsoft.com/en-us/library/system.idisposable.aspx

The example uses an un-managed handler - IntPr.

回答8:

Some objects might need to clean up low-level items. Such as hardware that needs to be closed, etc.

回答9:

Mainly for non-managed code, and interaction with non-managed code. "Pure" managed code should never need a finalizer. Disposable on the other hand is just a handy pattern to force something to be released when you are done with it.

回答10:

There are a few (very few) cases where it may be necessary to perform a specific action when a pure managed object is no longer used, I can't come up with an example off the top of my head but I have seen a couple of legitimate uses over the years. But the main reason is to clean up any unmanaged resources that the object might be using.

So, in general, you won't need to use the Dispose/Finalize pattern unless you are using unmanaged resources.

回答11:

Because the the Garbage Collector cannot collect what the managed environment did not allocate. Therefore any call to an unmanaged API that results in a memory allocation needs to be collected in the old fashioned way.

回答12:

The .NET garbage collector knows how to handle managed objects within the .NET runtime. But the Dispose pattern (IDisposable) is used primarily for un-managed objects that an application is using.

In other words, the .NET runtime doesn't necessarily know how to deal with every type of device or handle out there (closing network connections, file handles, graphics devices, etc), so using IDisposable provides a way to say "let me implement some cleanup of my own" in a type. Seeing that implementation, the garbage collector can call Dispose() and ensure that things outside of the managed heap are cleaned up.