ArrayList本身不会直接导致内存泄漏，问题在于其引用未及时释放或所含元素长期被强引用而无法被GC回收，典型场景包括静态集合滥用、引用逃逸及大对象/资源未释放。
ArrayList 本身不会直接导致内存泄漏，问题出在持有它的引用未被及时释放，或元素添加后长期滞留、不再使用却仍被强引用着。Java 的 GC 只能回收“不可达对象”，只要 ArrayList 还活着，且里面存着对象引用，这些对象就大概率无法被回收。
静态或长生命周期 ArrayList 持有无用元素
这是最典型的场景：把 ArrayList 声明为 public static 或作为单例、Spring Bean 的成员变量，持续 add() 却从不 clear()、remove() 或替换引用。
- 避免直接用
static List<Object> cache = new ArrayList<>();存业务数据；改用有明确生命周期的局部变量，或交由专业缓存（如 Caffeine）管理过期与大小 - 若必须用静态集合，搭配定时清理逻辑，例如用
ScheduledExecutorService每隔固定时间扫描并移除超时/失效项 - 对缓存类场景，可考虑
WeakHashMap（键弱引用）或ConcurrentLinkedQueue+ 包装弱引用，让 GC 能自然介入
ArrayList 引用未置空或作用域失控
局部 ArrayList 虽然方法结束就“出作用域”，但如果它被意外逃逸——比如被传入线程池任务、注册为监听器、或赋值给静态字段——它的生命周期就被延长了，里面的元素也就跟着“赖着不走”。
- 方法内创建的 ArrayList，确保不将其引用泄露到方法外；尤其警惕 lambda 表达式、匿名内部类中捕获该列表
- 若 ArrayList 是类成员变量，且所属对象（如 Activity、Service、Handler）已进入销毁阶段，应在
onDestroy()、destroy()等回调中调用list.clear()，再将list = null（双重保险） - 不要依赖“等 GC 自己发现”，主动切断引用链才是关键
元素本身是大对象或含资源引用
ArrayList 存的是引用，如果每个元素是大 byte[]、Map、或封装了未关闭的流/连接，即使清空了列表，只要这些对象还被其他地方引用，或底层 native 资源未释放，也会拖慢整体回收。
立即学习“Java免费学习笔记（深入）”；
- 避免往 ArrayList 中塞大对象（如整张图片的 byte[]、全量查询结果集），优先按需加载、分页或流式处理
- 若元素是自定义资源类（如含
InputStream或Connection），确保其实现AutoCloseable，并在清理列表前遍历调用close() - 对临时中间集合，用完立即
clear()或重用（如list.clear(); list.ensureCapacity(...)），比反复新建更可控
核心不是“ArrayList 有没有 leak”，而是“谁还在指着它，以及它指着谁”。盯住引用链终点，主动断开，比等 OOM 后排查高效得多。
