Develop Reference

In C# Can I stop an object from being garbage collected, from the finalizer?

Or is it already to late if the finalize method is reached?
Basically I'm creating some code to log to a MySql database. Each log entry is represented by an object and stored in a queue until it gets flushed to the database in a batch insert / update. I figured it'd be inefficient to create a new object on the heap every time I wanted to write an entry (especially since I might want to write an entry or two in performance sensitive areas). My solution was to create a pool of objects and reuse them.
Basically I'm trying to not re-invent the wheel by letting the .Net Garbage Collector let me know when an object is no longer needed and can be added back to the pool. The problem is I need away to abort garbage collection from the destructor. Is that possible?

Can you? Yes.
Should you? No, it is almost certainly a terrible idea.
The general rule C# developers should remember is the following:
If you find yourself writing a finalizer, you probably did something wrong.
The memory allocators used by well-established managed VMs (such as the CLR or JVM) are extremely fast. One of the things that slows down the garbage collector in these systems is the use of customized finalizers. In an effort to optimize the runtime, you are actually giving up a very fast operation in favor of a much slower operation. Furthermore, the semantics of "bringing an object back to life" are difficult to understand and reason about.
Before you consider using a finalizer, you should understand everything in the following articles.
Never write a finalizer again (well, almost never)
DG Update: Dispose, Finalization, and Resource Management

Connection pooling is a feature virtually any major DB connection implementation is already going to natively support, so there is no reason to handle this manually. You'll be able to simply create a new connection for each operation and know that behind the scenes the connections will actually be pooled.
To answer the literal question that you asked, yes. You can ensure that an object is not going to be GCed after it is finalized. You can do so simply by creating a reference to it from some "live" location.
This is a really bad idea though. Take a look at this example:
public class Foo
{
public string Data;
public static Foo instance = null;
~Foo()
{
Console.WriteLine("Finalized");
instance = this;
}
}
public static void Bar()
{
new Foo() { Data = "Hello World" };
}
static void Main(string[] args)
{
Bar();
GC.Collect();
GC.WaitForPendingFinalizers();
Console.WriteLine(Foo.instance.Data);
Foo.instance = null;
GC.Collect();
GC.WaitForPendingFinalizers();
}
This will print out:
Finalized
Hello World
So here we had an object end up being finalized, and we then accessed it later on. The problem however is that this object has been marked as "finalized". When it is finally hit by the GC again it's not finalized a second time.

You could re-register for finalization in the destructor, like so:
~YourClass()
{
System.GC.ReRegisterForFinalize(this);
}
And from there you'd probably want something to reference so it doesn't get finalized again, but this is a way to do it.
http://msdn.microsoft.com/en-us/library/system.gc.reregisterforfinalize(v=vs.110).aspx

Store 'this' at finalization

How could be defined a code that store 'this' during class finalization? How the garbage collector should behave (if defined somewhere)?
In my mind the GC should finalize multiple times the class instance, and the following test application shall print "66", but the finalizer is executed only once, causing the application to print "6".
Few lines of code:
using System;
namespace Test
{
class Finalized
{
~Finalized()
{
Program.mFinalized = this;
}
public int X = 5;
}
class Program
{
public static Finalized mFinalized = null;
static void Main(string[] args)
{
Finalized asd = new Finalized();
asd.X = 6;
asd = null;
GC.Collect();
if (mFinalized != null)
Console.Write("{0}", mFinalized.X);
mFinalized = null;
GC.Collect();
if (mFinalized != null)
Console.Write("{0}", mFinalized.X);
}
}
}
What I'm trying to do is to understand how finalizers manage instance memory. In my application could be desiderable to re-use instance reference again for further processing.
It's clear that the finalizer doesn't "free" memory (at least in my test application). May the memory chunk be reused for other purposes? Or even freed? And if it isn't, that would be a memory leak or what?
Now, I'm confused more than before.

This is due to Resurrection. By storing the object in another variable during finalization (assigning this to a variable), you resurrect the obejct instance as far as the GC is concerned. You are allowed to resurrect your object in .NET, and you can actually cause the GC to finalize the object more than once, but you have to explicitly request it via GC.ReRegisterForFinalize .
For details, see Automatic Memory Management in the Microsoft .NET Framework.

GC.Collect does a sweep, special-casing any objects with a finalizer and not collecting them. Once these finalizer objects have finalized, GC then runs again over these objects. If they're no longer eligible for collection (by re-rooting, as you do), so be it. Normally the finalizer only runs once, but IIRC, you can request that it runs again.

Finalizer only gets called once. You're free to assign self to somewhere, and prevent the object being garbage collected. But once the object is available again for GC, it doesn't run the finalizer.

I'm interested in any good uses of resurrected objects.
The MSDN states "There are very few good uses of resurrection, and you really should avoid it if possible".
Also Bill Wagner in his Effective C# says "You cannot make this kind of construct work reliably. Dont try". But the book is 2 years old so maybe something changed?

Which objects can I use in a finalizer method?

I have a class that should delete some file when disposed or finalized. Inside finalizers I can't use other objects because they could have been garbage-collected already.
Am I missing some point regarding finalizers and strings could be used?
UPD: Something like that:
public class TempFileStream : FileStream
{
private string _filename;
public TempFileStream(string filename)
:base(filename, FileMode.Open, FileAccess.Read, FileShare.Read)
{
_filename = filename;
}
protected override void Dispose(bool disposing)
{
base.Dispose(disposing);
if (_filename == null) return;
try
{
File.Delete(_filename); // <-- oops! _filename could be gc-ed already
_filename = null;
}
catch (Exception e)
{
...
}
}
}

Yes, you can most certainly use strings from within a finalizer, and many other object types.
For the definitive source of all this, I would go pick up the book CLR via C#, 3rd edition, written by Jeffrey Richter. In chapter 21 this is all described in detail.
Anyway, here's what is really happening...
During garbage collection, any objects that have a finalizer that still wants to be called are placed on a special list, called the freachable list.
This list is considered a root, just as static variables and live local variables are. Therefore, any objects those objects refer to, and so on recursively is removed from the garbage collection cycle this time. They will survive the current garbage collection cycle as though they weren't eligible to collect to begin with.
Note that this includes strings, which was your question, but it also involves all other object types
Then, at some later point in time, the finalizer thread picks up the object from that list, and runs the finalizer on those objects, and then takes those objects off that list.
Then, the next time garbage collection runs, it finds the same objects once more, but this time the finalizer no longer wants to run, it has already been executed, and so the objects are collected as normal.
Let me illustrate with an example before I tell you what doesn't work.
Let's say you have objects A through Z, and each object references the next one, so you have object A referencing object B, B references C, C references D, and so on until Z.
Some of these objects implement finalizers, and they all implement IDisposable. Let's assume that A does not implement a finalizer but B does, and then some of the rest does as well, it's not important for this example which does beyond A and B.
Your program holds onto a reference to A, and only A.
In an ordinary, and correct, usage pattern you would dispose of A, which would dispose of B, which would dispose of C, etc. but you have a bug, so this doesn't happen. At some point, all of these objects are eligible for collection.
At this point GC will find all of these objects, but then notice that B has a finalizer, and it has not yet run. GC will therefore put B on the freachable list, and recursively take C, D, E, etc. up to Z, off of the GC list, because since B suddenly became in- eligible for collection, so does the rest. Note that some of these objects are also placed on the freachable list themselves, because they have finalizers on their own, but all the objects they refer to will survive GC.
A, however, is collected.
Let me make the above paragraph clear. At this point, A has been collected, but B, C, D, etc. up to Z are still alive as though nothing has happened. Though your code no longer has a reference to any of them, the freachable list has.
Then, the finalizer thread runs, and finalizes all of the objects in the freachable list, and takes the objects off of the list.
The next time GC is run, those objects are now collected.
So that certainly works, so what is the big bruaha about?
The problem is with the finalizer thread. This thread makes no assumptions about the order in which it should finalize those objects. It doesn't do this because in many cases it would be impossible for it to do so.
As I said above, in an ordinary world you would call dispose on A, which disposes B, which disposes C, etc. If one of these objects is a stream, the object referencing the stream might, in its call to Dispose, say "I'll just go ahead and flush my buffers before disposing the stream." This is perfectly legal and lots of existing code do this.
However, in the finalization thread, this order is no longer used, and thus if the stream was placed on the list before the objects that referenced it, the stream is finalized, and thus closed, before the object referencing it.
In other words, what you cannot do is summarized as follows:
You can not access any objects your object refer to, that has finalizers, as you have no guarantee that these objects will be in a usable state when your finalizer runs. The objects will still be there, in memory, and not collected, but they may be closed, terminated, finalized, etc. already.
So, back to your question:
Q. Can I use strings in finalizer method?
A. Yes, because strings do not implement a finalizer, and does not rely on other objects that has a finalizer, and will thus be alive and kicking at the time your finalizer runs.
The assumption that made you take the wrong path is the second sentence of the qustion:
Inside finalizers I can't use other objects because they could have been garbage-collected already.
The correct sentence would be:
Inside finalizer I can't use other objects that have finalizers, because they could have been finalized already.
For an example of something the finalizer would have no way of knowing the order in which to correctly finalize two objects, consider two objects that refer to each other and that both have finalizers. The finalizer thread would have to analyze the code to determine in which order they would normally be disposed, which might be a "dance" between the two objects. The finalizer thread does not do this, it just finalizes one before the other, and you have no guarantee which is first.
So, is there any time it is safe to access objects that also have a finalizer, from my own finalizer?
The only guaranteed safe scenario is when your program/class library/source code owns both objects so that you know that it is.
Before I explain this, this is not really good programming practices, so you probably shouldn't do it.
Example:
You have an object, Cache, that writes data to a file, this file is never kept open, and is thus only open when the object needs to write data to it.
You have another object, CacheManager, that uses the first one, and calls into the first object to give it data to write to the file.
CacheManager has a finalizer. The semantics here is that if the manager class is collected, but not disposed, it should delete the caches as it cannot guarantee their state.
However, the filename of the cache object is retrievable from a property of the cache object.
So the question is, do I need to make a copy of that filename into the manager object, to avoid problems during finalization?
Nope, you don't. When the manager is finalized, the cache object is still in memory, as is the filename string it refers to. What you cannot guarantee, however, is that any finalizer on the cache object hasn't already run.
However, in this case, if you know that the finalizer of the cache object either doesn't exist, or doesn't touch the file, your manager can read the filename property of the cache object, and delete the file.
However, since you now have a pretty strange dependency going on here, I would certainly advice against it.

Another point not yet mentioned is that although one might not expect that an object's finalizer would ever run while an object is in use, the finalization mechanism does not ensure that. Finalizers can be run in an arbitrary unknown threading context; as a consequence, they should either avoid using any types that aren't thread-safe, or should use locking or other means to ensure that they only use things in thread-safe fashion. Note finalizers should use Monitor.TryEnter rather than Monitor.Enter, and endeavor to act as gracefully as possible if a lock is unexpectedly held. Note that since finalizers aren't supposed to run while an object is still in use, the fact that a lock was unexpectedly held will often suggest that a finalizer was run early. Depending upon the design of the code which uses the lock, it may be possible to have the finalizer set a flag and try again to acquire the lock, and have any other code which uses the lock check after releasing it whether that flag is set and, if so, reregister the object for finalization.
Handling finalization cleanup correctly in all threading scenarios is difficult. Finalization might not seem complicated, but no convenient automated mechanisms exist by which objects can ensure that finalizers won't run while the objects in question are in use. Consequently, finalizers have a lot of subtle thread-safety issues. Code which ignores such issues will "usually" work, but may sometimes fail in difficult-to-diagnose ways.

You can call the dispose method inside your finalizer and have the file cleanup code in the Dispose method. Along with that you can also pass a boolean to your dispose method that indicates that you are invoking it from the finalizer.
For an excellent reference on the proper usage of Dispose and Fianlizers , read this Proper use of the IDisposable interface

Variables with function scope

How the CLR handles local variables with function scope in case an exception is thrown.
is it a must to use the finally block or the variable is disposed once the flow leaves the function
below is a small example
protected void FunctionX()
{
List<Employee> lstEmployees;
try
{
lstEmployees= new List<Employee>();
int s = lstEmployees[1].ID; // code intended to throw exception
}
catch (Exception ex)
{
ManageException(ex, ShowMessage); //exception is thrown here
}
finally { lstEmployees= null; } // Is the finally block required to make sure the list is cleaned
}

To answer your specific question, no, the finally block you've listed is not required.
Assigning null to a reference variable does not actually do anything, as garbage collection is non-deterministic. As a simplistic explanation, from time to time, the garbage collector will examine the objects within the heap to determine if there are any active references to them (this is called being "rooted"). If there are no active references, then these references are eligible for garbage collection.
Your assignment to null is not required, as once the function exits, the lstEmployees variable will fall out of scope and will no longer be considered an active reference to the instance that you create within your try block.
There are certain types (both within .NET and in third-party libraries) that implement the IDisposable interface and expose some deterministic cleanup procedures through the Dispose() function. When using these types, you should always call Dispose() when you're finished with the type. In cases where the lifetime of the instance shouldn't extend outside of the lifetime of the function, then you can use a using() { } block, but this is only required if the type implements IDisposable, which List<T> (as you used in your example) does not.

Don't be worried about the objects cleanup, that's why the .NET and most modern languages provide the garbage collection functionality in runtime.
If your object has a handle to unmanaged resource do that cleanup.

Some of the other answers are slightly misleading here.
In fact, the garbage collector has got (almost) nothing to do with the variable lstEmployees. But it never needs to be set to null, neither in normal code flow nor after an exception is thrown.
Setting references to null to free the object they point they point to is almost never required, especially not for local objects.
As a consequence, the garbage collector won’t care about the exception either.
On the other hand, unmanaged resources which aren’t handled by the CG do always require manual cleanup (via the Dispose method of the IDisposable interface). To make sure that such resources are returned after an exception was thrown, you indeed need the finally clause. Or, if you don’t intend to handle the exception locally, you can replace the try … finally by a using clause:
using (someUnmanagedResource) {
// … use the resource …
}
// Will implicitly call someUnmanagedResource.Dispose() *whatever happens*!

.NET languages are garbage collected, which means that objects lifetimes are kept track of, so the garbage collection will get rid of your list when it finds no more object references to it.

Not at all. When the variable is out of scope, the garbage collector will take care of it (when the GC decides it's time to collect all the garbage...)
The only thing you have to take in account is that maybe you don't want to wait for the GC to do its job, so resources help by an instance of a class are released (e.g. imagine you have locally created an instance that hols a reference to a database connection. The connection will be held until GC takes care of deleting the instance, and later on deleting the referenced connection, which may take a while).
In these cases, take a look at the IDisposable interface, so you can proactively free resources before your instances are removed by the GC.

.NET's garbage collector will handle this for you. In fact, setting "lastEmployees" to null accomplishes the same thing as just exiting the function.
Any item that is no longer referenced by the root application in one form or another will be marked for collection.
In .NET, you never need to worry about cleaning up managed resource. Hence, managed.
http://msdn.microsoft.com/en-us/library/0xy59wtx.aspx

putting a tilde in front of a method call?

I was working through an example and I saw this...
#if DEBUG
/// <summary>
/// Useful for ensuring that ViewModel objects are properly garbage collected.
/// </summary>
~ViewModelBase()
{
string msg = string.Format("{0} ({1}) ({2}) Finalized", this.GetType().Name, this.DisplayName, this.GetHashCode());
System.Diagnostics.Debug.WriteLine(msg);
}
#endif
I tried to Google it but couldn't get any results... I was just wondering what it means. Anyone know?
Thanks

It is the finalizer for the ViewModelBase class. It is called by the garbage collector before collection.
It is not really very useful because:
a) Garbage collection does really work and you do not need to test it.
b) It tells you nothing about your code when this gets called during normal execution, because for the most part the Garbage Collector just does its own thing and collects when it determines that there is memory pressure.
For the most part it is OK to not worry about the Garbage Collector - only worry about it when you have a real problem.
Also experience tells me - avoid using the finalizer since you are never sure what state the rest of your program will be in when it is called.

This is called a finalizer.
It's called by the garbage collector at an indeterminate point in time when the object is collected, on the GC thread.
They also have a performance hit.
In general, you will never write a finalizer.
Finalizers are used by classes that directly own native resources (unless they use SafeHandles, which they should), and for special debugging tricks.

It's a finalizer (a special method that is invoked by the garbage collector). Finalizers are designed to dispose unmanaged resources owned by an type implementing IDisposable even if its Dispose() method is never called.
The reason the author of this class wrote that debug code isn't 100% clear, but such debugging code is usually just a means of saying "hey dummy, you forgot to call Dispose() manually". It's a fairly common debugging aid (I've seen it in quite a lot of code), though I don't use it myself.
Sometimes an instance of a type holds precious resources and it's in your interest to call Dispose() as soon as you're finished with it. What the author's code is doing is saying "if I ever reach this Finalizer, you're failing to call Dispose() as soon as possible." It's not really what you'd use a Finalizer for in production code, though.

Oh duh, I found it like two seconds after I posted this... it is a destruct-or. http://www.csharp-station.com/Tutorials/Lesson07.aspx