I am attempting to debug an application that is hanging. The program uses a queue implemented with a LinkedList
, and during stress testing I've discovered that the program stops responding due to running out of heap memory. I analyzed the heap dump and found that memory seems to be leaking from the LinkedList
.
The relevant part of the heap dump:
▶java.net.Vectior @ 0xff5eacd0
▶▶java.util.Vector @ 0xff629f30
▶▶▶java.lang.Object[1280] @ 0xff629f50
▶▶▶▶class com.itnade.vsm.staticobject.TrapQueue @ 0xff6b23e8
▶▶▶▶▶java.util.LinkedList @ 0xff6b2460
▶▶▶▶▶▶java.util.LinkedList$Node @ 0xfb954560
▶▶▶▶▶▶java.util.LinkedList$Node @ 0xfb959968
▶▶▶▶▶▶java.util.LinkedList$Node @ 0xfb95ede8
▶▶▶▶▶▶java.util.LinkedList$Node @ 0xfb964230
▶▶▶▶▶▶java.util.LinkedList$Node @ 0xfb969638
...
...
As you can see from the dump, the LinkedList$Node
s are not deleted, and accumulate.
The general flow of the program is:
Queue.offer() → Queue.poll → Queue.remove(object)
Why does the LinkedList
appear to be leaking memory, and how can I prevent this from happening?
according to How to handle memory Leaks while continuous insertion in a LinkedList?:
Your problem won't be solved by explicitly deleting objects ... basically because there is no way to do that in Java.
'If you are really creating too much garbage for the CMS collector to cope with, then the only solution is to use an object pool to recycle the buffer objects instead of dropping them on the floor for the GC to deal with. However, you need to be careful that you don't replace your current problem with others:
On the other hand, your real problem may be that your heap is too small for the application you are trying to run. If you run too close to the limit, the GC won't reclaim much garbage each time. Since the cost of running the GC is proportional to the amount of NON-garbage, it is easy to see that the GC's efficiency is non-linear as the heap gets closer to full.'
you can call garbage collector in a point of code by following code: 'system.GC();'