1

I have developed an application with Spring. I've a bean to create a thread, but during the execution of this thread, at runtime, the JVM throws the OutOfMemoryError - Java Heap Space.
What I would ask is whether the following solution might be suitable to solve the problem: Once thrown the thread dies and frees the memory previously occupied by the thread, then I through another thread (which I call RestartThread), I realize that the thread is dead (without catching the error), then:
1) call Garbage Collector, that effectively frees the memory of the dead thread;
2) call back function run() of died Thread, that restart the previous instance (including private variables used by the died Thread, which remain in memory even after the generation of 'OutOfMemoryError') of the died Thread.

What do you think of this thing, it could create problems? Is a correct solution to restart previous istance of died Thread?

Thanks in advance,
--Alucard

Alucard8
  • 13
  • 4
  • 2
    You probably should be finding out why you run out of memory (like leaking references or your application simply needs more memory than you've given to it) and try to fix it, rather than trying to recover from an OOM (which can be difficult at best) – esaj Feb 11 '12 at 19:02
  • You should not rely on this. See http://stackoverflow.com/questions/3058198/can-the-jvm-recover-from-an-outofmemoryerror-without-a-restart and http://stackoverflow.com/questions/2679330/catching-java-lang-outofmemoryerror/2679410#2679410 – Kai Sternad Feb 11 '12 at 19:25

3 Answers3

2

Do everything to prevent OutOfMemoryError. It is thrown by JVM when it does not have any other choice, i.e. all objects that can be removed by GC have been already removed. When this happens JVM often does not have resources even to terminate gracefully. It should be killed and started again. Most chances that even if you try to catch OutOfMemoryError and unlink some resources this will not work and at least will not work robustly.

AlexR
  • 114,158
  • 16
  • 130
  • 208
2

Recovering from an OutOfMemoryError, especially in a multi-threaded environment, is very difficult, and often even impossible. You probably should be finding out why you run out of memory (like leaking references or your application simply needs more memory than you've given to it) and try to fix it, rather than trying to recover from it.

Even if you could just let the thread throwing the error die and restart it, the restarted thread would probably just die again right at the beginning. In a more worse scenario, the root cause could be in some other part of the program. This would mean that other threads in your application would start throwing the same error, as they'd be trying to allocate new objects, resulting in the error cascading all through your application and finally the whole thing would come crashing down spectacularly.

The memory isn't your only problem. Your application state can be pretty much anything (ie. inconsistent), if the thread terminated by an OOME was in the middle of processing and touched the state(s) of some shared object(s), which other threads also use. Also, if another thread was waiting for some monitor (mutex) the terminated thread was holding, or similar (wait/notify etc), the other thread could become deadlocked. In most cases writing the recovery logic and checking that the recovery was successful will be very difficult, as there are far too many variables and things to check before you can be sure the application has REALLY recovered.

esaj
  • 15,875
  • 5
  • 38
  • 52
  • Thanks for reply. I think that if I agree to terminate the thread without cathing internally the OutOfMemoryError, than the memory previously allocated by the object inside the run() is released, then it might be worth thinking of restarting the thread, but with a new call to the function run(). What do you think avout this – Alucard8 Feb 12 '12 at 11:12
  • The memory isn't your only problem. Your application state can be pretty much anything (ie. inconsistent), if the thread terminated by an OOME was in the middle of processing and touched the state(s) of some shared object(s), which other threads also use. Also, if another thread was waiting for some monitor (mutex) the terminated thread was holding, or similar, the other thread could become deadlocked. In most cases writing the recovery logic and checking will be very difficult, as there are far too many variables and things to check before you can be sure the application has REALLY recovered – esaj Feb 12 '12 at 11:18
  • Ok, I've understand. Thanks alot for the clarification – Alucard8 Feb 12 '12 at 11:34
1

you can try to understand why do you have an OOM Error by generating Heap Dump See Here:

Link

Although the answer here is for JBoss Application Server, it should work in a general case for any java process.

Later you can analyze this dump and maybe you'll find that there are a lot of objects of the same type generated.

Hope this helps

Community
  • 1
  • 1
Mark Bramnik
  • 39,963
  • 4
  • 57
  • 97
  • Thanks for the suggestion, it is very useful. The problem is that I'm trying not to pass more arguments to the JVM, so I'm trying to solve the problem from the outside. – Alucard8 Feb 12 '12 at 11:29
  • I thought about this option as a temporary check that can help you to solve the root cause of the issue. Things like 'restarting' are a workaround only, they don't solve the issue, but only help to recover... – Mark Bramnik Feb 12 '12 at 11:36