开发者

IDisposable Interface

开发者 https://www.devze.com 2023-01-19 18:36 出处:网络
I know about IDisposable Interface and it\'s use in .net but there is a question in my mind that If i am wri开发者_JS百科ting all managed code , does implementing IDisposable interface make any sense?

I know about IDisposable Interface and it's use in .net but there is a question in my mind that If i am wri开发者_JS百科ting all managed code , does implementing IDisposable interface make any sense?

i know when and how to use Idisposible but my question is if i am writing all managed code say a simple class nothing expensive in it so if i implement IDisposable in this class and do some cleanup like freeing some global values, Does it make some sense?


No, you may not need to use IDisposble interface. However, it's recommended under certain circumstances (I might add later more as I remember :) ):

  1. You class has many objects and there are of lots of cross references. Even though its all managed, GC may not be able to reclaim the memory due to alive references. You get a chance (other than writing a finalizer) to untangle the references and break up the links the way you attached them. Hence, you are helping the GC to reclaim the memory.

  2. You have some streams open which are alive till the object of the class dies. Even though such implementations of files/network etc are managed, they go deep down to handles in Win32 mode. Hence, you get a chance to write a Dispose method where you can close the streams. The same is true for GDI objects, and some more.

  3. You are writing a class which uses unmanaged resources, and you want to ship your assembly to third parties. You better use disposable pattern to make sure you are able to free the handles to avoid the leakage.

  4. Thanks to supercat for this: Your class implements lots of event handlers and hooks them up to events. The objects of classes which expose the events, like Form etc., will not be freed up by GC since the implementations local to your class (maybe) are still hooked into those events. You can unhook those event handlers in Dispose; again helping GC.

Hmm... I can't remember more right now, but if the class is complex in its behaviours, you might want to rethink why you don't want implement IDisposable interface.


Rule of thumb: you need to implement IDisposable if your type has a member variable that is itself IDisposable or if it is unmanaged. GC is non-deterministic in .NET and IDisposable gives you a deterministic way not to reclaim memory but to reclaim resources. So when Dispose() is invoke, your memory is not immediately freed by the GC but you can clean up unmanaged resources deterministically (e.g., ensure your database connections are closed and you don't max connections on the server).


If you have a resource that needs to be reclaimed (like File) you want to have IDisposible in order to explicitly close it and not wait for the GC todo it.


A seldom-mentioned scenario where proper use of iDisposable is critical is an object with a short useful life that receives events from a long-lived object. The Dispose method for such an object must unsubscribe its events. If the object does not unsubscribe itself, it will not be eligible for garbage-collection until the object(s) whose events it has subscribed become eligible for garbage collection; that may very well be never.

For example, some types of enumerator need to subscribe to "object changed" messages. It would be entirely plausible for many thousands of such enumerators to be created during the execution of a long-running program. If such enumerators were not unsubscribed, they could effectively clog the system, even if they never use any resources other than managed memory.

Note, btw, that despite the importance of disposing of such an object, adding a finalizer to ensure such disposal would be useless. If an event publisher has gone out of scope, attempting to unsubscribing from one of its events would be at best useless and possibly dangerous. Since an event subscriber can't go out of scope unless the publishers of all the events it receives have also gone out of scope, the finalizer would only get called after there was nothing left for it to do.


Yes, even when you do not have any managed resources around, IDisposable can still be helpful. Why? Because you can use the Dispose method to reset object references back to null.

Note that this by itself doesn't yet free any resources, since garbage collection is non-deterministic (ie. it doesn't normally run at any moment of your choosing), BUT it breaks up references (links) between objects, making it more probable that some objects will be eligible for garbage collection on the GC's next run.


Does it make some sense?

No, make your object disposable only if it is expensive to create.

0

精彩评论

暂无评论...
验证码 换一张
取 消