How do I make the JVM exit on ANY OutOfMemoryException even when bad people try to catch it

Solution:

On newer JVMs:

-XX:+ExitOnOutOfMemoryError
to exit on OOME, or to crash:

-XX:+CrashOnOutOfMemoryError

On Older:

-XX:OnOutOfMemoryError="<cmd args>; <cmd args>"

Definition: Run user-defined commands when an OutOfMemoryError is first thrown. (Introduced in 1.4.2 update 12, 6)

See http://www.oracle.com/technetwork/java/javase/tech/vmoptions-jsp-140102.html

An example that kills the running process:

-XX:OnOutOfMemoryError="kill -9 %p"

If some piece of code in your application's JVM decides that it wants to try to catch OOMEs and attempt to recover, there is (unfortunately) nothing you that you can do to stop it ... apart from AOP heroics that are probably impractical, and definitely are bad for your application's performance and maintainability. Apart from that, the best you can do is to pull the plug on the JVM using an "OnOutOfMemoryError" hook. See the answer above: https://stackoverflow.com/a/3878199/139985/

Basically, you have to trust other developers not to do stupid things. Other stupid things that you probably shouldn't try to defend against include:

  • calling System.exit() deep in a library method,
  • calling Thread.stop() and friends,
  • leaking open streams, database connections and so on,
  • spawning lots of threads,
  • randomly squashing (i.e. catching and ignoring) exception,
  • etc.

In practice, the way to pick up problems like this in code written by other people is to use code quality checkers, and perform code reviews.

If the problem is in 3rd-party code, report it as a BUG (which it probably is) and if they disagree, start looking for alternatives.

For those who don't already know this, there are a number of reason why it is a bad idea to try to recover from an OOME:

  1. The OOME might have been thrown while the current thread was in the middle of updating some important data structure. In the general case, the code that catches this OOME has no way of knowing this, and if it tries to "recover" there is a risk that the application will continue with a damages data structure.

  2. If the application is multi-threaded there is a chance that OOMEs might have been thrown on other threads as well, making recovery even harder.

  3. Even if the application can recover without leaving data structures in an inconsistent state, the recovery may just cause the application to limp along for a few seconds more and then OOME again.

  4. Unless you set the JVM options appropriately, a JVM that has almost run out of memory tends to spend a lot of time garbage collecting in a vain attempt to keep doing. Attempting to recover from OOMEs is likely to prolong the agony.

Recovering from an OOME does nothing to address the root cause which is typically, a memory leak, a poorly designed (i.e. memory wasteful) data structure, and/or launching the application with a heap that is too small.


  1. edit OutOfMemoryError.java, add System.exit() in its constructors.

  2. compile it. (interestingly javac doesn't care it's in package java.lang)

  3. add the class into JRE rt.jar

  4. now jvm will use this new class. (evil laughs)

This is a possibility you might want to be aware of. Whether it's a good idea, or even legal, is another question.

Tags:

Java

Jvm

Recent Posts