ConcurrentLinkedQueue内存泄漏原因探究：为何新增对象会引发泄漏？

问题场景 #

你提供的代码中，仅一行queue.add(new Object());的差异，就导致了天差地别的性能表现和内存泄漏问题：

• 保留该行时，循环耗时随执行次数急剧增加，同时出现内存泄漏
• 移除该行后，循环性能极高，无内存泄漏

核心原因：ConcurrentLinkedQueue的遍历与节点回收逻辑 #

要理解这个问题，得先明确ConcurrentLinkedQueue的底层实现：它是基于单向链表的无界并发队列，每个元素对应一个Node节点，包含item（存储元素）和next（指向下一个节点）指针。

1. 保留初始节点时的内存泄漏与性能恶化 #

当你先执行queue.add(new Object());后，队列中会存在一个永远无法被移除的初始节点A（因为循环中remove(object)删除的是另一个固定对象，和A的元素不匹配）。后续循环的执行流程如下：

• 每次add(object)：会创建新节点（比如B、C、D...），追加到链表尾部，队列变成A→B→C→...
• 每次remove(object)：会从链表头部（head）开始遍历，先跳过初始节点A（元素不匹配），再跳过所有之前被删除的节点（这些节点的item已被置为null，但next指针仍指向后续节点），直到找到刚添加的目标节点。

关键问题在于：当删除的是链表尾部节点时，ConcurrentLinkedQueue的remove方法不会修改前驱节点的next指针（源码中仅在next不为null时才会更新前驱指针）。这就导致所有被删除的节点会一直留在链表中，形成一条越来越长的"幽灵链表"：

• 每次remove都要遍历整条链表，遍历节点数随循环次数线性增长，因此耗时越来越长
• 这些"幽灵节点"被队列的head和后续节点强引用，无法被GC回收，最终引发内存泄漏

2. 移除初始节点后的高效无泄漏表现 #

当队列初始为空时，循环的执行逻辑完全不同：

• 第一次add(object)：创建节点A，队列仅包含A
• 第一次remove(object)：找到节点A，将其item置为null。由于A是链表唯一节点，没有前驱节点，直接返回。此时队列的head仍指向A，但A的item为null
• 后续循环：add(object)会创建新节点追加到链表，但remove(object)会快速找到刚添加的节点（因为链表中只有一个前置的"哨兵节点"，遍历成本可以忽略）。更重要的是，这些被删除的节点不会积累：因为没有初始节点A的阻碍，后续的遍历和指针调整会更高效，被删除的节点最终会被GC回收，不会形成内存泄漏

耗时数据对比 #

保留初始节点时的耗时：

loops=10000 duration=588 MS
loops=20000 duration=1881 MS
loops=30000 duration=3175 MS
loops=40000 duration=3452 MS
loops=50000 duration=3784 MS
loops=60000 duration=4424 MS
loops=70000 duration=4761 MS
loops=80000 duration=5733 MS

移除初始节点后的耗时：

loops=363590000 duration=0 MS
loops=363600000 duration=0 MS
loops=363610000 duration=0 MS
loops=363620000 duration=0 MS
loops=363630000 duration=1 MS

总结 #

• 内存泄漏的本质是：初始节点的存在导致被删除的节点无法从链表中彻底移除，形成无法被GC回收的"幽灵节点"积累
• 性能差异的根源是：保留初始节点时，remove操作的遍历成本随循环次数线性增长；移除初始节点后，遍历成本几乎可以忽略

内容的提问来源于stack exchange，提问作者flower