LinkedList内存泄漏
我正在尝试调试挂起的应用程序。 该程序使用一个使用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似乎是泄漏内存，我该如何防止这种情况发生？
根据如何在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（）;’