C# 使用 Thread.Abort() 有什么问题
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/1559255/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
What's wrong with using Thread.Abort()
提问by Jan Bannister
So I know that you shouldn't use
所以我知道你不应该使用
Thread.Abort()
But I've never been given a good explanation. Is there a performance penalty or some hidden gotcha?
但我从来没有得到很好的解释。是否有性能损失或一些隐藏的问题？
I know you can't ignore/swallow the ThreadAbortException (which makes sense)
我知道你不能忽略/吞下 ThreadAbortException （这是有道理的）
采纳答案by Eric Lippert
In addition to all of the other good answers here, let me add that there is no guarantee whatsoever that a call to Thread.Abort will actually abort the thread in question, ever. It is possible (though not particularly easy) to "harden" a thread against being aborted. If, for example, you are aborting a thread because you believe it to be running hostile code then the hostile code could be resisting its own destruction.
除了这里所有其他好的答案之外，让我补充一点，无论如何都不能保证对 Thread.Abort 的调用实际上会中止有问题的线程。可以（虽然不是特别容易）“强化”线程以防止中止。例如，如果您因为认为某个线程正在运行恶意代码而中止一个线程，那么该恶意代码可能会抵制自己的破坏。
If you have a long-running operation involving code that you do not own that must be taken down cleanly, the correct way to do this is to put that code in its own process, not its own thread. (And preferably in a highly security-restricted appdomain in that process.) You can then cleanly kill the process.
如果您有一个长时间运行的操作涉及您不拥有的代码，并且必须彻底删除，那么正确的方法是将该代码放在自己的进程中，而不是自己的线程中。（并且最好在该过程中高度安全限制的应用程序域中。）然后您可以干净地终止该过程。
In short, Thread.Abort is at best indicative of bad design, possibly unreliable, and extremely dangerous. It should be avoided at all costs; the only time you should ever even consider aborting a thread is in some sort of "emergency shutdown" code where you are attempting to tear down an appdomain as cleanly as possible.
简而言之，Thread.Abort 充其量表明设计不佳，可能不可靠，并且极其危险。应该不惜一切代价避免它；您应该考虑中止线程的唯一时间是在某种“紧急关闭”代码中，您试图尽可能干净地拆除应用程序域。
回答by Frederik Gheysels
Thread.Abort stops your thread in an uncontrolled fashion. thread.Abort will throw an exception, which will cause that your thread stops immediatly.
Thread.Abort 以不受控制的方式停止您的线程。thread.Abort 将抛出异常，这将导致您的线程立即停止。
What is wrong with that: in most cases, you want to gracefully stop the operation that you're performing. For instance, if you are executing an ACID operation, you might want to complete the current operation before ending the thread, so that your system remains in a stable state.
这有什么问题：在大多数情况下，您希望优雅地停止正在执行的操作。例如，如果您正在执行 ACID 操作，您可能希望在结束线程之前完成当前操作，以便您的系统保持稳定状态。
回答by Brian Rasmussen
When you call Thread.Abort() on another thread a ThreadAbortException is injected in the flow of that thread. If you're lucky the code will handled this well and abort in a well defined state. The problem is that you have no way to figure out if you will be lucky in every case, so if you prefer safe over sorry calling Thread.Abort on other threads is not a good idea.
当您在另一个线程上调用 Thread.Abort() 时，会在该线程的流中注入 ThreadAbortException。如果你很幸运，代码会很好地处理这个问题并在一个明确定义的状态中中止。问题是您无法确定是否在每种情况下都是幸运的，因此如果您更喜欢安全而不是抱歉在其他线程上调用 Thread.Abort 不是一个好主意。
回答by Damien_The_Unbeliever
Because if you know that the thread is in some safe state in which it can be aborted, surely you can arrange better communication and have the thread exit cleanly.
因为如果您知道线程处于某种可以中止的安全状态，那么您当然可以安排更好的通信并使线程干净地退出。
The thread could have taken a lock and be in the middle of changing some shared state, and the Thread.Abort will undo the lock and leave the shared state corrupted.
线程可能已经获取了锁并且正在更改某些共享状态，而 Thread.Abort 将撤消锁并使共享状态损坏。
回答by Vitaliy Liptchinsky
Thread.Abort rises an exception in the target thread. Target thread in the meantime can be performing some critical operations and rising an exception can break your application state.
Thread.Abort 在目标线程中引发异常。与此同时，目标线程可能正在执行一些关键操作，引发异常可能会破坏您的应用程序状态。
回答by Vasyl Boroviak
In short. Any IDisposable object may not be disposed. Any locked object may not be unlocked. Anything that must be 100% performed will never be done.
简而言之。不得处置任何 IDisposable 对象。任何锁定的对象都不能解锁。任何必须 100% 执行的事情都不会完成。
回答by Quibblesome
It's easier to hurt yourself. As others have stated it raises an exception in the code, which can occur at any point. This might be fine if you expect this and have coded in a way that elegantly handles this exception at any point but some people dont:
更容易伤害自己。正如其他人所说，它会在代码中引发异常，该异常可能在任何时候发生。如果您期望这样并且以一种在任何时候优雅地处理此异常的方式进行编码，这可能没问题，但有些人不这样做：
Monitor.Enter(obj);
// some code - if exception is raised here, then the lock isn't released
Monitor.Exit(obj)
IDisposable someCriticalResource = GetResource();
// some code - if exception is raised here, then the object isn't disposed
someCriticalResource.Dispose();
Additionally if you're working with many people on a team unless you have good code reviews you cannot guarantee the quality of the code you'll be working with. Hence it is a good idea to preach the gospal of "no Thread.Abort()" than it is to get people to remember to write code that is robust against exceptions occuring anywherewithin that code.
此外，如果您与团队中的许多人一起工作，除非您有良好的代码，否则您无法保证您将使用的代码的质量。因此，宣扬“没有 Thread.Abort()”的福音是一个好主意，而不是让人们记住编写代码，以防止代码中任何地方发生的异常。
