What are the differences between calling System.exit(0) and Thread.currentThread().interrupt() in the main thread of a Java program?

java multithreading interrupt

brandones · Sep 24, 2012 · Viewed 17.5k times · Source

Both cause a program to stop executing. It's clear that there must be some differences in how this happens, though. What are they?

Answer

Summary

thread.interrupt() does not stop a thread. It is used for coordination in multi-threaded programs. Don't use it unless you know exactly what you do.
Throwing a RuntimeException will (usually) terminate the thread but not necessarily the program.
System.exit(int) almost always terminates the program and returns a status code.
In unusual situations, System.exit(int) might not actually stop the program. Runtime.getRuntime().halt(int) on the other hand, always does.

Thread Interruption

I'm afraid your first sentence is wrong. Thread.currentThread().interrupt() does not stop the thread or the program.

Interrupting a thread is a way to signal that it should stop, but this is a cooperative effort: The code in the thread is supposed to check the interrupted status from time to time and (in most cases - but even this is only optional) should stop if is has been interrupted. If it doesn't do that nothing will happen.

Specifically, interrupting a thread (any thread, include the currently executing one) will only set the interrupted flag. Certain methods in the standard library will throw an InterruptedException, but this is also just a way to signal that the thread has been interrupted. What should be done in such a situation is up to the code running in that thread.

Here are the relevant parts from the Java Concurrency in Practice book by Brian Goetz:

Thread provides the interrupt method for interrupting a thread and for querying whether a thread has been interrupted. Each thread has a boolean property that represents its interrupted status; interrupting a thread sets this status.

Interruption is a cooperative mechanism. One thread cannot force another to stop what it is doing and do something else; when thread A interrupts thread B, A is merely requesting that B stop what it is doing when it gets to a convenient stopping point if it feels like it.While there is nothing in the API or language specification that demands any specific application level semantics for interruption, the most sensible use for interruption is to cancel an activity. Blocking methods that are responsive to interruption make it easier to cancel long running activities on a timely basis.

Exceptions and System.exit(int)

The Javadoc of System.exit(int) says:

Terminates the currently running Java Virtual Machine. The argument serves as a status code; by convention, a nonzero status code indicates abnormal termination.

So calling exit() will (almost) definitely stop your program. In contrast to throwing a RuntimeException (or an Error), this can not be caught somewhere down the call stack and it does also not depend on whether there are other threads running. On the other hand, an uncaught exception terminates the thread in which it was thrown, but if there are any other (non-daemon) threads, the program will continue to run.

Another difference to throwing an Exception is that exit() will not print anything to the console (as does an uncaught exception) but instead makes the program return a specific status code. Status codes are sometimes used in shell or batch scripts but other than that, they are not very useful.

Runtime.halt(int)

Finally (for completeness' sake), I'd like to point out a third possibility to exit a Java program. When System.exit(int) is called (or the program ends in some other way), the runtime does some cleanup work before the Java Virtual Machine is halted. This is described in the Javadoc of Runtime.exit(int) (which is called by System.exit(int):

The virtual machine's shutdown sequence consists of two phases. In the first phase all registered shutdown hooks, if any, are started in some unspecified order and allowed to run concurrently until they finish. In the second phase all uninvoked finalizers are run if finalization-on-exit has been enabled. Once this is done the virtual machine halts.

If any shutdown hook or finalizer is prevented from completing, for example because of a deadlock, the program might never actually exit. The only method that guarantees that the JVM halts is Runtime.halt(int):

This method should be used with extreme caution. Unlike the exit method, this method does not cause shutdown hooks to be started and does not run uninvoked finalizers if finalization-on-exit has been enabled.