java 任务完成后如何销毁java中的线程
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/1838150/
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
how to destroy thread in java after the completion of task
提问by user149621
I am using a thread pool for my task. After completion of each task I am destroying the thread using Thread.stop()and Thread.destroy(). But after running my application (in Eclipse) for around 30 min. I am getting a Memory out of bound error.
我正在为我的任务使用线程池。完成每个任务后，我正在使用Thread.stop()和销毁线程Thread.destroy()。但是在运行我的应用程序（在 Eclipse 中）大约 30 分钟之后。我收到内存超出限制错误。
Please suggest me how to kill the thread.
请建议我如何杀死线程。
回答by Jon Skeet
If you're using a thread pool, you shouldn't be terminating the thread to start with - the whole point of a thread pool is to reuse threads.
如果您正在使用线程池，则不应终止线程一开始 - 线程池的全部意义在于重用线程。
If you don't wantto reuse the thread, then just start a new thread instead of using a thread pool - and just let the thread die, instead of calling stop or destroy. These methods are deprecated for good reason - they basically shouldn't be called.
如果您不想重用线程，那么只需启动一个新线程而不是使用线程池——然后让线程死亡，而不是调用 stop 或 destroy。这些方法被弃用是有充分理由的——它们基本上不应该被调用。
It's not really clear how this would cause an out of memory exception though - is there any reason why you're focusing on threading as the probable cause?
尚不清楚这将如何导致内存不足异常 - 有什么理由将线程作为可能的原因？
回答by Stephen C
To reinforce what @Jon Skeet said, it is a REALLY BAD IDEA to call the deprecated Thread.stop()or Thread.destroy()methods.
为了加强@Jon Skeet 所说的，调用已弃用的Thread.stop()或Thread.destroy()方法是一个非常糟糕的想法。
According to the javadoc, Thread.destroy()was fundamentally dangerous and was never implemented. The original idea was simply to kill the thread and break all of its monitor locks. If it happened to be in the middle of updating a shared data structure, the data structure would be left in an indeterminate state. Other threads waiting for the killed thread to notify some object would wait for ever.
根据javadoc，Thread.destroy()从根本上说是危险的，并且从未实现过。最初的想法只是杀死线程并破坏其所有监视器锁。如果碰巧正在更新共享数据结构，则该数据结构将处于不确定状态。等待被杀死的线程通知某个对象的其他线程将永远等待。
Thread.stop()causes a ThreadDeath exception to be raised at an unexpected (to the code that was hit) place. It is a little bit more orderly than killing a thread, but unless all of the stopped thread (including anything that it calls) is carefully written with finallyblocks to notify waiters, restore data structures, etc, you have the same problem.
Thread.stop()导致 ThreadDeath 异常在意外（针对被命中的代码）的地方引发。它比杀死线程更有序一点，但是除非所有停止的线程（包括它调用的任何东西）都用finally块仔细编写以通知服务员、恢复数据结构等，否则您会遇到同样的问题。
Refer to Java Thread Primitive Deprecationfor the whole story.
有关整个故事，请参阅Java Thread Primitive Deprecation。
回答by Stephen C
When the task is complete, the thread run should return. Do nothing more. That will take care of things.
当任务完成时，线程运行应该返回。什么都不做。那会处理事情。
回答by Giancarlo
In debug mode the threads are not cleared by the garbage collector. Try to run the app instead of run in debug mode and everything should be fine.
在调试模式下，垃圾收集器不会清除线程。尝试运行应用程序而不是在调试模式下运行，一切都应该没问题。
