Comments on: Prevent and Recover from Java OutOfMemory Error

By: Taran

Taran — Tue, 13 Oct 2009 20:48:40 +0000

Modified to make more sense. No GCs called, but current thread shutdowns gracefully, possibly other apps/threads can survive bit longer if one of them finishes or reduces the memory mark.

By: Hazem Saleh

Hazem Saleh — Tue, 13 Oct 2009 18:24:38 +0000

Never handle OutOfMemoryException with your hand as JVM already does this for you. And if one application has an OutOfMemoryException, this will be resulted from even a bad programming or a bad design.

By: Kirk

Kirk — Tue, 13 Oct 2009 17:11:25 +0000

The definition of an OutOfMemoryError is greater than 98% of the time spent in GC with less than 2% freed memory. I don't see how calling System.gc() is going to help you in this instance as the system is already spinning it's wheels trying to free up memory.

By: jkilgrow

jkilgrow — Tue, 13 Oct 2009 00:52:57 +0000

I agree with jgulla. I don't think this will buy you much. Especially if you have a leak. But also because gc() merely suggests a GC to run. Even if your production environment allows the gc() method to run, if you are in a situation where you NEED to do this programmtically, it is probably already to late and your collector is already thrashing because it can't recover enough memory to get below the threshold.

By: Olivier

Olivier — Mon, 12 Oct 2009 18:31:51 +0000

Do not try to recover from an OutOfMemory, this is a really bad idea.
I will cite the excellent tips provided in the book "The Pragmatic Programmer" :
> Crash Early
> A dead program normally does a lot less damage than a crippled one.

Let the system crash and as jgulla said, profile your application and adjust your JVM memory system correctly. This will be a lot better than trying to stay alive in a really bad state where everything can happen and bring your system to its knees.

By: jgulla

jgulla — Mon, 12 Oct 2009 07:10:06 +0000

This probably won't work in a production environment. Many production environments (including the one I work on) explicitly disable System.gc(). In fact, many vendors recommend this (you can really mess up the GC / JVM memory strategy by doing explicit calls to System.gc. Besides, if you have a real memory “leak” (holding on to refs no longer needed, etc.) this won't help – the GC will never free them.

You're better off analyzing your memory profile with VisualGC or some other tool and a adjusting your JVM memory settings appropriately.