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