Every now and then I run into the situation where I have to assist on Java EE (bad) performance analysis. I am pretty sure that every one of us came across the most interesting „dos and don’ts“, and probably enough “don’ts” to provide content for the next year for „the daily WTF“ blog. But since I am not a consultant doing performance analysis day in and day out, I never took the time to write down anything to help me on my next firefighting.
A memory leak is the most-discussed java memory issue there is. Most of the time people only talk about growing memory leaks, that is the continuous rise of leaked objects. They are in comparison, the easiest to track down (…)
Lastly there is also the particularly nasty, but in reality rarely, seen version of a lot of small, unrelated memory leaks. It’s theoretically possible, but in reality it would need a lot of seriously bad programmers working on the same project. So let’s look at the most common causes for memory leaks.
According to Micahel Kopp, the most common causes for memory leaks are:
- Thread Local Variables
- Mutable static fields and collections
- Circular and complex bi-directional references
- JNI memory leaks
- Wrong implementation of equals/hashcode
- Classloader Leaks
The article briefly explains each one of this causes, shortly explaining how to detect those using the dynatrace tool stack. Even if you are not using their toolset, the article is a very good starting point/ list of root causes to look for.