Question

我有一个应用程序，其中java.util.LinkedList $ Entry对象的数量似乎在稳步增加。此应用程序包含一个包含以下代码的方法：

    final List<Boolean> correctnessList = new ArrayList<Boolean>();
    final List<Double> discriminationList = new ArrayList<Double>();
    final List<Double> difficultyList = new ArrayList<Double>();
    final List<Double> guessingList = new ArrayList<Double>();
                 .
                 .
                 .
    for (ItemData datum : candidateItemData) {
                      .
                      .
                      .
        correctnessList.add(datum.isCorrect);
        discriminationList.add(iRTParameter.discrimination);
        difficultyList.add(iRTParameter.difficulty);
        guessingList.add(iRTParameter.guessing);
                      .
                      .
                      .
    }

包含此代码的方法被多次调用。当然，每次方法返回时，List对象都超出范围，并且可能可用于垃圾收集。

但是，正如我所说，java.util.LinkedList $ Entry对象的数量似乎在稳步增长。

我在这里创建了内存泄漏吗？我应该在方法结尾的List对象上调用一些方法，以便可以对LinkedList $ Entry对象进行垃圾回收吗？

Answer 1

不，您不需要对可要求的对象进行任何显式的去初始化。

你最好的办法是找出为什么这些元素不是垃圾收集的。要做到这一点，使用您喜欢的内存分析器，拍摄快照并尝试跟踪其中一些元素路径到最近的GC路径（我个人建议使用VisualVM，因为它使用起来相对简单，而且对于很多东西来说仍然足够强大）。

另外：在您的示例中，您使用ArrayList作为List实施。该实现不使用Entry个对象。因此，您需要检查代码中使用LinkedList的位置。

Answer 2

您是否检查过垃圾收集器是否真的运行了？在正常情况下，JVM会定期或在内存不足时决定运行gc。

正如Joachim Sauer所说，从活动主题到你的列表可能会有一些悬空引用。因此，如果gc运行但至少没有收集其中一些对象（有时可能不会收集所有符合gc条件的对象，因此通常不会出现问题），您应该检查引用的位置。

我们曾经遇到过数据库连接条目的问题，这些条目已关闭但未发布，因此在某些地图中保存了大量数据。在这种情况下，摆脱对这些连接的引用有所帮助，但是当我们部署了一个内存跟踪工具（在我们的例子中是JProbe）时，这是显而易见的。

Answer 3

这里似乎没有内存泄漏。这取决于你如何使用它的结果。通常，垃圾收集器将收集所有这些。另一方面，当memoty使用和hadling只有一个列表并且数据将被包装到包含这些字段的结构中时，它会更好。当它将添加第17项时 - 将在内存中分配新的blok，并将之前的项目移动到新的内存块。所以最好只做一次而不是4次。最后一点是，最好使用构造函数来提供项目数。它将分配专用的内存块。它将避免在您填写集合时可能的重新分配。

释放java.util.LinkedList $条目内存

3 个答案: