ArrayList扩容对性能影响显著，核心在于扩容时O(n)数组复制开销、GC压力及内存碎片；插入100万元素约扩容20–22次，预设容量可使耗时从450ms降至80ms。
ArrayList 扩容机制对性能的影响，核心在于数组复制开销和内存分配频率。它不是每次 add 都慢，而是扩容那一刻集中爆发——一次复制就是 O(n) 时间，还带 GC 压力。
扩容次数直接决定性能损耗程度
默认无参构造（初始容量 10），按 1.5 倍增长，插入 N 个元素时，扩容次数远超直觉：
- 插入 100 万数据，会触发约 20–22 次 grow()
- 每次扩容都要 System.arraycopy 整个旧数组，累计复制元素量达数百万次
- 扩容越靠后，单次复制成本越高（比如第 20 次可能要复制 60 万个对象）
时间开销集中在扩容瞬间
正常 add() 是 O(1)，但扩容的 add() 是 O(n)。实测数据表明：
sc-java-to-ts-interface
下载
将后端 Java 接口文档转换为前端 TypeScript 类型定义（interface / type）。输入：飞书文档、Spring Boot 接口文档、Swagger/OpenAPI、手写 API 文档等。输出：包含请求参数与响应结果的 .md 文件，含完整 JSDoc 注释。触发关键词：Java 转 TS、接口转换、生成前端类型、接口文档转 TypeScript、DTO/VO/BO 转 interface、后端文档转前端类型、生成接口类型、类型定义生成。
- 添加 100 万个 Integer：不预设容量约耗时 450ms；指定
new ArrayList(1_000_000)后降至约 80ms - 添加 10 万个元素：默认方式平均 15–25ms；调用
ensureCapacity(100000)后压至 5–10ms - 纳秒级测试中，未优化场景下 add 总耗时可达 185 万纳秒，优化后仅 62 万纳秒
隐性成本容易被忽略
除了 CPU 时间，扩容还会带来三类隐藏负担：
立即学习“Java免费学习笔记（深入）”；
- 内存碎片与 GC 压力：旧数组立即变为垃圾，频繁扩容导致年轻代频繁 Minor GC
- 缓存局部性下降：新数组内存地址不连续，CPU 缓存预取效率降低
- 线程栈与监控干扰：大量 arraycopy 出现在线程栈顶，掩盖真实业务瓶颈（如那次 1200ms 接口延迟，根源就是 list 扩容）
评估方法要结合场景看本质
不能只看“均摊 O(1)”这种理论值，得看你的实际模式：
- 若数据规模已知（如批量导入、固定报表条目），扩容次数可精确计算，性能影响可预测
- 若 size 波动大或完全不可控（如实时日志缓冲），应关注最大可能扩容次数与单次最坏复制量
- 用 JFR 或 async-profiler 抓一下
java.util.Arrays.copyOf的调用频次和耗时占比，比纯代码分析更真实
