StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
primarykey
Id
538238
data
AcceptedAnswerId
0
AnswerCount
0
ClosedDate
CommentCount
63
CommunityOwnedDate
2010-04-02T12:50:57.023
CreationDate
2009-02-11T18:55:20.617
FavoriteCount
0
LastActivityDate
2017-11-28T16:08:51.560
LastEditDate
2017-11-28T16:08:51.560
LastEditorUserId
18797
OwnerUserId
12597
ParentId
538060
PostTypeId
2
Score
2311
ViewCount
0
LastEditorDisplayName
text
Body
The point of Dispose is to free unmanaged resources. It needs to be done at some point, otherwise they will never be cleaned up. The garbage collector doesn't know how to call <code>DeleteHandle()</code> on a variable of type <code>IntPtr</code>, it doesn't know whether or not it needs to call <code>DeleteHandle()</code>. <blockquote> Note: What is an unmanaged resource? If you found it in the Microsoft .NET Framework: it's managed. If you went poking around MSDN yourself, it's unmanaged. Anything you've used P/Invoke calls to get outside of the nice comfy world of everything available to you in the .NET Framwork is unmanaged – and you're now responsible for cleaning it up. </blockquote> The object that you've created needs to expose some method, that the outside world can call, in order to clean up unmanaged resources. The method can be named whatever you like: <pre><code>public void Cleanup() public void Shutdown() </code></pre> But instead there is a standardized name for this method: <pre><code>public void Dispose() </code></pre> There was even an interface created, <code>IDisposable</code>, that has just that one method: <pre><code>public interface IDisposable { void Dispose() } </code></pre> So you make your object expose the <code>IDisposable</code> interface, and that way you promise that you've written that single method to clean up your unmanaged resources: <pre><code>public void Dispose() { Win32.DestroyHandle(this.CursorFileBitmapIconServiceHandle); } </code></pre> And you're done. Except you can do better. <hr> What if your object has allocated a 250MB <a href="http://msdn.microsoft.com/en-us/library/system.drawing.bitmap.aspx" rel="noreferrer">System.Drawing.Bitmap</a> (i.e. the .NET managed Bitmap class) as some sort of frame buffer? Sure, this is a managed .NET object, and the garbage collector will free it. But do you really want to leave 250MB of memory just sitting there – waiting for the garbage collector to eventually come along and free it? What if there's an <a href="http://msdn.microsoft.com/en-us/library/system.data.common.dbconnection.aspx" rel="noreferrer">open database connection</a>? Surely we don't want that connection sitting open, waiting for the GC to finalize the object. If the user has called <code>Dispose()</code> (meaning they no longer plan to use the object) why not get rid of those wasteful bitmaps and database connections? So now we will: <ul> <li>get rid of unmanaged resources (because we have to), and </li> <li>get rid of managed resources (because we want to be helpful)</li> </ul> So let's update our <code>Dispose()</code> method to get rid of those managed objects: <pre><code>public void Dispose() { //Free unmanaged resources Win32.DestroyHandle(this.CursorFileBitmapIconServiceHandle); //Free managed resources too if (this.databaseConnection != null) { this.databaseConnection.Dispose(); this.databaseConnection = null; } if (this.frameBufferImage != null) { this.frameBufferImage.Dispose(); this.frameBufferImage = null; } } </code></pre> And all is good, except you can do better! <hr> What if the person forgot to call <code>Dispose()</code> on your object? Then they would leak some unmanaged resources! <blockquote> Note: They won't leak managed resources, because eventually the garbage collector is going to run, on a background thread, and free the memory associated with any unused objects. This will include your object, and any managed objects you use (e.g. the <code>Bitmap</code> and the <code>DbConnection</code>). </blockquote> If the person forgot to call <code>Dispose()</code>, we can still save their bacon! We still have a way to call it for them: when the garbage collector finally gets around to freeing (i.e. finalizing) our object. <blockquote> Note: The garbage collector will eventually free all managed objects. When it does, it calls the <code>Finalize</code> method on the object. The GC doesn't know, or care, about your Dispose method. That was just a name we chose for a method we call when we want to get rid of unmanaged stuff. </blockquote> The destruction of our object by the Garbage collector is the perfect time to free those pesky unmanaged resources. We do this by overriding the <code>Finalize()</code> method. <blockquote> Note: In C#, you don't explicitly override the <code>Finalize()</code> method. You write a method that looks like a C++ destructor, and the compiler takes that to be your implementation of the <code>Finalize()</code> method: </blockquote> <pre><code>~MyObject() { //we're being finalized (i.e. destroyed), call Dispose in case the user forgot to Dispose(); //<--Warning: subtle bug! Keep reading! } </code></pre> But there's a bug in that code. You see, the garbage collector runs on a background thread; you don't know the order in which two objects are destroyed. It is entirely possible that in your <code>Dispose()</code> code, the managed object you're trying to get rid of (because you wanted to be helpful) is no longer there: <pre><code>public void Dispose() { //Free unmanaged resources Win32.DestroyHandle(this.gdiCursorBitmapStreamFileHandle); //Free managed resources too if (this.databaseConnection != null) { this.databaseConnection.Dispose(); //<-- crash, GC already destroyed it this.databaseConnection = null; } if (this.frameBufferImage != null) { this.frameBufferImage.Dispose(); //<-- crash, GC already destroyed it this.frameBufferImage = null; } } </code></pre> So what you need is a way for <code>Finalize()</code> to tell <code>Dispose()</code> that it should not touch any managed resources (because they might not be there anymore), while still freeing unmanaged resources. The standard pattern to do this is to have <code>Finalize()</code> and <code>Dispose()</code> both call a third(!) method; where you pass a Boolean saying if you're calling it from <code>Dispose()</code> (as opposed to <code>Finalize()</code>), meaning it's safe to free managed resources. This internal method could be given some arbitrary name like "CoreDispose", or "MyInternalDispose", but is tradition to call it <code>Dispose(Boolean)</code>: <pre><code>protected void Dispose(Boolean disposing) </code></pre> But a more helpful parameter name might be: <pre><code>protected void Dispose(Boolean itIsSafeToAlsoFreeManagedObjects) { //Free unmanaged resources Win32.DestroyHandle(this.CursorFileBitmapIconServiceHandle); //Free managed resources too, but only if I'm being called from Dispose //(If I'm being called from Finalize then the objects might not exist //anymore if (itIsSafeToAlsoFreeManagedObjects) { if (this.databaseConnection != null) { this.databaseConnection.Dispose(); this.databaseConnection = null; } if (this.frameBufferImage != null) { this.frameBufferImage.Dispose(); this.frameBufferImage = null; } } } </code></pre> And you change your implementation of the <code>IDisposable.Dispose()</code> method to: <pre><code>public void Dispose() { Dispose(true); //I am calling you from Dispose, it's safe } </code></pre> and your finalizer to: <pre><code>~MyObject() { Dispose(false); //I am *not* calling you from Dispose, it's *not* safe } </code></pre> <blockquote> Note: If your object descends from an object that implements <code>Dispose</code>, then don't forget to call their base Dispose method when you override Dispose: </blockquote> <pre><code>public Dispose() { try { Dispose(true); //true: safe to free managed resources } finally { base.Dispose(); } } </code></pre> And all is good, except you can do better! <hr> If the user calls <code>Dispose()</code> on your object, then everything has been cleaned up. Later on, when the garbage collector comes along and calls Finalize, it will then call <code>Dispose</code> again. Not only is this wasteful, but if your object has junk references to objects you already disposed of from the last call to <code>Dispose()</code>, you'll try to dispose them again! You'll notice in my code I was careful to remove references to objects that I've disposed, so I don't try to call <code>Dispose</code> on a junk object reference. But that didn't stop a subtle bug from creeping in. When the user calls <code>Dispose()</code>: the handle CursorFileBitmapIconServiceHandle is destroyed. Later when the garbage collector runs, it will try to destroy the same handle again. <pre><code>protected void Dispose(Boolean iAmBeingCalledFromDisposeAndNotFinalize) { //Free unmanaged resources Win32.DestroyHandle(this.CursorFileBitmapIconServiceHandle); //<--double destroy ... } </code></pre> The way you fix this is tell the garbage collector that it doesn't need to bother finalizing the object – its resources have already been cleaned up, and no more work is needed. You do this by calling <code>GC.SuppressFinalize()</code> in the <code>Dispose()</code> method: <pre><code>public void Dispose() { Dispose(true); //I am calling you from Dispose, it's safe GC.SuppressFinalize(this); //Hey, GC: don't bother calling finalize later } </code></pre> Now that the user has called <code>Dispose()</code>, we have: <ul> <li>freed unmanaged resources</li> <li>freed managed resources</li> </ul> There's no point in the GC running the finalizer – everything's taken care of. <h2>Couldn't I use Finalize to cleanup unmanaged resources?</h2> The documentation for <a href="https://msdn.microsoft.com/en-us/library/system.object.finalize.aspx" rel="noreferrer"><code>Object.Finalize</code></a> says: <blockquote> The Finalize method is used to perform cleanup operations on unmanaged resources held by the current object before the object is destroyed. </blockquote> But the MSDN documentation also says, for <a href="https://msdn.microsoft.com/en-us/library/system.idisposable.dispose(v=vs.110).aspx" rel="noreferrer"><code>IDisposable.Dispose</code></a>: <blockquote> Performs application-defined tasks associated with freeing, releasing, or resetting unmanaged resources. </blockquote> So which is it? Which one is the place for me to cleanup unmanaged resources? The answer is: <blockquote> It's your choice! But choose <code>Dispose</code>. </blockquote> You certainly could place your unmanaged cleanup in the finalizer: <pre><code>~MyObject() { //Free unmanaged resources Win32.DestroyHandle(this.CursorFileBitmapIconServiceHandle); //A C# destructor automatically calls the destructor of its base class. } </code></pre> The problem with that is you have no idea when the garbage collector will get around to finalizing your object. Your un-managed, un-needed, un-used native resources will stick around until the garbage collector eventually runs. Then it will call your finalizer method; cleaning up unmanaged resources. The documentation of Object.Finalize points this out: <blockquote> The exact time when the finalizer executes is undefined. To ensure deterministic release of resources for instances of your class, implement a Close method or provide a <a href="https://msdn.microsoft.com/en-us/library/system.idisposable.dispose(v=vs.110).aspx" rel="noreferrer"><code>IDisposable.Dispose</code></a> implementation. </blockquote> This is the virtue of using <code>Dispose</code> to cleanup unmanaged resources; you get to know, and control, when unmanaged resource are cleaned up. Their destruction is "deterministic". <hr> To answer your original question: Why not release memory now, rather than for when the GC decides to do it? I have a facial recognition software that needs to get rid of 530 MB of internal images now, since they're no longer needed. When we don't: the machine grinds to a swapping halt. <h2>Bonus Reading</h2> For anyone who likes the style of this answer (explaining the why, so the how becomes obvious), I suggest you read Chapter One of Don Box's Essential COM: <ul> <li>Direct link: <a href="http://ptgmedia.pearsoncmg.com/images/0201634465/samplechapter/chap01.pdf" rel="noreferrer">Chapter 1 sample by Pearson Publishing</a></li> <li>magnet: 84bf0b960936d677190a2be355858e80ef7542c0</li> </ul> In 35 pages he explains the problems of using binary objects, and invents COM before your eyes. Once you realize the why of COM, the remaining 300 pages are obvious, and just detail Microsoft's implementation. I think every programmer who has ever dealt with objects or COM should, at the very least, read the first chapter. It is the best explanation of anything ever. <h2>Extra Bonus Reading</h2> <a href="https://ericlippert.com/2015/05/18/when-everything-you-know-is-wrong-part-one/" rel="noreferrer">When everything you know is wrong</a> by Eric Lippert <blockquote> It is therefore very difficult indeed to write a correct finalizer, and the best advice I can give you is to not try. </blockquote>
Tags
Title
singulars
PostAcceptedAnswerId
1. This table or related slice is empty.
PostParentId
1. POProper use of the IDisposable interface
 singulars
 PostTypePostTypeId
 PTQuestion
PostTypePostTypeId
1. PTAnswer
UserLastEditorUserId
1. USBinary Worrier
UserOwnerUserId
1. USIan Boyd
plurals
PostLinksPostIdRelatedPostId
1. This table or related slice is empty.
PostLinksRelatedPostIdPostId
1. This table or related slice is empty.
PostsAcceptedAnswerId
1. POProper use of the IDisposable interface
 singulars
 PostTypePostTypeId
 PTQuestion
PostsParentIdCreationDate
1. This table or related slice is empty.
VotesPostIdCreationDate
1. VO
 singulars
 PostPostId
 PO
 UserUserId
 This table or related slice is empty.
 VoteTypeVoteTypeId
 VTUpMod
2. VO
 singulars
 PostPostId
 PO
 UserUserId
 This table or related slice is empty.
 VoteTypeVoteTypeId
 VTUpMod
3. VO
 singulars
 PostPostId
 PO
 UserUserId
 This table or related slice is empty.
 VoteTypeVoteTypeId
 VTUpMod
CommentsPostId

Querying!

Guidance

A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.