clear()能帮GC回收对象，因其主动解除集合对元素的强引用，使无外部引用的元素变为不可达对象，便于GC（尤其是Minor GC）及时回收；而new会创建新对象，旧集合及底层数组等待GC，频繁新建加重Young GC压力。
及时调用 clear() 并不是“多此一举”，而是直接影响 GC 是否能回收这批对象的关键动作。
为什么 clear() 能帮上 GC？
集合（如 ArrayList、HashSet、Vector）本身是对象，它内部持有对元素的强引用。只要集合还活着，且没被清空或置 null，这些元素就无法被垃圾回收器判定为“可回收”——哪怕方法早已执行完毕、局部变量已出作用域。
调用 clear() 的本质，是让集合主动解除对所有元素的引用（例如 ArrayList 把每个数组槽位设为 null，HashSet 清空底层 HashMap 的桶链）。这时，只要没有其他外部引用指向这些元素，它们立刻变成“不可达对象”，下次 GC（尤其是 Minor GC）就可能把它们收走。
clear() 和直接赋值 new 集合的区别
两种写法看似效果一样，但内存行为不同：
- list.clear(); —— 复用原对象，只释放元素引用；原集合的底层数组/哈希表结构仍存在，容量不变，适合后续重复填充
- list = new ArrayList(); —— 创建新对象，旧集合对象（连同其底层数组）失去引用，等待 GC；但频繁新建会增加年轻代分配压力
对大容量集合（比如存了 10 万条日志对象的 List），clear() 更轻量、更可控，避免反复申请大块连续内存。
光 clear() 还不够：必须断掉“根引用”
clear() 只解决集合内部引用，但若集合本身还被长期持有，GC 依然无能为力。常见陷阱包括：
- 静态集合字段（static List<?> cache）：clear() 后仍存活，需配合业务逻辑决定是否置 null 或用 WeakReference
- 线程局部变量（ThreadLocal<List>）：未调用 remove()，会导致内存泄漏，尤其在线程池中
- 作为成员变量且生命周期长（如 Spring Bean 中的缓存 List）：clear() 是必须操作，不能依赖方法结束自动释放
怎么验证 clear() 真生效了？
别靠猜，用工具看实际堆状态：
- 运行时执行：jmap -histo:live <pid>，对比 clear 前后某类对象实例数是否下降
- 抓取 heap dump，用 JProfiler 或 VisualVM 查看该集合对象的 “Path to GC Roots”，确认 clear 后不再有强引用链通向它
- 避免滥用 System.gc()：它不保证立即回收，且可能干扰 JVM 自适应策略
不复杂但容易忽略：clear() 是低成本、高确定性的资源解绑动作，尤其在处理批量数据、缓存、临时聚合结果时，应成为编码习惯。
