0

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$Nodes 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?

Jason C
  • 38,729
  • 14
  • 126
  • 182
ko ki hong
  • 3
  • 1
  • 3
  • Please provide the relevant code to replicate the issue and more details about the environment: what version of Java, what OS, arguments used to execute the Java application, and on... – Luiggi Mendoza Apr 15 '15 at 04:38

1 Answers1

1

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:

The recycled objects may need to be "cleaned" (zeroed).
A poorly designed object pool can be a memory leak.
A poorly designed object pool can be a concurrency bottleneck.
A poorly designed object pool can increase GC overheads, especially if you are running with a heap that is too small.

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();'

Community
  • 1
  • 1
Mohsen Bahaloo
  • 257
  • 2
  • 2
  • Be very wary of relying on `System.gc()`: http://stackoverflow.com/questions/2414105/why-is-it-bad-practice-to-call-system-gc – Jason C Apr 16 '15 at 06:10
  • You should never call `System.gc()`...ever...this triggers a major GC which generally should happen very infrequently. It's very expensive to do and is usually (always? I'm 90 percent sure about always, but not sure about all the algorithms) a stop-the-world event. If you're ever calling this it means you're trying to clean all of the heap and you expect massive throughput delays – searchengine27 Sep 05 '16 at 16:05