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