java - 链表内存泄漏

Question

我正在尝试调试挂起的应用程序。该程序使用通过 LinkedList 实现的队列，在压力测试期间我发现该程序由于堆内存耗尽而停止响应。我分析了堆转储，发现内存似乎从 LinkedList 泄漏。

堆转储的相关部分:

▶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
 ...
 ...

正如您从转储中看到的那样，LinkedList$Node 并未被删除，而是累积起来。

程序的大致流程是:

      Queue.offer() → Queue.poll → Queue.remove(object)

为什么 LinkedList 似乎正在泄漏内存，如何防止这种情况发生？

Answer 1

根据How to handle memory Leaks while continuous insertion in a LinkedList? :

你的问题不会通过显式删除对象来解决......基本上是因为在 Java 中没有办法做到这一点。

'如果您确实创建了太多垃圾，让 CMS 收集器无法处理，那么唯一的解决方案是使用对象池来回收缓冲区对象，而不是将它们扔到地上供 GC 处理。但是，您需要小心，不要用其他问题代替当前的问题:

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.

另一方面，您真正的问题可能是您的堆对于您尝试运行的应用程序来说太小。如果运行太接近限制，GC 每次都不会回收太多垃圾。由于运行 GC 的成本与非垃圾量成正比，因此很容易看出，随着堆接近满，GC 的效率是非线性的。'

您可以通过以下代码在代码点中调用垃圾收集器:'system.GC();'