What are the methods to destroy Excel COM Interop objects in C#, besides these:
object_instance = null;
System.GC.collect();
&
System.Runtime.InteropServices.Marshal.ReleaseComObject(object);
Please suggest only inbuilt techniques, not other tools like bigcannon, etc.
The kicker is that if you haven't dropped all references to the object, even GC.Collect won't destroy it.
The rule in C# (or .NET generally) is that you can't destory an object. Dispose() won't do it. A finalizer won't do it (rule number 2, don't use a finalizer unless you know why you need it, and don't ever call it directly).
For .NET, these are the things you need to do:
If an object holds references to unmanaged objects, implement IDispose pattern. And implement it fully; it's more than just providing a Dispose() method.
The only reason to have a finalizer is to release unmanaged objects, and only in the event that your object hasn't been properly disposed. Once your dispose method is called, it should do the cleanup, then "kill" the finalizer by calling GC.SuppressFinalize.
If you are using an object that implements a Dispose() method, call Dispose() when you're done with that object. Best practices is to allocate that object with a using block. Exit from the using block will call Dispose() automatically.
When you are done with an object, drop all references to the object, including event handlers, delegates, etc.
Beyond that, trust the garbage collector to do its job. Don't mess with the garbage collector; you're only likely to make things worse, unless you really, really, really know what you're doing and why.
The garbage collector is the only mechanism that can destroy a managed object, but you usually don't invoke it explicitly. You just let it do its thing.
Just like you never take your own trash to the depot, you just leave it sitting on the corner. It's always the garbage man's responsibility.
You can release references to things and clean them up with IDisposable, finalizers and destructors but not destroy them.
By using System.GC you can ask the garbage man to do things early - request a custom run just for yourself - but this usually screws up his schedule and he has a lot more trash to deal with than just yours so it's not recommended.
For the most part, you have to remove all references to an object. Only then will the garbage collector see it and destroy it.
Be aware of this:
object_instance = null;
All this does is kill the object_instance reference. This works if it's the only reference. If there are other references, then it won't be collected.
var skywalker = new Person();
var object_instance = skywalker;
...
object_instance = null;
//It's still alive and won't be collected because skywalker lives...
If your object allocates significant resources, it's best to implement IDisposable and explicitly call Dispose. If you can't call Dispose for some reason and your class reserves unmanaged memory, you can use GC.AddMemoryPressure (with a matching GC.RemoveMemoryPressure in the finalizer) to tell the GC your class is heavier than it looks, prioritizing it for earlier cleanup.
If you really need to explicitly free the memory occupied by an object, and you are sure that you will choose the moment to exterminate it better than GC, then the only reasonable option is to allocate it on stack and let it die when you return from the method where it was allocated.
If you want control so that you can manage resources of the object, then implement the IDisposable interface.
http://msdn.microsoft.com/en-us/library/system.idisposable.aspx
If resources are not the reason why you want to explicitly control object destruction, I can't fathom why you want that level of control... Do you use object pooling?
Related
I am happy using IDisposable and using blocks but often I find myself writing (new Obj()).Foo(); to avoid the extra instantiation code and naming etc. Does this instance hang in memory until the end of the function scope or is it disposed of directly after the enclosing parenthesis is exited...? Is there an alternative I am missing? An equivalent to implementing IDisposable for concrete objects that I want to use once and throw away?
IDisposable is not related whit when the memory allocated for the object is released. In both cases the memory is released when the Garbage Collector decides to release it.
IDisposable is used for objects that need to execute some action in order to release the resources it allocates outside them. For example if the objects open a Database connection, you must release it as soon as you don't need it anymore.
So IDisposable gives you one thing:
A way to release the resources as soon as you want, by calling the Dispose() method or using the using clause
So it's ok to do:
new Obj()).Foo();
And has no sense to make Obj implements IDisposable if it does not uses any resource that must be deallocated.
If an object implements IDisposable, it is imperative that you Dispose() the object in your own code, either explicitly (and within a try/finally construct, too!) or with the using syntax, and do not simply let the reference(s) fall out of scope.
EDIT: I feel like I used an awful lot of words to get around to explaining the most important aspect of all this, which is that the only reason an object should implement IDisposable is if it holds handles to other objects that are unmanaged (the CLR doesn't know about them) or scarce (due to resources/cost/licensing/etc.). So if an object implements IDisposable, you MUST call Dispose() YOURSELF, as soon as possible. The CLR will not do it for you. And if you implement IDisposable on your own classes, you need to be implementing a finalizer on them, too.
Simply letting a reference fall out of scope does not cause the GC to run immediately, and you have no guarantees whatsoever that a GC is going to occur any time soon. You can explicitly trigger a GC with code, but that is typically going to hurt overall performance more than help it.
If there is not much memory pressure, for instance, the CLR may wait a long time before running the GC. There just isn't a pressing need for it to run in a situation where there is light or zero contention for resources. If it ran too often, it would impact the performance of your applications negatively
The GC does not call Dispose(). The GC calls an object's finalizer if it has one. The finalizer is a special method using syntax similar to a C++ destructor, but which really is not a destructor in that sense.
So if an object implements IDisposable, but does not implement a finalizer, the GC will never release that object's resources. The object will cause both memory leaks and unresolvable resource contention.
Nor does calling Dispose() from your own code trigger a GC.
The finalizer is a last-ditch backup mechanism to try to ensure that a class holding scarce or expensive resources does eventually let go of them even if consumers of the class fail to explicitly release those resources.
IDisposable is really just a common convention, implemented with a handy well-known interface contract, to let callers generically request that any class holding scarce resources release those resources immediately.
The standard pattern is that the finalizer calls the Dispose() method (actually, it typically calls Dispose(false) and I'm intentionally ignoring that detail). The Dispose() method will release all the scarce resources, then it can call GC.SuppressFinalize() so that the GC can free the object's memory more quickly when it gets around to running.
The old tried and true "acquire late/release early" semantics apply here.
You should read up on how the GC uses multiple passes or "generations" to clean up objects with finalizers.
The GC can get rid of regular objects (objects where all the resources are managed by the CLR) in one pass. If there are no in-scope references to an object, the GC can basically just delete it.
But if an object has a finalizer (and GC.SuppressFinalize() has not been called), the GC uses at least 2 passes or generations to release the object. In the first generation, it marks the object for finalization. In the second generation (which happens the next time the GC runs), it actually calls the finalizer, and at that point the object is finally eligible to have its memory released.
The scarce/expensive resources we're talking about are typically things like network sockets, file handles, database or other server connections which may be limited or expensive or resource-intensive or all three, etc. This is also true of virtually all "unmanaged" (non .NET CLR) resources, including things like Win32 window handles, file handles, network sockets and so on. Such resources require deterministic cleanup. You need to let go of them as quick as you can, but the CLR is going to take its sweet time getting around to cleaning this stuff up. You have to do it yourself.
But if your class isn't using any of these types of scarce/expensive/"unmanaged" resources, then there is probably no reason to implement IDisposable on it at all.
What is the difference between System.GC.Collect and Dispose()?
Aren't they used for the same purpose, and when should each be used; what is the best practice?
Best practice is to never need to call GC.Collect, and to call Dispose on all IDisposable objects when you're done with them.
The purpose of GC.Collect is to to tell the Garbage collector that there are some objects in the memory that can be collected and it is the right time to collect. Though, as a rule of thumb you should leave that to GC itself. It is designed to do this job.
If there are some resources in your object that you think GC won't take care of. You should implement Dispose and take care of them yourself. You need to call Dispose Explicitly to dispose the resources you want. And if you are implementing IDisposable than you can also do that by the Using statement.
System.GC.Collect is called when all objects which are there in memory are to be collected by the Garbage Collector. Objects which are referenced in managed code are not considered for Garbage collection. This method is used to force the system to reclaim the available memory.
Dispose() is not part of GC but as better practice you can use this. It should only be used for objects which uses unmanaged resources like FileStream etc. It should release all the resources that it owns. When you know that certain resources will not be released by GC then you can use the Dispose() method.
The using statement ensures the correct use of IDisposable objects.
On a side note: The GC does not call Dispose, it calls the finalizer(which you should call from Dispose(false))
Also, to make ensure that resources are always released appropriately, a Dispose method should be callable multiple times without throwing an exception.
MSDN says:
"It is possible to force garbage collection by calling Collect, but
most of the time, this should be avoided because it may create
performance issues. "
Check this blog:-
GC.Collect() asks the system to perform a collection "now". You
shouldn't mess with this; the system usually has a much better idea
than you do of when collection is necessary.
So is the best practice:
You can use the using block or as you mentioned use the Dispose method.
Why should you use IDisposable and Dispose?
MSDN says
In many cases it is possible for objects that would otherwise always
need to be finalized to avoid that cost by implementing the
IDisposable interface. This interface provides an alternative method
for reclaiming resources whose lifetime is well known to the
programmer, and that actually happens quite a bit. Of course it's
better still if your objects simply use only memory and therefore
require no finalization or disposing at all; but if finalization is
necessary and there are many cases where explicit management of your
objects is easy and practical, then implementing the IDisposable
interface is a great way to avoid, or at least reduce, finalization
costs.
Also check this article on Improve garbage collector performance using finalize/dispose pattern
In trying to understand the IDisposable i have a few questions that most answers haven't explicitly stated.
If we call dispose on an object, does that dispose the object at that time or just class members that we would like to clean up, and the whole object would be destroyed later by the GC.
After we suppress the finalizer in the dispose method, will the GC still clean up all the class members we didn't clean up in the dispose?
An object will be garbage collected once all references to it are gone, in a non-deterministic way. Garbage collection
from MSDN : Garabge collection fundamentals
Garbage collection occurs when one of the following conditions is
true:
The system has low physical memory.
The memory that is used by allocated objects on the managed heap
surpasses an acceptable threshold. This means that a threshold of
acceptable memory usage has been exceeded on the managed heap. This
threshold is continuously adjusted as the process runs.
The GC.Collect method is called. In almost all cases, you do not have
to call this method, because the garbage collector runs continuously.
This method is primarily used for unique situations and testing.
Garabge collection when to use
Understanding Object life cycle
First things first, there is a ton of duplicate questions here on this topic. If truly none other answer explicitly answers your question, here they are, but I expect this to be closed as a duplicate.
First, Dispose is just a method, an ordinary method. It does not deal with Garbage Collection at all.
So what does Dispose do? It should be used to clean up unmanaged resources, such as file handles, window handles, etc. Things that the .NET garbage collector does not know about.
So to answer question 1: "Yes", when you call Dispose on an object, it is disposed there and then. There is no mark set on the class to indicate cleanup later on.
Since Dispose does not deal with Garbage Collection, you can easily keep a reference to the object after disposing it, and it will not be garbage collected. Garbage collection only occurs when there are no more references to the object. This can happen even if you have not called Dispose on the object, but it will not happen because you call Dispose on the object.
Second question: When GC collects the object after it has been through the finalizer cycle, then GC will clean up the object + any object it refers to that no longer has any references left (besided the one from your object). This happens at some point, and not necessarily all at once either.
Suppressing the finalizer is just making sure GC does not do more work than necessary, by saying that "when you find this object and determine that it is eligible for collection, then just go ahead and collect it, I have taken care of the 'finalization' cleanup so you don't have to".
Firstly and most important you need to understand that disposing an object and garbage collecting an object are completely different things - make sure that you don't confuse the two!
If we call dispose on an object the only thing that happens is that the Dispose method gets called. It might be that the Dispose method then goes on to call GC.SuppressFinalize, but then again it might not do anything at all - its completely up to the implementation.
When we call GC.SuppressFinalize the only thing that happens is that it requests that the GC not call the objects finalizer when the object is collected (almost as if the object didn't have a finalizer in the first place).
As it happens a common pattern is for objects which have a finalizer to also implement IDisposable so that unmanaged resources can be cleaned up deterministicly - if this happens then there is no need for the GC to call the finalizer as the work that would have been done in the finalizer has already been performed when we called Dispose - calling GC.SuppressFinalize is just a friendly hint to the GC that it doesn't really need to call the finalizer after all.
1) When you call dispose on an object, all that happens is that the code in its Dispose() method is run. This code may of course call Dispose() for one or more of its fields, but it's not required to.
It may also call the base class' Dispose(true), if any (via base.Dispose()), but that is using the Dispose Idiom; Dispose(bool) is NOT part of the IDisposable interface.
2) The finalizer is suppressed only for the specific object for which SuppressFinalize() was called. It won't affect any other objects (including any held by fields of the object for which SuppressFinalize() was called).
This is pretty much only for me to make sure, I got this right:
We have a large resource class implementing the IDisposal pattern. It should (by design) be implemented in a way, that enables it to get called more than one time (even if we try to call it exactly one time of course). We also implement a finalizer, which also calls the Dispose() method - just as backup. If called manually, Dispose() will also call GC.SuppressFinalize(this).
There are several examples of disposal patterns around. Most of them call GC.SuppressFinalize(this) at the end of the disposing code. Some claim, it would be better, to call it at the beginning of the Dispose() method, before any cleaning. Latter argue, this would make sure, the GC doesn't call the finalizer concurrently, while we are still cleaning up.
Question:
It seems, placing GC.SuppressFinalize at the beginning doesn't do any better? We still have a race condition, right? So is it true, that we rather should implement Dispose() in a thread safe way instead?
The GC only cleans up objects that are not 'reachable'.
A class in which code is executing is still 'reachable' because it's this pointer is on the stack. So while dispose is executing, the finalizer won't be called.
So it does not matter if you call SuppressFinalize at the begin or end.
As commentors below indicated, the CLR implementation does not appear to guarantee that your object does not get garbage collected/finalized while instance methods are executing. The only possible 'dependable' reference keeping the object alive is the one used to invoke the method on the object, but I don't know enough about the JIT internals to make statements about that, and it's behaviour might change.
I'm leaving the answer here for access to the discussion below.
While it is sometimes possible for an object to be finalized while a seemingly-live reference exists, that can only happen when nothing else is going to ever refer to the object. The GC.SuppressFinalize(this) actively refers to the present object 'this', thus guaranteeing that it will not be finalized until the GC.SuppressFinalize executes. Further, the fact that the object reference existed to dispose the object, and was available to the Dispose method, guarantees that the finalizer couldn't have been queued before Dispose started running unless the object was dead and a finalizer somewhere (either its own finalizer, or that of some other object) resurrected it.
Because there are some scenarios where an object could be scheduled for finalization and resurrected without ever being aware of it, it may not be a bad idea to protect a dispose and finalize against redundant operation. Microsoft's pattern is not a good one, however. Finalizable objects shouldn't hold references to any objects not needed for finalization. If an object would hold a mixture of managed and unmanaged resources, the unmanaged resources should be moved into their own classes (effectively turning them into managed resources), so then the main object would hold nothing but managed resources.
Dispose should not throw any exceptions.
I would make sure all the code in Dispose is thread safe so that if it gets called it will not do anything strange. Usually adding checks if variables are null already should do the trick.
In the microsoft examples i've only seen GC.SuppressFinalize at the end of the Dispose function.
Three questions:
What kind of variables should be disposed manually in .NET/Java? I know that SqlConnection should always be either disposed manually or used in a using{} block. Is it right? What are the other kind of variables that should be disposed?
I read somewhere that unmanaged code must be disposed manually. Is that right? What exactly is unmanaged code and how do I know if a variable is managed or unmanaged?
Finally, how do I dispose variables? I know that the Dispose() method does not really dispose a variable. So what does Dispose() do? Should I set them to null()? What is the logic by which the garbage collector works?
This answer deals only with the .NET part of your question
What kind of variables should be disposed manually in .NET/Java? I know
that SqlConnection should always be
either disposed manually or used in a
using{} block. Is it right? What are
the other kind of variables that
should be disposed?
In .NET, all objects that implement IDisposable should be disposed explicitly (or used in a using block).
I read somewhere that unmanaged code must be disposed manually. Is
that right? What exactly is unmanaged
code and how do I know if a variable
is managed or unmanaged?
You probably mean unmanaged resources, as code can't be disposed... All classes that use unmanaged resources (memory allocated not on the managed heap, win32 handles...) should implement IDisposable, and should be disposed explictly, since they are not managed by the garbage collector.
Finally, how do I dispose variables? I know that the Dispose()
method does not really dispose a
variable. So what does Dispose() do?
Should I set them to null()? What is
the logic by which the garbage
collector works?
I'm not sure I understand your question... you don't dispose a variable, it is managed by the garbage collector. All managed memory is automatically released when it's not used anymore (i.e. it is not accessible by code because there are no references left to it). The IDisposable.Dispose method is only intended for resources that are not managed by the GC.
EDIT: as a side note, I would like to add that IDisposable is primarily intended to clean-up unmanaged resources, but is also frequently used to perform other cleanup actions and guarantee state or data integrity. For instance, IDbTransaction implements IDisposable in order to rollback the transaction if an exception occurs before the transaction was committed :
using (var trx = connection.BeginTransaction())
{
// Do some work in the transaction
...
// Commit
trx.Commit();
} // the transaction is implicitly rolled back when Dispose is called
In Java, you "close" rather than "dispose".
JDBC Connections, unless you got them from a pool.
JDBC ResultSets, depending on the JDBC connector.
InputStreams, OutputStreams, Readers and Writers (with the exception of those that are byte array and string backed).
Some third-party Java libraries or frameworks have classes that need to be manually disposed / closed / destroyed.
.NET
All objects that implement the IDisposable interface are asking that their Dispose methods are called when they are no longer required. The using block is just C# sugar for a try-finally block that disposes the IDiposable in the finally block, as long as it is not null. Consequently, disposal occurs even if an exception is thrown in the try block.
Unmanaged Code.
The Dispose method does whatever code the developer who wrote the Dispose method put in it! Typically this involves releasing 'unmanaged' resources, which are not managed by the runtime, such as database connections, window handles and file handles. Note that the GC manages the heap, so setting a reference to null just before the object it references becomes unreachable doesn't help all that much.
This is a good read.
This was mostly covered by Thomas, but to expand on the third point:
Finally, how do I dispose variables? I know that the Dispose()
method does not really dispose a
variable. So what does Dispose() do?
Should I set them to null()? What is
the logic by which the garbage
collector works?
They key is that the Dispose() tells the object to free any unmanaged resources that it currently holds, it does not free the object itself.
The garbage collector knows how to free the object, but for IDisposable objects, only the object itself knows how to dispose of it's private resources, so you have to make sure that Dispose() gets called before the garbage collector frees the object.
For Java:
SWT is a framework where we have to dispose resources (like images), because the framework uses native libs and system handles which have to released. SWT classes are documented and tell, when dispose is required.
Following up on other .NET solutions...
If your object owns unmanaged resources, it's not enough to simply clean them up on Dispose() calls, because you have no guarantee that Dispose will get called. The full solution is:
Add a finalizer for the class.
Add a public bool property called Disposed, which indicates that the object has been disposed.
Add a protected Dispose(bool) method. The public Dispose() method has no parameters.
When Dispose() is called, if the Disposed property is false, it will call Dispose(true), and call GC.SuppressFinalize() to disable the finalizer. Ths is essential to keep .NET's garbage collector happy. Classes with unspressed finalizers go to the end of the line for garbage collector cleanup, so they become almost a memory leak.
The public Dispose() method should then set the Disposed property to true.
The finalizer calls Dispose(false).
The Dispose(bool) will always clean up its own managed resources, but it will clean up unmanaged resources only when called as Dispose(true). Note that all resource cleanup is in the protected Dispose(bool) method, not in the public Dispose() method.
If the class is not sealed, then the protected Dispose(bool) method should be a virtual method. Subclasses that need to do cleanup can override Dispose(bool) and followht e same logic as above. In addition, they should call base.Dispose(bool) with the parameter they were given.
If .net, if you can use an object in a "using" statement, that means the object implements iDisposable and you should when practical call it's disposal method when you're done with it. Note that the disposal method may not always be called "Dispose", but you can always call it by casting the object to iDisposable and then calling Dispose on that.
Note that some types of "iDisposable" objects don't handle any unmanaged resources, but do subscribe to events. If such an object isn't properly disposed, it might not get garbage-collected unless or until all of the objects for which it holds subscribed events are themselves garbage-collected. In some cases, that may never happen until an application exits.
For example, the enumerator returned by an iEnumerable collection might subscribe to that object's "collection changed" event, unsubscribing when its dispose method is called. If the dispose method is never called, the enumerator would remain around as long as the collection did. If the collection itself stayed around a long time and was enumerated frequently, this could create a huge memory leak.
I'm in agreement with the above, I'll just add to the subsequent question about setting a variable to null.
You don't need to do this with variables used in a method (they will fall out of scope so it's only if they have state within them that must be signalled as needing clean-up, through IDisposable.Disopse that you have to worry abou this).
It's rarely useful for instance or static members, as memory isn't as precious a resource as people often think (it is a precious resource, but most attempts to deal with it in a few lines of code is like turning off your taps while you've a burst main.
It is though useful if you have a static or instance member of a class and (A) it is a large object (B) the "owning" object is likely to stay in memory for a long time and (C) you know you won't need that value gain, to set that member to null.
In practice this isn't a very common combination. If in doubt, just leave alone.
Now, do read the other answers here, as what they say about the Dispose() method is much more important.