Root causes of memory leaks

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.

People at dynatrace did recently publish „the top Java memory problems – Part 1“. In this article, Michael Kopp (co-author of the book Java Enterprise Performance) discusses memory leaks…

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.

Short URL for this post: http://wp.me/p4nxik-wE
This entry was posted in Java and Quality. Bookmark the permalink.

Leave a Reply