Что не так с использованием Thread.Abort()

Ответ 1

В дополнение ко всем другим хорошим ответам здесь, позвольте мне добавить, что нет никакой гарантии, что вызов Thread.Abort фактически прервет нить, о которой идет речь, когда-либо. Возможно (хотя и не очень легко) "затвердеть" нить от прерывания. Если, например, вы прерываете поток, потому что считаете, что он работает с недружественным кодом, тогда враждебный код может сопротивляться его собственному уничтожению.

Если у вас есть длительная работа с кодом, который у вас нет, это должно быть очищено чисто, правильный способ сделать это - поставить этот код в свой собственный процесс, а не на свой собственный поток. (И желательно, чтобы в этом процессе был ограниченный доступ к приложениям с высокой степенью безопасности.) Затем вы можете просто убить процесс.

Короче говоря, Thread.Abort в лучшем случае свидетельствует о плохом дизайне, возможно, ненадежном и чрезвычайно опасном. Его следует избегать любой ценой; единственный раз, когда вы даже должны подумать о прерывании потока, - это какой-то код "аварийного выключения", в котором вы пытаетесь максимально снести приложениедомен.

Ответ 2

Потому что, если вы знаете, что поток находится в каком-то безопасном состоянии, в котором он может быть прерван, вы можете организовать лучшую связь и обеспечить чистоту потока.

Поток мог бы занять блокировку и оказаться в середине изменения какого-либо общего состояния, а Thread.Abort отменит блокировку и оставит общее состояние поврежденным.

Ответ 3

Легче навредить себе. Как утверждали другие, в коде возникает исключение, которое может произойти в любой точке. Это может быть хорошо, если вы ожидаете этого и закодировали таким образом, чтобы элегантно обрабатывать это исключение в любой момент, но некоторые люди не делают:

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();

Кроме того, если вы работаете со многими людьми в команде, если у вас нет хороших обзоров кода, вы не можете гарантировать качество кода, с которым будете работать. Поэтому хорошо проповедовать gospal "no Thread.Abort()", чем заставить людей запоминать код, надежный против исключений, происходящих в любом месте этого кода.

Ответ 4

Короче. Любой объект IDisposable не может быть удален. Любой заблокированный объект не может быть разблокирован. Все, что должно быть выполнено на 100%, никогда не будет выполнено.

Ответ 5

При вызове Thread.Abort() в другом потоке поток потока ThreadAbortException вводится в поток этого потока. Если вам повезет, код обработает эту скважину и прервется в четко определенном состоянии. Проблема в том, что у вас нет никакого способа выяснить, удастся ли вам в каждом случае, поэтому, если вы предпочитаете безопасное извинение, вызвав Thread.Abort в других потоках, это не очень хорошая идея.

Ответ 6

Thread.Abort останавливает поток в неконтролируемом режиме. thread.Abort будет генерировать исключение, которое приведет к тому, что ваш поток немедленно остановится.

Что не так: в большинстве случаев вы хотите изящно прекратить выполняемую вами операцию. Например, если вы выполняете операцию ACID, вы можете завершить текущую операцию до окончания потока, чтобы ваша система оставалась в стабильном состоянии.

Ответ 7

Thread.Abort создает исключение в целевом потоке. В то же время целевой поток может выполнять некоторые критические операции, и рост исключения может привести к поломке вашего состояния приложения.