优化ArrayList内存的关键是填充前预估容量和填充后收缩冗余：批量加载前用构造器或ensureCapacity预设合理容量，加载完成后调用trimToSize释放冗余空间，并结合监控聚焦长生命周期、大数据量场景。

在项目中优化 ArrayList 内存，关键不是“全量套用”，而是抓住两个时机：**填充前预估容量**、**填充后收缩冗余**。多数性能问题其实就出在这两步没做，而不是代码逻辑本身。

批量加载前：用 ensureCapacity 或构造器预设容量

适用于从数据库查出万级数据、解析大文件、接收批量 HTTP 请求体等场景。此时你大概率知道最终元素数量或可合理估算。

• 如果初始化时就能确定规模（比如固定导入 8 万条日志），直接用 new ArrayList<>(80000)
• 如果规模有波动（如接口返回 5–12 万条），取上限再加 5%~10% 余量，例如 new ArrayList<>(130000)
• 若构造时还不知道（比如 DAO 层返回空列表，Service 层才开始 add），就在循环 add 前调一次 list.ensureCapacity(expectedSize) —— 它只扩容一次，不复制数据，开销极小

数据加载完成后：调用 trimToSize 释放多余空间

这一步常被跳过，但对长生命周期、大数据量的列表特别有效。比如缓存配置项、预热词典、离线计算中间结果。

Java Maven Common

Java Maven 项目审查工作流的通用输入处理。当 Java Maven 项目以 ZIP压缩包或 GitLab 仓库 URL 形式提供且需要...时使用。

下载

• 确认后续基本只读（不再 add/remove），且 size 比底层数组长度小不少（例如 size=9500，elementData.length=16384）
• 在所有 add 完成后，立即执行 list.trimToSize() —— 它会把 elementData 数组缩到刚好等于 size，多出的引用槽位立刻可被 GC 回收
• 注意别在循环里反复 trim，也别 trim 后又频繁 add，否则反而增加复制负担

结合监控判断是否值得优化

不是所有 ArrayList 都需要动。小列表（几百以内）、短生命周期（方法内临时变量）、写少读多但数据量不大，优化收益几乎为零，还增加代码理解成本。

立即学习“Java免费学习笔记（深入）”；

• 重点关注堆内存中长期存活、size ≥ 10000 的 ArrayList 实例
• 用 JVM 工具（如 jstat、VisualVM）观察 GC 频率和老年代占用变化，若 trimToSize 后 Full GC 次数明显下降，说明优化到位
• 线上可配合 -XX:+PrintGCDetails 日志，对比 trim 前后 Eden 区晋升量

避开常见误区

优化是手段，不是目的。有些做法看似“更省”，实则得不偿失。

• 不要为了省一点内存，把 ArrayList 换成 LinkedList —— 后者每个元素多一个 next 引用，对象头开销更大，随机访问变慢，GC 更吃力
• 不要在 for 循环中用 list.get(i) 遍历后再 trim —— 遍历本身没问题，但 get(i) 在 ArrayList 中本就是 O(1)，无需替换
• 不要给小集合硬套 new ArrayList<>(1000)，初始容量设太大反而浪费堆空间，尤其当该列表大概率只存几个元素时