is there a way to determing if a jvm is shutting down normally? Shutdown hook can only spawn a thread, is there a way to determine if the JVM is existing normally or abnormally at that time?
4 Answers
You could write a file on startup and delete it again on graceful exit. If the JVM is gone but the file is still there you know that it crashed or has otherwise exited in a unintended manner.

- 13,877
- 6
- 48
- 58
-
1+1 but... There are a **lot** of gotchas if you try to do that correctly. For example where and how do you know where to store the file? On OS X, for example, the location returned by the *tmpdir* property can **change** from one run to the next. You then need a way to know where the file is saved (say using the Preferences API). Also, it's not because you have the right to write to some temporary files that you'll get the same right on the next run. What if two instances are run, etc. It can be made to work but it is **MUCH** more complex than your answer make it sound like. – SyntaxT3rr0r Jun 02 '11 at 11:05
-
@SyntaxT3rr0r: Yes, you are right, although the complexity depends on what kind of application this is needed for. For a server application you usually need some well defined directories where you can write files into anyway. For a desktop application it would be helpful to know what is supposed to happen as a consequence of a unintentional shutdown to suggest a more detailed solution. – x4u Jun 02 '11 at 11:55
When the JVM is shutting down normally, this means that the main thread has ended. If the JVM is shutting down for some other resaon (e.g. the user pressed Strg+C), the main thread is still running. So you can store a reference to the main thread in your shutdown hook and check whether this thread is still alive. Of course this assumes that the main thread will normally be the last running thread in your application. I don't know how the situation is if one of the threads called System.exit(), but you could easily find this out.

- 11,184
- 7
- 52
- 87
I remembered a similar question being asked time ago. One possible course of action is the use of SignalHandler.
You can read the full article here. It appears to be related to IBM JVM but I think it is equally valid for Java Hotspot.
A little-known feature of Java is the ability of an application to install its own signal handler, which is supported through the sun.misc.Signal class. However, use caution when using classes from the sun.misc package because it contains undocumented support classes that may change between releases of Java. You can install a Java handler for any signal that is not used by the JVM. These signal handlers are similar to native handlers because they're invoked when a native system signal is raised, but they will always run as a separate Java thread. Essentially, when a signal is raised for which a Java signal handler is available, the JVM's "signal dispatcher thread" is woken up and informed of the signal. The signal dispatcher thread then invokes a Java method to create and start a new thread for the installed Java signal handler. To write a Java signal handler, define a class that implements the sun.misc.SignalHandler interface and register the handler by using the sun.misc.Signal.handle() method.

- 1
- 1

- 76,803
- 25
- 144
- 205