我投票给Thread.stop()。

例如，您有一个持久的操作(如网络请求)。 假设您正在等待响应，但这可能需要时间，并且用户导航到其他UI。 这个等待线程现在是a)无用的b)潜在的问题，因为当他得到结果时，它是完全无用的，他将触发回调，从而导致大量错误。

所有这些，他可以做响应处理，这可能是CPU密集。作为开发人员，您甚至不能停止它，因为您不能在所有代码中抛出if (Thread.currentThread(). isinterrupted())行。

因此，无法强制停止线程是很奇怪的。

请参阅Sun的这篇文章，了解他们为什么弃用thread .stop()。它将详细说明为什么这是一个糟糕的方法，以及应该做些什么来安全地停止线程。

他们推荐的方法是使用一个共享变量作为标志，要求后台线程停止。这个变量可以由请求线程终止的另一个对象设置。

我没有得到中断工作在Android，所以我用这个方法，工作完美:

boolean shouldCheckUpdates = true;

private void startupCheckForUpdatesEveryFewSeconds() {
    Thread t = new Thread(new CheckUpdates());
    t.start();
}

private class CheckUpdates implements Runnable{
    public void run() {
        while (shouldCheckUpdates){
            //Thread sleep 3 seconds
            System.out.println("Do your thing here");
        }
    }
}

 public void stop(){
        shouldCheckUpdates = false;
 }

一般来说你不会…

你可以使用Thread.interrupt() (javadoc link)命令它中断正在做的事情。

在javadoc中有一个很好的解释(java technote链接)

通常不杀死、停止或中断线程(或检查它是否被中断())，而是让它自然终止。

这很简单。你可以在run()方法中使用任何循环和(volatile)布尔变量来控制线程的活动。您还可以从活动线程返回到主线程以停止它。

这样你就优雅地杀死了一个线程:)。

试图突然终止线程是众所周知的糟糕编程实践，也是糟糕应用程序设计的证据。多线程应用程序中的所有线程显式或隐式地共享相同的进程状态，并被迫相互协作以保持一致，否则您的应用程序将容易出现很难诊断的错误。因此，开发人员有责任通过仔细和清晰的应用程序设计来保证这种一致性。

对于受控线程终止，有两种主要的正确解决方案:

使用共享volatile标志 使用Thread.interrupt()和Thread.interrupted()方法。

关于突发线程终止相关问题的详细解释，以及受控线程终止的错误和正确解决方案的示例，可以在这里找到:

https://www.securecoding.cert.org/confluence/display/java/THI05-J.+Do+not+use+Thread.stop%28%29+to+terminate+threads