Это выглядит немного странно. Возможно, причина в том, что он явно разбирает список, заключается в том, что список очищается для существующих итераторов и подсписков, а также для родительского списка.
Конечно, это НЕ сделано, чтобы ускорить сборку мусора. Сборщик мусора не пересекает ссылки в недоступном объекте, поэтому обнуление их не будет иметь никакого значения.
UPDATE
Более поздняя версия метода имеет следующие комментарии:
// Clearing all of the links between nodes is "unnecessary", but:
// - helps a generational GC if the discarded nodes inhabit
// more than one generation
// - is sure to free memory even if there is a reachable Iterator
Итак, похоже, что у GC есть польза, по крайней мере, в некоторых случаях.
Предположим, что Node в старшем поколении содержит ссылку на объект (например, Node или элемент) в младшем поколении. Эта ссылка становится «корнем» при сборе младшего поколения, в результате чего объект молодого поколения сохраняется, даже если старое поколение Node недоступно. Это состояние продолжается, пока старшее поколение не будет собрано. Старые поколения собираются нечасто.
Если вы обойдете список и разберете его, переменной, содержащей старую -> новую ссылку, присваивается значение null. Барьер записи для этого назначения приводит к тому, что (немедленно или во время GC) исходная ссылка больше не является «корнем». Таким образом, объект в младшем поколении теперь можно собирать, и он не в конечном итоге «завладевает» старшему поколению (что продвигает время, когда необходимо собрать это поколение).
Предположительно, преимущества GC перевешивают затраты на выбор списка ... либо в среднем, либо в тех случаях, когда расходы катастрофические.
Для получения дополнительной информации см. «Алгоритмы сбора мусора для динамического управления памятью» Джонс и Линс. Он находится в главе 7.5 в моем (первом издании) экземпляре.
Вообще говоря, лучше выбросить Collection объект и начать заново, чем очистить его для повторного использования.