On Memory Leaks in JVM

Memory leaks in JVM are weird because technically you can’t have a leak of memory in a virtual, preallocated block of memory – it really won’t take up more than your -Xmx parameter.

It gets even weirder when you learn that a memory leak in its final stages can be recognized by high CPU utilization.

So now we know that a memory leak doesn’t really take up more memory than allocated and it’s the CPU that you’re running short of – what exactly is a memory leak in a JVM?

– You have probably heard of GC, the great Garbage Collector that magically cleans up your memory whenever you don’t need it. The “you don’t need it” part is determined by a simple condition – no other object is referencing the object subject to a GC. If you’ve watched Disney’s Coco a 100 times like I did with my 6 year old, you can think of it as the souls that disappear once everyone forgets them.

The problem is, if you keep these references for too long, you’ll run out of allocated memory pretty fast. First symptom of a memory leak is an increase of memory utilization in Old Gen space – especially if the % utilized doesn’t go down after a major GC event. If your application keeps allocating more memory, you’ll shortly enter a phase where the JVM will detect high utilization on Old Gen space and will try to clean up as much memory as it can with even more major collection events. A few moments later, the application will not do any work because it can’t use anymore memory so…. it will take up all the CPU power trying to clean up unreferenced objects, eventually killing the JVM with an OutOfMemory error.

But – is it always a “leak”?
No, sometimes your application configuration simply needs more memory to operate – may be the services need to be already in the memory, you need some cache data to be available at hand. You know, the stuff you can’t really afford loading at runtime with each request due to performance reasons. How to check if it’s a leak?
The first step is to validate the heap dump. Memory Analysis Tool can help your identify potential leaks, by identifying large or frequent objects in memory. If MAT doesn’t show any suspicious activity, a valid strategy is to increase the heap size and check the system’s behaviour.