Освобождение java.util.LinkedList $ Entry memory

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 $Похоже, что количество объектов ввода постоянно увеличивается.

Я создал здесь утечку памяти?Должен ли я вызывать какой-либо метод в объектах List в конце метода, чтобы объекты LinkedList $ Entry можно было собирать мусором?

Answer 1

Нет, вам не нужно делать явную деинициализацию для объектов, которые могут быть востребованы.

Лучше всего узнать , почему элементы не собираются мусором,Для этого используйте предпочитаемый профилировщик памяти, сделайте снимок и попытайтесь проследить путь некоторых из этих элементов до ближайшего маршрута GC (лично я бы посоветовал VisualVM, поскольку он относительно прост в использовании и все еще достаточно мощный для многих вещей).

Также: в вашем примере вы используете ArrayList в качестве List реализации.Эта реализация не использует Entry объекты.Поэтому вам нужно проверить, где в вашем коде вы используете LinkedList.

Answer 2

Похоже, здесь нет утечек памяти.Это зависит от того, как вы используете результат этого.В общем, сборщик мусора соберет их всех.С другой стороны, лучше использовать памятку и заголовки, когда это будет только один список, и данные будут упакованы в структуру, содержащую эти поля.Когда будет добавлен 17-й элемент - новый блок будет выделен в памяти, а предыдущие элементы будут перемещены в новый блок памяти.Так что лучше сделать это только один раз, а не 4 раза.И последнее замечание: лучше использовать конструктор, в котором вы можете указать количество элементов.Он выделит соответствующий блок памяти.Это позволит избежать возможных перераспределений при заполнении коллекции.

Answer 3

Вы проверяли, действительно ли работал сборщик мусора? При нормальных обстоятельствах JVM решает запускать gc через регулярные промежутки времени или при нехватке памяти.

И, как сказал Йоахим Зауэр, в ваших списках может быть какая-то свисающая ссылка из активной цепочки. Поэтому, если gc запустился, но не собрал хотя бы некоторые из этих объектов (иногда он может собирать не все объекты, подходящие для gc, так что это обычно не проблема), вам следует проверить, где находятся ссылки.

Когда-то у нас была проблема с записями соединения с базой данных, которые были закрыты, но не освобождены, и, таким образом, содержали тонны данных на некоторых картах. Избавление от ссылок на эти соединения помогло в этом случае, но это было очевидно только тогда, когда мы применили инструмент трассировки памяти (в нашем случае JProbe).