我最近在遗留代码库中遇到了一种多线程模式，它依赖于Thread.Abort()取消对外部系统的同时请求的方法。不好的后果之一是不容易将超时异常与其他异常类型区分开来。
ThreadAbortException在多线程控制流中不使用 s 的其他原因是什么？
问问题
172 次
1 回答
5
在多线程控制流中不使用 ThreadAbortExceptions 的其他原因是什么？
Thread.Abort 可以使线程处于非常奇怪的状态，这可能无法干净地处理。
来自Thread.Abort的文档：
如果一个线程在另一个线程上调用 Abort，则中止会中断正在运行的任何代码。静态构造函数也有可能被中止。在极少数情况下，这可能会阻止在该应用程序域中创建该类的实例。在 .NET Framework 版本 1.0 和 1.1 中，线程有可能在 finally 块运行时中止，在这种情况下 finally 块被中止。
如果您正在使用多线程代码，这可能会更加危险，因为它可能会触发死锁。这也记录在案：
如果正在中止的线程位于代码的受保护区域（例如 catch 块、finally 块或受约束的执行区域）中，则调用 Abort 的线程可能会阻塞。如果调用 Abort 的线程持有被中止线程所需的锁，则可能发生死锁。
一般来说，使用框架的协作取消模型更安全、更干净，并且永远不要调用Thread.Abort. 使用CancellationTokenandCancellationTokenSource允许您以干净的方式设计适当的取消，并且线程可以正确处理自己的清理。
于 2013-05-20T17:45:13.367 回答