相关疑难解决方法(0)

所以我知道你不应该使用

Thread.Abort()

但我从未得到过很好的解释.是否存在性能损失或隐藏的问题？

我知道你不能忽略/吞下ThreadAbortException(这是有道理的)

我的同事正在使用我们没有源代码的第三方.NET库.我们正在使用ThreadPool让很多线程调用到这个库中,偶尔其中一个线程将永远挂起,而其余的线程会随意地突然出现.

所以我们想用dreaded Thread.Abort来杀死这样的线程.在我自己创建线程之前我已经完成了这个,但我从未使用过ThreadPool.如果我们跟踪每个任务的开始时间,如下所示:

static Dictionary<Thread, DateTime> started = new Dictionary<Thread, DateTime>();

static void DoSomeWork(object foo)
{
    lock(started)
        started[Thread.CurrentThread] = DateTime.Now;

    SomeBuggyLibraryThatMightInfiniteLoopOrSomething.callSomeFunction(doo);

    lock(started)
        started.Remove(Thread.CurrentThread);
}

然后我们可以锁定并迭代正在运行的线程并调用Thread.Abort以杀死它们吗？如果我们这样做,那么我们是否需要向ThreadPool添加一个新线程来替换我们刚刚杀死的线程,或者ThreadPool会为我们处理它？

编辑:我非常清楚所有潜在的问题Thread.Abort.我知道理想情况下它应该永远不会在生产代码中使用,并且它不一定会停止线程,并且如果你在线程获得锁定时中止线程,那么你可以挂断其他线程等.但是现在我们是在时间紧,我们有体面的理由相信,在这一特定情况下,我们可以调用Thread.Abort没有把整个过程处于危险之中,我们想避免重写这个程序,以消除线程池,除非我们绝对必须.

所以我想知道的是这样的:因为我们将调用Thread.Abort上属于一个线程池线程,有没有引起这些是线程池线程的任何特殊问题,做我们必须手动旋转了一个新的线程来代替一个被杀的人还是ThreadPool会为我们做的？