我知道优雅地关闭线程的公认正确解决方案。
但是假设我的游戏应该是容错的，当一个新的游戏开始时，它会尝试优雅地关闭旧游戏的（现在暂停的）线程。如果它无法加入/关闭它（例如，因为旧线程有问题并且处于无限循环中），它会实例化新线程并启动它。但我不喜欢旧线程还在那里，吃资源的事实。
是否有一种公认的方法可以在不终止进程的情况下终止无响应的线程？在我看来，事实上，我在某处读到 Thread 也可能不会对 Thread.stop() 做出反应。
所以没有办法处理无限循环中的线程（例如由于错误），是吗？即使它对 Thread.stop() 做出反应，文档说 Thread.stop() 可能会使 Dalvik VM 处于不一致的状态......
如果您需要此功能，则必须对其进行设计和实施。显然，如果你不设计和实现优雅的方式来关闭线程，那么就没有办法优雅地关闭线程。没有通用的解决方案，因为解决方案是特定于应用程序的。例如，它取决于线程可能持有的资源以及线程可能持有锁或已损坏的共享状态。
规范的答案是：如果您需要此功能，请不要使用线程。使用流程。
核心原因是线程的工作方式。您获取锁，然后操作共享数据。在您操作该共享数据时，它可能会进入不一致的状态。在释放锁之前将数据恢复到一致状态是线程的绝对责任。（例如，从双向链表中删除一个对象。您必须先调整正向链接或反向链接。在这两个操作之间，链表处于不一致状态。）
假设您有以下代码：
获取锁或进入同步块。
开始修改锁保护的共享状态。
漏洞
将锁保护的数据返回到一致状态。
释放锁。
那么，现在，我们该怎么办？在第 3 步，线程持有一个锁，它遇到了错误并触发了异常。如果我们不释放它在步骤 1 中获得的锁，那么每个试图获得相同锁的线程将永远等待，我们注定要失败。如果我们确实释放了它在步骤 1 中获得的锁，那么每个获得锁的线程都会看到线程无法清理的不一致共享状态，因为它从未到达步骤 4。无论哪种方式，我们都注定要失败。
如果线程遇到应用程序程序员没有创建合理的处理方式的异常情况，则该进程注定要失败。