当前位置:首页>>ASP.NET教程>>Asp.NET综合技巧>>解决Thread 的关闭问题和参数传递时想到的办法
解决Thread 的关闭问题和参数传递时想到的办法
2009/11/8 13:19:18
在运用多线程的时候,往往会涉及到线程的关闭,很多人指出可以使用Thread.Abort方法来关闭线程.
在这里提出一些自己的想法:

参考一下牛津字典对单词Abort的解释:

vi.
异常中断, 中途失败, 夭折, 流产, 发育不全
n.
中止计划[任务]异常中断, 中途失败, 夭折, 流产, 发育不全

有夭折的意思

参考一下Abort的MSDN解释:
当线程对自身调用 Abort 时,效果类似于引发异常;ThreadAbortException 会立刻发生,并且结果是可预知的。但是,如果一个线程对另一个线程调用 Abort,则将中断运行的任何代码。在 finally 块运行时线程可能会终止,在这种情况下,finally 块将被终止。还有一种可能就是静态构造函数被终止。在极少数情况下,这可以防止在该应用程序域中创建该类的实例。

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

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

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

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

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

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

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

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

 1public class BX_Thread
 2    {
 3        private Thread thWorker;
 4        private bool IsClosing =false;
 5
 6        private int Interval =0;
 7        private object objParameter;
 8        public BX_Thread(object Parameter)
 9        {
10            this.objParameter =Parameter;
11            this.thWorker =new Thread(new ThreadStart(WorkProc));
12            this.thWorker.Priority =ThreadPriority.Lowest;
13        }
14
15        public void Run(int Interval)
16        {
17            this.thWorker.Start();
18        }
19
20        private void WorkProc()
21        {
22