Все!
Я нашел странный код в LinkedBlockingQueue:
private E dequeue() {
// assert takeLock.isHeldByCurrentThread();
Node<E> h = head;
Node<E> first = h.next;
h.next = h; // help GC
head = first;
E x = first.item;
first.item = null;
return x;
}
Кто может объяснить, зачем нам нужна локальная переменная h? Как это может помочь GC?
Чтобы лучше понять, что происходит, посмотрите, как выглядит список после выполнения кода. Сначала рассмотрим начальный список:
1 -> 2 -> 3
Затем h указывает на head и first на h.next:
1 -> 2 -> 3
| |
h first
Затем h.next указывает на h и head указывает на first:
1 -> 2 -> 3
| / \
h head first
Теперь практически мы знаем, что есть только активная ссылка, указывающая на первый элемент, который сам по себе (h.next = h), и мы также знаем, что GC собирает объекты, которые не имеют более активных ссылок, поэтому, когда метод заканчивается, (старая) глава списка может быть безопасно собрана GC, поскольку h существует только в рамках метода.
Сказав это, было указано, и я согласен с этим, что даже с классическим методом dequeue (т.е. просто сделать first точкой head.next и head указать на first), нет больше ссылок, указывающих на старую голову. Однако в этом сценарии старая голова остается болтающейся в памяти и все еще имеет поле next, указывающее на first, тогда как в отправленном вами коде остается только один объект, указывающий на себя. Это может привести к тому, что GC будет действовать быстрее.
Если вы посмотрите на jsr166 src, вы обнаружите оскорбительную фиксацию
http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/main/java/util/concurrent/LinkedBlockingQueue.java?view=log (см. v 1.51)
Это показывает, что ответ указан в этом отчете об ошибке
http://bugs.sun.com/view_bug.do?bug_id=6805775
Полное обсуждение в этой теме
http://thread.gmane.org/gmane.comp.java.jsr.166-concurrency/5758
"Помощник GC" - это то, что вы избегаете кровотечения.
Приветствия
Matt
Возможно, немного поздно, но текущее объяснение для меня совершенно неудовлетворительное, и я думаю, что у меня есть более разумное объяснение.
Прежде всего, каждый java GC делает какую-то трассировку из корневого набора так или иначе. Это означает, что если старая голова будет собрана, мы все равно не будем читать переменную next - нет причин для этого. Следовательно, IF голова собирается на следующей итерации, это не имеет значения.
ИФ в приведенном выше предложении является важной частью здесь. Разница между настройкой рядом с чем-то другим не имеет значения для сбора самой головки, но может иметь значение для других объектов.
Пусть предполагается простая генерация GC: если голова находится в молодом наборе, она будет собрана в следующем GC в любом случае. Но если это в старом наборе, оно будет собрано только тогда, когда мы сделаем полный GC, который случается редко.
Итак, что происходит, если голова находится в старом наборе, и мы делаем молодой GC? В этом случае JVM предполагает, что каждый объект старой кучи все еще жив и добавляет каждую ссылку от старых к юным объектам в корневой набор для молодой GC. И это именно то, чего здесь не позволяет присвоение: запись в старую кучу обычно защищается барьером записи или чем-то другим, чтобы JVM мог улавливать такие назначения и обрабатывать их правильно - в нашем случае он удаляет объект next, указанный на который имеет последствия.
Краткий пример:
Предположим, что 1 (old) -> 2 (young) -> 3 (xx). Если мы удалим 1 и 2 из нашего списка, мы можем ожидать, что оба элемента будут собраны следующим GC. Но если происходит только молодой GC, и мы НЕ удалили указатель next в старом, оба элемента 1 и 2 не будут собраны. В отличие от этого, если мы удалили указатель в 1, 2 будет собран молодым GC..
Вот пример кода, который иллюстрирует вопрос: http://pastebin.com/zTsLpUpq.
Выполнение GC после runWith() и получение дампа кучи для обеих версий говорит только один экземпляр элемента.