dcsimg
Login | Register   
LinkedIn
Google+
Twitter
RSS Feed
Download our iPhone app
TODAY'S HEADLINES  |   ARTICLE ARCHIVE  |   FORUMS  |   TIP BANK
Browse DevX
Sign up for e-mail newsletters from DevX

By submitting your information, you agree that devx.com may send you DevX offers via email, phone and text message, as well as email offers about other products and services that DevX believes may be of interest to you. DevX will process your information in accordance with the Quinstreet Privacy Policy.


Tip of the Day
Language: Java
Expertise: Intermediate
Apr 2, 2018

WEBINAR:

On-Demand

Building the Right Environment to Support AI, Machine Learning and Deep Learning


How to Diagnose Memory Leaks

Memory leaks don't have to be hard/scary/tedious problems to solve if you follow the three simple steps mentioned below:

Step 1: Capture baseline heap dump

You need to capture heap dump when it's in a healthy state. Start your application and let it take real traffic for 10 minutes. At this point, capture the heap dump. Heap Dump is basically a snapshot of your memory. It contains all objects that are residing in the memory, values stored in those objects and inbound and outbound references of those object. Heap dump can be captured using following command:

jmap -dump:format=b,file= 

where:

  • pid: is the Java Process Id, whose heap dump should be captured
  • file-path: is the file path where heap dump will be written in to.

If you don't want to use jmap for capturing heap dumps, there are several other options to capture heap dumps.

It's always better to capture heap dump in the production environment (unless in the test environment you can mirror the exact production traffic pattern). Traffic type and its volume plays a primary role in the type and number of objects created in the memory.

Step 2: Capture troubled heap dump

After doing step #1, let the application run. Before the application crashes, take a heap dump once again. Often times it might be challenging to capture heap dumps before it crashes, because we don't know when the application will crash. Is it after 30 minutes, 3 hours, 3 days? Thus, it's ideal to start your application with following JVM property:

-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=

file-path: is the file path to which the heap dump will be written.

This property will trigger heap dump right when application experiences an OutOfMemoryError.

Step 3: Compare heap dumps

Objects that are causing memory leaks grow over the period. If you can the identify objects whose size has grown between the heap dumps captured in step #1 and step #2, then those are the objects that are causing memory leak.

You can consider using a heap dump analyzer tool such as HeapHero.io for this purpose. When you load the heap dumps in to heapHero.io, it provides rich information about your application's memory. There is a "Large Objects" section, that reports the largest objects that are sitting in the memory. Compare this section between heap dumps captured in step #1 and step #2. If you notice any abnormal growth of objects, then they are the ones which is causing memory leak in your application. You can also click on any of the largest object to see the children, grandchildren, great grandchildren objects present in it.

Ram Lakshmanan
 
Comment and Contribute

 

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

 

Sitemap
Thanks for your registration, follow us on our social networks to keep up-to-date