One day every professional Java programmer will suffer from this exception thrown by his Java application: java.lang.OutOfMemoryError .
With a little luck this error will occur during development of the application – if not and it happens in a production environment, you will quickly get a lot of unintentional attention by your management, as a Java OutOfMemoryError normally means that you had an application crash! The reasons for these memory problems in the Java Virtual Maschine are versatile and in many cases not easys to analyze. In our troubleshooting services we see workarounds for these errors every day: Servers are preventevly restarted every night as the heap gets closer and closer to its limits or – even worse – the application regulary crashes with an java.lang.OutOfMemoryError indicating that the hunger of the JVM for more memory was bigger than the available heap.
As 64bit JVMs are getting more and more available in production environments, this seems as a perfect solution for theses kind of problems, as more adressable memory means bigger heaps and less frequent crashes. This is why I see that heaps in production are moving to the GB-area without thinking about the consequences: Less performance and troughput, because of more Garbage Collection overhead and pause times. Even worse if the Java OutOfMemoryError had nothing to do with the heap size…
Our performamce study has shown that memory problems are under the most critical problems with regard to stability and performance of Java applications. Almost 50% of the 250 questioned Java specialists answered, that Java Memory Management is critical for the performance and stability of their application. I think that it is time to write a comprehensive guide to the Java Memory Model inclusing tools and methods for anlyzing Java OutOfMemory errors and this is what this blog series is about.
I am calling this series “Java OutOfMemoryError – A tragedy in seven acts”, as I liked the definition of “tragic” in the German Wikipedia entry for “tragedy”, as it says that in the context of a tradegy the word “tragic” is not used in the sense of “sad” but in the sense that somebody gets blameless guilty.
In my opinion this is often true for developers that are responsible for Java OutOfMemoryError – they get blameless guilty. In my troubleshooting sessions I often see that managers are more interested in finding the person who is responsible for the problem than in finding the reason for the problem – this is sad and I hope that I will help the readers of this blog to better understand the reasons for OutOfMemory errors and give them the right knowledge to avoid them or if they have already occured, to quickly find and resolve them.
This is an overview of my Java Memory Tragedy:
1. Act – The Java Memory Architecture.
The first part of this series will introduce the memory architecture inside the Java Virtual Maschine in detail and will explain where and when java.lang.OutOfMemoryError can occur.
2. Act – Java Memory Leaks et al.
The second part of the series will cover the reasons for java.lang.OutOfMemoryError in detail – especially Java Memory Leaks and high, temporary memory consumption.
3. Act – JVM Monitoring and Configuration
The third part of the series will describe the parameters to configure the JVMs memory areas and show tools to monitore these parameters at runtime. As the parameter are different between JVM vendors and implementation, this blog entry will focus on the Sun HotSpot JVM.
4. Act – Creating and understanding Java Heapdumps
The fourth part of the series will show how to generate Heapdumps with the Sun HotSpot JVM and how to analyze these dumps.
5. Act – Runtime Analyzis of the Java Heap.
The fifth part of the series will cover tools and methods to analyze objects on the Java Heap at runtime, especially to find high memory allocation hotspots and slow growing memory leaks.
6. Act – Typical Java Memory problems
The sixth part of the series will show you typical Java OutOfMemoryError scenarios in practise. I will show you real examples and describe how to analyze and fix these problems by applying the tools and rules of the last 5 parts of this series.
7. Act – Summary and Outlook
The last part of the series will summarize the whole series and will give you an outlook to the next tragedy I am planning to write: The Java Garbage Collector.
Was this post helpful?
More articles
fromMirko Novakovic
21.2.2014 Your job at codecentric?
Jobs
Agile Developer und Consultant (w/d/m)
Alle Standorte
More articles in this subject area
Discover exciting further topics and let the codecentric world inspire you.
Gemeinsam bessere Projekte umsetzen.
Wir helfen deinem Unternehmen.
Du stehst vor einer großen IT-Herausforderung? Wir sorgen für eine maßgeschneiderte Unterstützung. Informiere dich jetzt.
Hilf uns, noch besser zu werden.
Wir sind immer auf der Suche nach neuen Talenten. Auch für dich ist die passende Stelle dabei.
Blog author
Mirko Novakovic
Do you still have questions? Just send me a message.
Do you still have questions? Just send me a message.