How the JVM processes signals

When a signal is raised that is of interest to the JVM, a signal handler is called. This signal handler determines whether it has been called for a Java™ or non-Java thread.

If the signal is for a Java thread, the JVM takes control of the signal handling. If an application handler for this signal is installed and you did not specify the -Xnosigchain command-line option, the application handler for this signal is called after the JVM has finished processing.

If the signal is for a non-Java thread, and the application that installed the JVM had previously installed its own handler for the signal, control is given to that handler. Otherwise, if the signal is requested by the JVM or Java application, the signal is ignored or the default action is taken.

For exception and error signals, the JVM performs one of two operations:
  • Handles the condition and recovers
  • Enters a controlled shut down sequence where it:
    1. Produces dumps, to describe the JVM state at the point of failure
    2. Calls your application's signal handler for that signal
    3. Calls any application-installed unexpected shutdown hook (this step does not apply to AIX® systems)
    4. Performs the necessary JVM cleanup
For interrupt signals, the JVM also enters a controlled shut down sequence, but this time it is treated as a normal termination that:
  1. Calls your application's signal handler for that signal
  2. Calls all application shut down hooks and any application-installed exit hooks (this step does not apply to AIX systems)
  3. Performs the necessary JVM cleanup

The shut down is identical to the shut down initiated by a call to the Java method System.exit().

Other signals that are used by the JVM are for internal control purposes and do not cause it to stop. The only control signal of interest is SIGQUIT (equivalent to SIGBREAK on Windows systems), which causes a Javadump to be generated.