java.util.concurrent.LinkedBlockingQueue 中的奇怪代码

发布于 2024-12-26 02:09:55 字数 386 浏览 2 评论 0原文

全部！

我在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 有什么帮助？

原文

All!

I found strange code in 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;
}

Who can explain why do we need local variable h? How can it help for GC?

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

笔落惊风雨 2025-01-02 02:09:55

如果您查看 jsr166 src 然后你会发现有问题的提交，向下滚动到 v1.51

这表明答案就在这个错误报告

完整的讨论可以在 jsr.166 邮件列表thread

“帮助 GC”是为了避免事情渗入终身。

回复收藏 0 原文

萝莉病 2025-01-02 02:09:55

也许有点晚了，但目前的解释对我来说完全不满意，我想我有一个更合理的解释。

首先，每个 java GC 都会以某种方式从根集进行某种跟踪。这意味着，如果收集了旧头，我们无论如何都不会读取 next 变量 - 没有理由这样做。因此 IF head 在下一次迭代中被收集并不重要。

上面这句话中的 IF 是这里的重要部分。设置在不同物体旁边的差异对于收集头本身并不重要，但可能会对其他物体产生影响。

让我们假设一个简单的分代GC：如果 head 位于 young set 中，那么无论如何它都会在下一次 GC 中被收集。但如果它在旧集合中，只有当我们执行完整的 GC 时才会收集它，而这种情况很少发生。

那么如果 head 位于旧集合中并且我们执行年轻 GC 会发生什么？在这种情况下，JVM 假定旧堆中的每个对象仍然存在，并将从旧对象到年轻对象的每个引用添加到年轻 GC 的根集中。这正是赋值所避免的：写入旧堆通常受到写屏障或其他东西的保护，以便 JVM 可以捕获此类赋值并正确处理它们 - 在我们的例子中，它会删除对象 next 指向根集，这确实会产生后果。

简短的例子：

假设我们有 1 (old) -> 2（年轻）-> 3（xx）。如果我们现在从列表中删除 1 和 2，我们可能期望下一次 GC 会收集这两个元素。但是，如果仅发生年轻的 GC，并且我们没有删除旧的 next 指针，则元素 1 和 2 都不会被收集。与此相反，如果我们删除了 1 中的指针，2 将被年轻的 GC 收集。

回复收藏 0 原文

方觉久 2025-01-02 02:09:55

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

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

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

To better understand what happens let's see how the list looks like after executing the code. First consider an initial list:

1 -> 2 -> 3

Then h points to head and first to h.next:

1 -> 2 -> 3
|    |
h    first

Then h.next points to h and head points to first:

1 -> 2 -> 3
|   / \
h head first

Now, practically we know that there is only active reference pointing to the first element, which is by itself (h.next = h), and we also know that the GC collects objects that have no more active references, so when the method ends, the (old) head of the list ca be safely collected by the GC since h exists only within the scope of the method.

Having said this, it was pointed out, and I agree with this, that even with the classic dequeue method (i.e. just make first point to head.next and head point to first) there are no more references pointing towards the old head. However, in this scenario, the old head is left dangling in memory and still has its next field pointing towards first, whereas in the code you posted, the only thing left is an isolated object pointing to itself. This may be triggering the GC to act faster.

回复收藏 0 原文