线程不一定会立即中止，或者根本不中止。如果线程在作为中止过程的一部分被调用的 finally 块中做非常大量的计算，从而无限期延迟中止操作，则会发生这种情况。

可见对Thread进行一个Abort调用,实际上是通过引发一个异常来进行强制关闭.这样对程序来说可能存在潜在的威胁.所以实际上．

相信很多人都有Abort后线程仍然运行的经历．实际上Thread结束失败是较小的损失．另外一可能会出现一种更大的威胁：
例如：

我有一个数据库．当用户更新表１时一定会更新表２中的一个字段．
假如开发中没有使用存储过程，而是把这２个更新放到了一个线程中去执行．那么就为问题的出现埋下了隐影．

用户通过一个Text ="UpDate"的按钮开启了这个线程，这个线程开始进行费事的更新操作．然而用户对执行２个操作所需要的时间没有很好的认识．在点击了这个按钮后就选择了退出系统．
好，麻烦来了．
由于Abort是强制结束，无疑在任何时间都可以把代码Kill了．如果运气不好，在刚执行了第一个更新步骤后就把线程喀嚓了．．．

这个问题的严重程度实际上是比较大的，做CS 的兄弟大概都知道．而且这样的错误实际上是难以发现的．
但是一但有这样的bug, 实际上可以认为系统是健壮性不高的．

所以我提出一种使用线程并且关闭线程的其他办法．

自己对线程进行一些封装：

代码实际上很简单，无非是自己封装了一下Thread.
这样有２个好处：

（１）２００３　的Thread好象是不能传递参数．将参数封装到BX_Thread中（以private object)的方式存在，可以保证Thread对他的访问．

 (2) 提供了一种非　Abort的结束方式．
 
对于最关心的地２个问题：
可以看看WorkProc().

这里有个while循环．需要解释一下．
一般来说，多线程运用到生产消费模式的情况比较多．
最典型的：我在一个线程中将数据不断的填入一个队列．
然后开很多线程不断的重队列中取出数据进行处理．

这是，线程的执行方法通常是考虑如下的结构：
WorkProc()
{
    while(true)
     {
        if(队列中有数据)
        {
            取出一个进行处理。
        }
    }
}

BX_Thread模型主要对这个模型的循环部分进行了修改。
WorkProc()
{
    while(this.IsClosing !=true)
    {
        if(队列中有数据)
        {
            取出一个进行处理。
        }
    }
}

然后提供一个方法：BX_Thread.Close()
只需要将 private bool IsClosing 改为true.
线程就会自己退出循环了。
一但退出循环，线程也就自然死亡而非谋杀了。

所以这个是一种思路。BX_Thread可以这样使用：
首先改写WorkProc()满足你的需求。
BX_Thread thWorker =new BX_Thread( Parameter);
thWorker.Run(1000);
//这里的1000回导致循环一次Sleep1秒。如果Run(0)则不Sleep..
//结束
thWorker.Close();

如果不想改写WorkProc
那么可以考虑做一个接口。将线程和业务分离。

我的意思，还有一点：并不是说Abort没有存在的价值。
有时也会有Abort起来很方便的时候。
但是大多数情况，需要Thread正常结束。
而且用错了结束的方式，也会很麻烦。

                                            BearOcean