LinkedList.clear()逐个断开节点的next、prev和element引用，确保GC及时回收；若仅重置头尾指针，残留强引用链会阻碍回收，且影响迭代器等视图的空状态感知。
Java 中 LinkedList.clear() 并不是简单地把头尾指针重置为空，而是逐个遍历所有节点，主动断开它们对前后节点和元素的引用。这个设计看似“多此一举”，实则关键——它直接服务于垃圾回收（GC）的及时性和确定性。
clear 为什么要逐个断开引用
LinkedList 是双向链表，每个 Node 包含三个强引用：
-
item（存储的实际元素） -
next（指向后继节点） -
prev（指向前驱节点）
如果只做 first = last = null，虽然链表逻辑上清空了，但原有节点之间仍相互强引用着（A→B→C→…→header），形成一个闭环或长引用链。只要外部还有任意一个 Node 的引用（比如某个迭代器、子列表 view、或业务代码意外持有某节点），整个链就可能无法被 GC 回收。
逐个断开的作用就是：
立即学习“Java免费学习笔记（深入）”；
- 把每个
Node变成孤立对象（next = prev = null,item = null） - 切断节点间的强引用链
- 让每个节点及其
item能在无其他引用时立刻成为 GC 候选
clear 方法内部做了什么（以 JDK 7/8 典型实现为准）
public void clear() {
Entry<E> e = header.next; // 从第一个实际节点开始（header 是虚哨兵）
while (e != header) {
Entry<E> next = e.next; // 临时保存下一个节点
e.next = e.previous = null; // 断开双向连接
e.element = null; // 断开对元素的引用
e = next; // 移动到下一个
}
header.next = header.previous = header; // 恢复空链表结构
size = 0;
modCount++;
}注意几个细节：
- 使用
header（循环链表的哨兵节点）作为终止条件，避免漏节点 - 先缓存
next再置空e.next，防止链断裂后找不到后续 -
element = null是关键：否则即使集合清空，元素对象仍被Node.item强引用
这种做法对 GC 的实际影响
- ✅ 如果元素只被
LinkedList持有 →clear()后立即可被回收 - ⚠️ 如果元素还被其他变量、静态字段、Map 的 value 等持有 → 不会因
clear()而被回收（这是正常行为，不是 bug） - ✅ 即使有
ListIterator或subList()正在使用该链表，clear()后它们看到的也是空状态（因为节点已解绑，视图感知到结构变化） - ❌ 不会缩容、不重建结构、不释放
Node对象本身（Node 实例仍存在，只是变成垃圾）
和 ArrayList.clear() 的对比（辅助理解）
ArrayList.clear() 同样是遍历 elementData[0..size-1]，逐个设为 null，而非只重置 size=0。原因一致：
- 防止底层数组长期持有旧元素引用，阻碍 GC
-
LinkedList断的是Node的item/next/prev；ArrayList断的是数组槽位里的Object引用
不复杂但容易忽略
