static void Main(string[] args)
        {
            for (int i = 0; i < 30; i++)
            {
                Thread t = new Thread(new ThreadStart(ThreadProc));
                t.Name = "Overred_" + i;
                t.Start();
            }
            Console.Read();
        }
        static void ThreadProc()
        {
            try
            {
                for (int i = 0; i < 10; i++)
                {
                     Console.WriteLine("{0}  Value:{1}",Thread.CurrentThread.Name,i);
                }
               
            }
            catch (Exception ex)
            {
                Console.WriteLine(ex.Message);
            }
        }
以上代码非常简单，就是循环启动30个线程去执行同一个方法ThreadProc(),然后打印出结果。
现在提出问题1：当Main里的30个线程都把ThreadProc()方法执行完毕后，这些Threads是自动消亡还是被GC回收，还是变成DeadThread？
好，拿出我们的看家工具windbg，来debug一把。
首先启动我们的程序，然后打开windbg，然后F6，Attach我们的exe
1,加载mscorwks(.net 2.0或者以上)

0:003> .loadby sos mscorwks 

 

红色部分，31个Thread，对应着31个Context，每个线程在windows底层都是一个内核对象和一个栈空间，内核对象存放一些线程的统计信息，比如计数器以及一个上下文，就是我上次执行到那里等。而栈空间则是用来存放线程参数等。

 

 

0:003> !GCRoot 013c3bd4
Note: Roots found on stacks may be false positives. Run "!help gcroot" for
more info.
Scan Thread 0 OSTHread 25e4
Scan Thread 2 OSTHread 24b8
DOMAIN(00514818):HANDLE(WeakSh):241298:Root:013c3bd4(System.Threading.Thread)

 

windbg已经很清楚的告诉我们，
一个对象可以
1，在栈上
2，在一个GCHandle里（可以执行!GCHandles命令查看）
3，在FinalizeQueue里
4，是一个对象的成员
难道对象就必定在以上的“四行”之中吗？答案是不一定，还有个Gchandleleaks，就是你在内存里看不到这个Handle，它已经leak。（这种也算在GCHandle里吧）。
回头我们接着说他自己没被其他任何对象所引用，自己就是个根，但是GC却不搭理它，为何？那就是他在GCHandle里，

 

而且在FinalizeQueue里也有它的踪影:

 

 

下面就来解释下什么才可以在FinalizeQueue里出现呢？答案就是有身份的人，很有身份的人，享受特殊待遇的哦！
啥身份，就是自身实现拉析构函数。

啥待遇，就是GC两次才有可能把他们部分清理掉！为啥部分，是我们不知道windows到底何时去把所有的清理掉（赖皮阿）
具体原理大家可以看.net框架去，我这里不多说。

 

static void Main(string[] args)
        {
            for (int i = 0; i < 30; i++)
            {
                Thread t = new Thread(new ThreadStart(ThreadProc));
                t.Name = "Overred_" + i;
                t.Start();
            }
            GC.Collect();
            GC.Collect();
            Console.Read();
        }

首先声明一点就是当我们调用一次GC.Collect();时，并不是执行一次垃圾收集，只是告诉系统我要强制进行垃圾收集，系统听到这个命令后乖不乖那就不一定拉。
当我们用Reflector查看mscorlib对Thread实现的使用也会发现他实现拉析构：

    ~Thread()
    {
        this.InternalFinalize();
    }

 

再用windbg查看线程时则为:

而FinalizeQueue则为:

为啥还有3个，呵呵，这你可以继续用反射工具查看ThreadPool的实现，在其核心代码ExecutionContext : ISerializable里使用拉一个Thread。
那现在又出现问题拉，既然ThreadPool这么好，那我们为啥还使用Thread呢？这个问题就是ThreadPool有个 GetMaxThreads，可以通过GetMaxThreads(out int workerThreads, out int completionPortThreads);方法获取到，如果线程池满拉，则会死锁更严重！
另：ThreadPool都为后台线程。
究竟使用那个，根据情况而定，理解拉内在的东西，一切表象就简单拉。
OK，到此吧。。。