2

After reading a lot about MAT, I used my production heap dump to analyze the memory leak issue. Here is the leak report error:

The thread org.apache.tomcat.util.threads.TaskThread @ 0x6d8be0a30 http-bio-8443-exec-115 keeps local variables with total size 3,695,816,440 (89.03%) bytes.

The memory is accumulated in one instance of "java.lang.Object[]" loaded by "'<'system class loader'>".

The dominator tree summary shows the following:

org.apache.tomcat.util.threads.TaskThread @ 0x6d8be0a30 http-bio-8443-exec-115 SH:112 RH:3,695,816,440 Prct:89.03% java.util.ArrayList @ 0x6da437cd8 SH:24 RH:3,695,668,184 Prct:89.03% java.lang.Object[1823230] @ 0x77da34ee8 SH:7,292,936 RH:3,695,668,160 Prct:89.03% com.cjs.persistence.dto.SomeDTO @ 0x76f631650 SH:360 RH:2,264 Prct:0.00% com.cjs.persistence.dto.SomeDTO @ 0x750ed8f88 SH:360 RH:2,264 Prct:0.00% ...

The path to GC root shows the thread itself. Am unable to find what is causing this and why these lists of DTOs is retained and how to clear them up. Any advise is much appreciated.

sMajeed
  • 323
  • 4
  • 10

1 Answers1

1

Actually, we could not help you like this, if you want to resolve the leakage issues, you have to get many inputs, such as GC details, thread dumps and etc.

However, i could suggest to do the following:

From your inputs, i could tell that your leak issue caused by a local variable that got filled via certain method and its seems to have a loop or complex business or any other factor.

Please note: that the GC root for local variable will be alwas the its parent thread itself.

In this case you have to get the stacktrace of that thread, it will show you what exactly that thread is doing, so you can start your investigation from their.

Salah
  • 8,567
  • 3
  • 26
  • 43
  • Thanks for your response. The stacktrace is pointing out the method that is fetching someEntity from database and filling out SomeDTO, nothing else. – sMajeed Apr 21 '15 at 10:09