Why LinkedBlockingQueue’s dequeue sets h.next = h – The hidden GC trick explained

What does it do?

The method java.util.concurrent.LinkedBlockingQueue#dequeue removes the head node of the queue and returns its item, doing nothing else.

Running a demo shows the linked list before and after removal, illustrating that the head node (node 1) disappears after the operation.

help GC?

Investigation of JDK bug reports (JDK‑6805775, JDK‑6806875) shows that the line h.next = h was added to break cross‑generation references, preventing the head node from lingering in the old generation and causing excessive Full GC cycles.

Benchmarks comparing JDK 6 (without h.next = h) and JDK 8 (with the line) demonstrate a dramatic reduction in Full GC events when the line is present.

When the queue resides in the old generation and its nodes are in the young generation, removing a node without clearing its next reference creates a cross‑generation reference that hinders Young GC, forcing a Full GC to reclaim the node.

h.next=null ???

Both h.next = h and h.next = null can break the reference, but the JDK implementation chose h.next = h because it aligns with the iterator’s handling of dequeued nodes, where a dequeued node is marked by p.next == p.

The weakly‑consistent iterator relies on this self‑linking to correctly advance when a node has been removed concurrently, ensuring that iteration continues with the next reachable node.

Thus, setting h.next = h both aids the garbage collector and supports the iterator’s contract.