The Thread object will be eligible for garbage collection as soon as it's not used any more, i.e. immediately after calling the Start method. (It will however not be collected immediately, as the garbage collector runs at specific times.)

The actual thread however is not relying on the Thread object, and will continue to run even if the Thread object is collected.

If the thread is still running when the main method exits, the application will not end until the thread completes, unless you have marked the thread to be a background thread.


Word "thread" could mean several things here:

  • System.Threading.Thread object (created by new Thread()),
  • CLR thread (managed thread),
  • OS thread (un-managed thread).

Thread object will be candidate for GC as soon as Start() method completes, because there are no more references to it.

Managed thread will stay alive while doSomeLengthyOperation() runs.

Quoting the article by James Kovacs, Microsoft MVP:

A managed thread's lifetime is independent of the Thread object that creates it, a very good thing given that you wouldn't want the GC to terminate a thread that was still doing work simply because you lost all references to the associated Thread object. So the GC is collecting the Thread object, but not the actual managed thread.

The article also contains some helpful code samples if you want to experiment yourself.

Operating system thread, theoretically, has no one-to-one relationship with managed threads. From MSDN:

...a sophisticated host can use the CLR Hosting API to schedule many managed threads against the same operating system thread, or to move a managed thread between different operating system threads.

In practice, however, CLR thread maps directly to a Windows thread today.