Catching Ctrl+C in Java

Solution 1:

You can attach a shutdown hook to the VM which gets run whenever the VM shuts down:

The Java virtual machine shuts down in response to two kinds of events:

  • The program exits normally, when the last non-daemon thread exits or when the exit (equivalently, System.exit) method is invoked, or

  • The virtual machine is terminated in response to a user interrupt, such as typing Ctrl+C, or a system-wide event, such as user logoff or system shutdown.

The thread you pass as shutdown hook has to follow several rules, though, so read the linked documentation carefully to avoid any problems. This includes ensuring thread-safety, quick termination of the thread, etc.

Also, as commenter Jesper points out, shutdown hooks are guaranteed to run on normal shutdown of the VM but if the VM process is terminated forcibly they don't. This can happen if native code screws up or if you forcibly kill the process (kill -9, taskkill /f).

But in those scenarios all bets are off anyway, so I wouldn't waste too much thought on it.

Solution 2:

Just for quick console testing purposes...

Runtime.getRuntime().addShutdownHook(new Thread() {
        public void run() {
            try {
                Thread.sleep(200);
                System.out.println("Shutting down ...");
                //some cleaning up code...

            } catch (InterruptedException e) {
                Thread.currentThread().interrupt();
                e.printStackTrace();
            }
        }
    });

Solution 3:

The top answer suggests using a shutdown hook. Shutdown hooks are far more trouble than they are worth. They run in an indeterminate order, and libraries you depend upon may add their own shutdown hooks, which may mean that something your own shutdown hook depends upon may be de-initialized before your shutdown hook runs. Save yourself the headache, and use a signal handler:

Signal.handle(new Signal("INT"),  // SIGINT
    signal -> System.out.println("Interrupted by Ctrl+C"));

Signal is currently sun.misc.Signal, which means it will be deprecated -- but what it's being replaced with is currently named jdk.internal.misc.Signal, so until the Java team figure out how to publicly expose signal handlers in a non-internal way, beware that this call may go away. For now though (as of JDK 11), sun.misc.Signal still exists.