为什么Thread.stop（）方法不安全？

Question

来自"Effective Java book"的引用：

  

“这些库提供了Thread.stop方法，但是这个方法是   很久以前就弃用了，因为它本质上是不安全的 - 它的使用可能会导致   在数据损坏。 不要使用Thread.stop “

任何人都可以告诉我为什么？

Answer 1

如果您停止的线程持有严重锁定怎么办？如果线程将对象置于不一致状态并且还没有机会恢复它，该怎么办？停止线程的正确方法是与其合作，而不是强迫它从外部停止。

此外，它根本没有逻辑意义。应用程序中的所有线程都应该合作以实现相同的目的。如果有不应该做的事情，没有线程应该这样做。应该没有理由停止一个线程 - 它应该只被编码为做某事，如果这是整个应用程序首先需要完成的事情。如果一个线程需要被停止，那只是因为它运行的代码被破坏了 - 即使不应该这样做也要做。只需修复该代码。

Answer 2

来自javadoc：

  

为什么不推荐使用Thread.stop？

     

因为它本质上是不安全的。停止线程会导致它解锁   它已锁定的所有监视器。 （监视器解锁为   ThreadDeath异常向上传播。）如果有任何对象   以前受这些监视器保护的状态不一致，   其他线程现在可以在不一致的状态下查看这些对象。   据说这些物体已被损坏。当线程运行损坏时   对象，可以导致任意行为。这种行为可能很微妙   并且难以检测，或者可能发音。与其他不同   未经检查的异常，ThreadDeath以静默方式杀死线程;就这样   用户没有警告他的程序可能已损坏。腐败   甚至可以在实际损坏发生后的任何时间表现出来   未来几小时或几天。

有关详细信息，请阅读：

http://docs.oracle.com/javase/1.4.2/docs/guide/misc/threadPrimitiveDeprecation.html

Answer 3

恕我直言，如果你用它来阻止另一个线程，这是不安全的。您可以使用它来停止当前线程，而不会出现正常问题，例如：如果你需要重新抛出一个已检查的异常。

stop（）的问题是，你不知道在线程中抛出异常或错误的位置。您唯一考虑使用它的方法是停止行为不正常的第三方线程。问题是这样的线程可以捕获并忽略此触发的错误。如果你确实需要运行不安全或不可靠的代码，我建议你使用一个单独的进程，你可以根据需要杀死它。

Answer 4

简而言之，stop强行中止线程而不给它任何清理机会。最典型的结果是一团糟。