在Java程序的主线程中调用System.exit0和Thread.currentThreadinterrupt有什么区别？

如何解决在Java程序的主线程中调用System.exit0和Thread.currentThreadinterrupt有什么区别？

摘要

thread.interrupt()不停止线程。它用于多线程程序中的协调。除非您确切知道自己的工作，否则不要使用它。
抛出RuntimeException遗嘱（通常）会终止线程，但不一定终止程序。
System.exit(int) 几乎总是终止程序并返回状态码。
在特殊情况下，System.exit(int)可能实际上并未停止该程序。Runtime.getRuntime().halt(int)另一方面，总是如此。

线程中断

恐怕你的第一句话错了。Thread.currentThread().interrupt()不会停止线程或程序。

中断线程是发信号通知它应该停止的一种方式，但这是一种合作的努力：线程中的代码应不时检查中断状态，并且（在大多数情况下- 但这只是可选的）如果已被中断则停止。如果不这样做，将不会发生任何事情。

具体来说，中断线程（任何线程，包括当前正在执行的线程）只会设置中断标志。标准库中的某些方法将引发InterruptedException，但这也只是一种信号，表明线程已被中断。在这种情况下应该做什么取决于该线程中运行的代码。

以下是Brian Goetz撰写的 Java Concurrency in Practice 一书中的相关部分：

线程提供了用于中断线程和查询线程是否已被中断的中断方法。每个线程都有一个布尔属性，表示其中断状态。中断线程将设置此状态。

中断是一种合作机制。一个线程无法强迫另一个线程停止正在执行的操作并执行其他操作。当线程A中断线程B时，A只是请求B在感觉到方便的停止点时停止其正在做的事情。尽管API或语言规范中没有任何内容要求任何特定的应用程序级语义中断，中断最明智的用途是取消活动。响应中断的阻止方法使更容易及时取消长时间运行的活动。

异常和System.exit（int）

的JavadocSystem.exit(int)说：

参数用作状态码；按照惯例，非零状态代码表示异常终止。

因此，调用exit()（几乎）肯定会停止您的程序。与RuntimeException引发（或Error）相比，它不能在调用堆栈的下方捕获，它也不取决于是否正在运行其他线程。另一方面，未捕获的异常会终止引发该异常的线程，但是如果有其他（非守护程序）线程，该程序将继续运行。

引发Exception的另一个区别是不会exit()将任何内容打印到控制台（未捕获的异常也是如此），而是使程序返回特定的状态代码。状态代码有时用在Shell或批处理脚本中，但除此之外，它们不是很有用。

Runtime.halt（int）

最后（出于完整性考虑），我想指出退出Java程序的第三种可能性。当System.exit(int)调用（或程序以其他方式结束）时，运行时将在Java虚拟机停止之前执行一些清理工作。这在Runtime.exit（int）的Javadoc中进行了描述（称为System.exit(int)：

虚拟机的关闭序列包括两个阶段。在第一阶段，所有已注册的关闭挂接（如果有）以某种未指定的顺序启动，并允许并发运行直到它们完成。在第二阶段，如果启用了退出时终结，则所有未调用的终结器都将运行。完成此操作后，虚拟机将停止。

如果由于死锁等原因导致任何关闭挂钩或终结器无法完成，则该程序可能永远不会真正退出。保证JVM停止的唯一方法是Runtime.halt（int）：

使用此方法时应格外小心。与退出方法不同，此方法不会导致启动关闭挂钩，并且如果启用了退出时终结处理，则不会运行未调用的终结器。

解决方法

两者都会导致程序停止执行。显然，这种情况的发生方式必须有所不同。这些是什么？