Java线程需要清理吗？

我看到所有的stop和destroy以及其他与清理方法有关的方法都被弃用了

---

如果我有一个新的Thread（）或一个扩展Thread running的类，我是否需要在它的run（）方法中执行任何操作，而不是让它结束常规执行？或者是否有后台机制可以理解线程已经完成了所有任务，并且可以被销毁？

无需清理。一旦它完成任务，jvm将杀死它。

当你在线程上调用

start（）

时，jvm中靠近操作系统的本机机制正在启动你的线程，最终执行

run（）

。当

run（）

您可能关心垃圾收集或其他资源清理。当然，如果在线程内打开文件/网络连接，它必须像其他任何地方一样关闭。此外，垃圾收集器在分析活动对象时，会考虑从运行线程引用的对象。但当线程完成时，它（或通过
Runnable
实现传递给线程）引用的所有对象都有资格进行垃圾收集

线程退出方法的快速脏编辑，因为visible contextClassLoader缺少x.x

private void exit() {
    if (group != null) {
        group.remove(this);
        group = null;
    }
    /* Aggressively null out all reference fields: see bug 4006245 */
    target = null;
    /* Speed the release of some of these resources */
    threadLocals = null;
    inheritableThreadLocals = null;
    inheritedAccessControlContext = null;
    blocker = null;
    uncaughtExceptionHandler = null;
}

stop（）方法实际上会导致线程抛出错误或异常。它被弃用的原因是，它在潜在未知状态下修改的代码中的任何地方都可能发生这种情况。stop（）只有在停止当前线程时才是真正安全的，因为您知道它将在何时发生。顺便说一句，您可以捕获错误/异常，这意味着线程没有停止（）

在任何情况下，结果都是相同的，run（）返回（或无法捕获异常/错误）。stop（）方法触发一个名为ThreadDeath的特殊错误。它唯一的特殊之处是，通常会打印一个未捕获的异常/错误，但这一个不会。（并且它的名称末尾没有错误；）如果您愿意，可以更改此行为

当线程不再被引用时，可以对其进行清理。（就像任何其他对象一样）注意：您可以在另一个线程中保存对它的引用，即使它已经完成，也不会被清除。
这是我的想法，但很难找到明确拼写它的文档。当您运行简单java程序的主方法时，情况也是如此。它做了自己的事情，然后就死了。@Dr.Dredel，除非在java中明确说明，否则您不需要清理。最有趣的是，可能需要轻微清理的线程是从未启动过的线程。@bestsss是否愿意在响应中对此进行扩展？：）@pst，yeah-线程组、inheritedAccessControlContext、目标、继承的线程局部变量和co保持不变。在过去，未启动的螺纹用于导致螺纹组泄漏（但已修复）。因此，如果出于某种原因保留了对该线程的引用，则它可能是泄漏源。很多人在不知情的情况下通过关闭钩子泄露信息。
destroy（）
不仅仅是不受欢迎的，实际上它根本不存在。如果您尝试调用它，它将不会停止线程，并抛出一个
NoSuchMethodError
它引用的所有对象（或通过传递给线程的可运行实现）都有资格进行垃圾收集。不幸的是，事实并非如此。一个死线程保留了它对contextClassLoader的引用，这可能是一个巨大的问题。有趣的是，谢谢你的评论，你能给我推荐一些深入解释这个问题的资源吗？我想编辑我的答案，使之更加相关…@Tomasz，java.lang.Thread的源代码，我总是看源代码。我快速地看了一下您的答案，说得很好，很聪明，我建议您跟踪并阅读JDK的源代码（java.lang/util作为start）。那你就知道引擎盖下的东西是怎么工作的了。你永远不可能比亲眼所见更清楚。Quick ref（我将编辑您的答案，将清除线程中内容的exit（）方法的代码放入线程中，您可能不会接受）一个死线程保留对许多内容的引用。这不是问题。@unjutable，我没有引用错误本身。空部分不是为了帮助GC，而是为了释放线程自己没有创建的引用。保留对死线程的引用一直是jboss的tx管理器-arjuna（例如）中的漏洞来源。给出的不推荐stop（）的理由并不令人信服。在代码中的任何地方都可能发生异常，其中许多异常都是意外和未捕获的。如果代码在stop（）下不安全，那么没有stop（）就不安全。大体上，我同意。如果可以，最好不要使用stop（），但如果必须使用，我认为最好使用它，而不是千方百计避免它。他们不愿承认，真正的原因可能是stop（）不能保证有效，因为线程死亡可能会被捕获并被忽略。我打赌它在大多数代码中都不起作用，人们倾向于在很多地方捕捉到可丢弃的内容。引用：“当ThreadDeath异常向堆栈上传播时，监视器被解锁。”对于任何异常都是如此。@不可修复，我将ThreadDeath视为OutOfMemoryError或StackOverflowerError（两者都是不可预测的）。如果代码能够在其中任何一种情况下存活下来，那么就没有理由会出现带有ThreadDead的问题。编写一个随时可能崩溃的应用程序是很困难的。但不是这样：当您是运行应用程序的容器时。