clear()仅断开集合对元素的引用，不销毁集合对象或触发GC；它将底层数组元素置null并重置size，但数组本身仍存在，元素能否被GC回收取决于是否还有其他强引用。
调用 clear() 不会让集合对象本身消失，也不会立即触发 GC 回收内存；它只断开集合对内部元素的引用，能否真正释放内存，取决于这些元素是否还有其他活引用。
clear() 做了什么：只是“松手”，不是“销毁”
以 ArrayList 为例，clear() 执行两件事：
• 把底层数组 elementData 中从索引 0 到 size-1 的所有位置设为 null；
• 将 size 重置为 0，并增加修改计数器 modCount。
数组本身（比如长度为 1000 的 Object[1000]）仍保留在堆中，不缩容、不重建、不回收。
GC 能否回收元素，关键看“还有谁拿着它”
元素能否被 GC 回收，和 clear() 没有直接因果关系，只取决于可达性分析结果：
• 如果该元素只被这个集合引用过，clear() 后它立刻失去强引用，成为 GC 候选；
• 如果该元素还被静态字段、线程局部变量、另一个集合或正在运行的方法参数持有，即使集合已清空，它依然存活；
• 可通过 JVisualVM 或 JProfiler 的 “Path to GC Roots” 功能追踪为何某个本该被回收的对象没被回收。
clear() 和 list = null 的区别很实在
二者作用对象完全不同：
• list.clear()：切断集合对**元素**的引用；
• list = null：切断变量对**集合对象自身**的引用；
如果后续不再使用该集合，且希望连同其底层数组一起尽早让 GC 回收，赋 null 更有效；但要注意避免误删仍在使用的引用，尤其在多线程或共享上下文中。
立即学习“Java免费学习笔记（深入）”；
别指望 System.gc() 立竿见影
System.gc() 只是向 JVM 发出建议，不保证执行，也不控制时机；频繁调用反而干扰 GC 正常节奏。真正可控的做法是：
• 尽早让集合脱离作用域（如限制在方法内、用完即弃）；
• 避免将大集合长期存于静态字段或缓存中未清理；
• 对临时大集合，可考虑配合 try-with-resources 自定义清理逻辑（需手动实现 AutoCloseable），但更推荐靠设计规避长期持有。
