What is the difference between StackOverflowError and OutOfMemorryError and how can we avoid them in the application? [closed]

StackOverflowError

It occurs when the stack of methods calls between classes overflows due to an excessive number and our application breaks. It usually occurs when we incorrectly encode the exit condition in a recursive method.

You should know how many calls our stack supports before it breaks, and then count our calls and test if they actually exceed this number in a real case, or only surpass it because our algorithm is poorly coded.

OutOfMemoryError:

The memory of the Virtual Machine is divided into several regions. One of these regions is the PermGen , the area of memory used to, among other things, save the metadata of classes such as attributes and their data types, methods, etc. This memory is of the non-heap type. The instances of the classes are loaded in the heap type memory, to which are added and eliminated the instances of the classes as they are used and eliminated by the garbage collector (Garbage Collector, hereinafter GC).

The default value of the PermGen space is 64 Mb in the Sun virtual machine (VM). This value is normally sufficient for applications that run independently. In the case of an application that runs on a Tomcat web server or an application server, there are cases where this value is not enough.

First , the application may need more space for its own architecture. The Spring and Hibernate libraries are large libraries, which load many classes and also make use of proxies and dynamic loading of classes that make use of the PermGen space, so the 64Mb may not be enough. This case occurs when the exception with the error occurs immediately after starting the web or application server or when accessing the application.

• To solve this problem it will be enough to increase the maximum size of PermGen type memory

Second, the most likely cause of an exception java.lang.OutOfMemoryError: PermGen space failure occurs when the application is reinstalled on the server without restarting the server. The way to reinstall the applications is by removing the classloader that loaded the application for the first time and creating a new classloader for the new instance of the application. In theory, this provides a clean way to reinstall applications, but if the application or web server saves a reference to the old classloader, a memory leak occurs and the result is that we will have the application classes loaded two times in memory.

At the moment I leave you a very interesting link, although in English, about possible causes of java memory leaks: Memory Fugue