ArrayList本身不会直接导致内存溢出，但不当使用会快速耗尽堆内存；需控制其背后对象的规模与生命周期，预设容量、避免静态持有、复用实例并配合监控定位隐患。
ArrayList 本身不会直接导致内存溢出，但不当使用会快速耗尽堆内存，最终触发 java.lang.OutOfMemoryError: Java heap space。关键不在“防止 ArrayList 溢出”，而在于**控制它背后对象的创建规模与生命周期**。
明确容量预期，提前调用 ensureCapacity
ArrayList 默认初始容量为 10，每次扩容按 1.5 倍增长（如 10→15→22→33…），频繁扩容会反复分配新数组、复制旧数据，既消耗 CPU，也产生大量临时对象，加重 GC 压力。
如果已知要存入数千或数万个元素，应在初始化后立即预设容量：
-
推荐写法：
ArrayList<person> list = new ArrayList(10000);</person> - 或分两步：
list.ensureCapacity(10000);再批量 add - 避免在循环中无节制 add，尤其不要嵌套在 while(true) 或长周期任务里持续累积
警惕静态引用和长生命周期持有
ArrayList 若被声明为 static，或作为单例、缓存、全局配置的一部分长期存活，其中的对象就无法被回收——哪怕业务上早已不用。
立即学习“Java免费学习笔记（深入）”；
java-api-doc-generator
下载
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
常见风险场景：
-
private static List<string> cache = new ArrayList();</string>→ 缓存未清理机制，越积越多 - 监听器、回调注册后未反注册，内部持有了 ArrayList 引用链
- 线程局部变量（ThreadLocal）中存放了 ArrayList，线程复用导致内存滞留
解决思路：用完即清，定期清理，或改用 WeakReference 包装、ConcurrentHashMap + 定时淘汰等更安全的结构。
避免在高频路径中反复新建 ArrayList 实例
在方法内、循环体、过滤逻辑中频繁 new ArrayList()，看似轻量，但若每秒执行成千上万次，对象创建速率远超 GC 回收能力，极易引发 Young GC 频繁甚至晋升失败。
可优化方式：
- 复用局部实例（如方法参数传入可重置的 list）
- 对只读场景，优先用
Collections.unmodifiableList或 Arrays.asList（不扩容） - 极简场景下，考虑用基本类型数组（
int[]、Object[]）替代，绕过泛型装箱与对象头开销
配合监控与快照，主动识别隐患
仅靠代码规范不够，需建立可观测性：
- 启动时加 JVM 参数：
-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/path/to/dumps，OOM 时自动生成堆快照 - 用 MAT（Memory Analyzer Tool）打开 hprof 文件，查看 Dominator Tree，定位哪个 ArrayList 实例占用了最多内存、持有多少对象
- 通过
jstat -gc <pid></pid>观察 Eden 区是否长期接近 100%，Young GC 是否过于频繁
