问题描述

为了更好地了解发生了什么，让我们看看执行代码后列表的样子。首先考虑一个初始列表：

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仅存在于方法的范围内。

话虽如此，但有人指出，我也同意这一点，即使采用经典的出队方法（即first指向head.next和head指向first），也没有指向旧头的引用。但是，在这种情况下，旧头仍然悬空在内存中，并且其next字段仍然指向first，而在您发布的代码中，剩下的唯一一个是指向自己的孤立对象。这可能会触发GC动作更快。

解决方法

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;
}