C#中通常使用线程类Thread来进行线程的创建与调度,博主在本文中将分享多年C#开发中遇到的Thread使用陷阱。
Thread调度其实官方文档已经说明很详细了。本文只简单说明,不做深入探讨。
如下代码展示了一个线程的创建与启动
static void Main(string[] args)
{
Thread thd = new Thread(new ThreadStart(TestThread));
thd.IsBackground = false;
thd.Start();
}
static void TestThread()
{
while (true)
{
Thread.Sleep(1);
}
}
我们可以通过
Thread.ThreadState 判断指定线程状态
Thread.Yield 切换线程
Thread .Interrupt 引发阻塞线程的中断异常
Thread .Join 等待线程完成
Thread.Abort 引发线程上的ThreadAborting异常
本文要谈的是Thread.Abort。有一定多线程开发经验的朋友一定听说过它。官方文档如此描述:
在调用此方法的线程上引发 ThreadAbortException,以开始终止此线程的过程。 调用此方法通常会终止线程。
这在实际中是非常有用的,相信大部分人都会迫不及待地在项目中用上Thread.Abort来终止线程(博主就是迫不及待地用到项目中了)。不过对于不熟悉的API,使用之前一定先看懂文档(这是博主在吃过不少亏后的感言)
Abort调用还分为线程自身调用:
当线程对自身调用 Abort 时,效果类似于引发异常; ThreadAbortException 会立刻发生,并且结果是可预知的。 但是,如果一个线程对另一个线程调用 Abort,则将中断运行的任何代码。 还有一种可能就是静态构造函数被终止。在极少数情况下,这可以防止在该应用程序域中创建该类的实例。在 .NET Framework 1.0 版和 1.1 版中,在 finally 块运行时线程可能会中止,在这种情况下, finally 块将被中止。
被其它线程调用:
如果正在中止的线程是在受保护的代码区域,如 catch 块、 finally 块或受约束的执行区域,可能会阻止调用 Abort 的线程。 如果调用 Abort 的线程持有中止的线程所需的锁定,则会发生死锁。
由官方文档上的说明可知:Abort方法调用是需要特别注意避免静态构造函数的终止和锁的使用,这是通过文档我们能够获得的信息。
但不是全部!
class Program
{
static TcpClient m_TcpClient = new TcpClient();
static void Main(string[] args)
{
m_TcpClient.Connect("192.168.31.100" , 8888);
Thread thd = new Thread(new ThreadStart(TestThread));
thd.IsBackground = false;
thd.Start();
Console.ReadKey();
Console.Write("线程Abort!");
thd.Abort();
Console.ReadKey();
}
static void TestThread()
{
while (true)
{
byte[] sdDat = new byte[10000 * 1024];
try
{
Thread.Sleep(1);
m_TcpClient.GetStream().Write(sdDat, 0, sdDat.Length);
}
catch (Exception ex)
{
// 异常处理
m_TcpClient.Close();
}
}
}
}
以上代码创建了一个Tcp连接,然后不间断向服务端发送数据流。此时若服务端某种原因使用了Thread.Abort终止发送数据(只是终止发送数据,并不是要断开连接),那执行的结果与期望便大相径庭了。
这里正确的使用方式是在发生SocketException异常和ThreadAbortException 异常时分别处理
catch (SocketException sckEx)
{
//socket异常处理
m_TcpClient.Close();
}catch(ThreadAbortException thAbortEx)
{
}
在项目中大家都会遇到对第三方IO库的调用,如果恰好第三方库缺少对ThreadAbortException的异常处理,那你的代码使用ThreadAbort出现BUG的概率便大大提高了。(实际上不光是第三方库,.NetFramework中API也并非完全考虑了此异常)陷阱二就说明了一个系统API对此异常的处理缺陷。
- 陷阱二:文件操作
同样我使用测试代码说明文件操作API的一个异常情况。
开启一个线程,对某个文件写数据(不断循环)代码如下:
class Program
{
static void Main(string[] args)
{
Thread thd = new Thread(new ThreadStart(TestThread));
thd.IsBackground = false;
thd.Start();
Thread.Sleep(1000); //等待,确保代码已经开始执行
while (true)
{
if (thd.IsAlive)
{
thd.Abort();
Thread.Sleep(10);
}
else
{
Console.WriteLine("线程已经退出!");
break;
}
}
Console.ReadKey();
}
static void TestThread()
{
while (true)
{
byte[] sdDat = new byte[10240];
try
{
using (FileStream fs = File.Open("D:\\1.dat", FileMode.OpenOrCreate, FileAccess.ReadWrite))
{
fs.Write(sdDat, 0 , 10240);
Thread.Sleep(1); // 根据自己的运行环境调节休眠时间
}
}
catch (IOException ex)
{
Console.WriteLine("IO exception:" + ex.Message);
break;
}
catch (ThreadAbortException )
{
Thread.ResetAbort();
Console.WriteLine("ThreadAbortException ");
}catch(Exception ex)
{
Console.WriteLine("Other exception:" + ex.Message);
break;
}
}
Console.WriteLine("线程退出");
}
}
运行代码得到输出: (实际并非每次输出都一致,取决与执行代码计算机的当前状态,你也可以改变while循环中的休眠时间,输出较多或较少行ThreadAbortException)
ThreadAbortException
ThreadAbortException
ThreadAbortException
IO exception:文件“D:\1.dat”正由另一进程使用,因此该进程无法访问此文件。
线程退出
线程已经退出!
这次代码里我使用ResetAbort处理ThreadAbortException异常,将Abort状态恢复并继续执行循环,而在IO异常与其它异常时候直接退出循环。
我们可以看到在 ThreadAbortException打印了三次后,出发了IO异常:
IO exception:文件“D:\1.dat”正由另一进程使用,因此该进程无法访问此文件。
这个异常是如何产生的呢?各位不妨看看代码,分析下可能的原因。
首先,这段代码“看起来”的确是没有问题,大家知道在using里的new 的对象在代码段结束的时候,会自动调用Dispose方法释放资源。重最开始的两次ThreadAbort异常被触发可以看出,即使在这种情况下,被占用的文件资源也已经被释放掉了。当然, “看起来”与实际的效果还是有差距,在第四次执行就触发IOException了。说明第三次的文件被占用后没有释放。
问题的关键就在第三次占用文件后为什么没有被释放?
我猜测有可能是fs的对象引用在赋值到fs之前就触发了ThreadAbortException异常,而File.Open代码中占用了文件资源后并在返回之前没有处理ThreadAbortException,导致在using代码段结束释放时,fs为空引用,那自然就无法调用其释放的代码了。当然这些只是我的大胆猜测,为此我修改了本例中TestThread方法的代码,验证猜测。
static void TestThread()
{
byte[] sdDat = new byte[10240];
FileStream fs = null;
while (true)
{
try
{
fs = null;
using (fs = File.Open("D:\\1.dat", FileMode.OpenOrCreate, FileAccess.ReadWrite))
{
fs.Write(sdDat, 0, 10240);
Thread.Sleep(1);
}
}
catch (IOException ex)
{
Console.WriteLine("IO exception:" + ex.Message);
break;
}
catch (ThreadAbortException ex)
{
Thread.ResetAbort();
Console.WriteLine("ThreadAbortException (fs == null):[{0}]", fs == null);
}
catch (Exception ex)
{
Console.WriteLine("Other exception:" + ex.Message);
break;
}
}
Console.WriteLine("线程退出");
}
我把fs变量提出到while循环之前,并在 每次调用using 代码段之前赋值为null,随后每次触发ThreadAbortException 时都打印出fs是否为空。
执行结果:
ThreadAbortException (fs == null):[False]
ThreadAbortException (fs == null):[True]
ThreadAbortException (fs == null):[False]
ThreadAbortException (fs == null):[False]
ThreadAbortException (fs == null):[False]
ThreadAbortException (fs == null):[False]
ThreadAbortException (fs == null):[False]
ThreadAbortException (fs == null):[False]
ThreadAbortException (fs == null):[True]
IO exception:文件“D:\1.dat”正由另一进程使用,因此该进程无法访问此文件。
线程退出
线程已经退出!
多次执行程序就可以看出,每次IOException异常发送的时候,上次打印的 fs都为空。那怎么解释中间有一次fs为空但没有触发IOException呢?记得我上面的分析吗?File.Open在占用了文件资源后并在返回之前的Exception没有处理会出现问题,那么在占用文件资源之前出现Exception是不会出现占用资源未释放的问题的。所以,问题的原因正如我分析的那样。一个需要释放的类(资源)是不太适宜在可能会被Abort的线程中创建并释放的。因为你不太可能完全保证资源占用的时候类赋值之前不会触发ThreadAbortException的。
在项目开发中,Thread类就如同一把双刃剑,功能强大得不得了,但是给代码理解与调试带来了一定程度上的困难。如果非要问我在多线程开发上有什么建议的话,我想说,除非你已经在千锤百炼的开发经验中完全掌握了多线程,否则能不用它就不要用它吧!