代码评审中应关注arraylist扩容是否合理：检查构造时是否按业务预估指定初始容量、ensurecapacity是否提前调用且参数合理、高频场景是否避免重复扩容，并甄别是否误用arraylist替代更优数据结构。
在代码评审中关注 ArrayList 扩容机制，核心不是看它“会不会扩容”，而是判断它“是否在不该扩的时候扩了、扩得是否浪费、是否暴露了容量预估能力缺失”。这直接反映开发者对内存效率和运行时行为的掌控力。
看构造时是否合理指定初始容量
评审时重点检查 new ArrayList() 出现的位置：
- 如果上下文明确知道元素数量（如数据库查询固定返回 100 条、解析 JSON 数组长度已知、循环次数可数），却用无参构造——这是典型信号：后续大概率触发多次扩容，应改为 new ArrayList(expectedSize)
- 若集合用于临时拼接（如日志参数组装、DTO 转换中间列表），且规模通常 ≤5，用无参构造可接受；但若出现 add 调用超过 10 次且未指定容量，需质疑
- 特别注意流式操作后的收集： list.stream().filter(...).collect(Collectors.toList()) 默认不带容量提示，若上游数据量大，建议改用 Collectors.collectingAndThen(..., list -> { list.ensureCapacity(n); return list; }) 或自定义 collector
查 ensureCapacity() 的使用是否真正起效
有人会写 list.ensureCapacity(1000)，但评审要确认两点：
- 调用是否发生在首次添加前？如果已在添加若干元素后再调，可能已发生过扩容，此时 ensureCapacity 只是避免后续扩，无法回收已分配的碎片空间
- 传入值是否合理？比如传 Integer.MAX_VALUE 或明显远超业务上限（如订单列表传 10 万），属于防御过度，反而增加 OOM 风险
- 更优做法是结合业务峰值预估：例如“单次导出最多 5000 条”，则初始化时设 5000，或扩容前 ensureCapacity(5000)
审扩容频次是否异常（通过日志/监控反推）
单纯看代码难发现频繁扩容，但可结合可观测性线索评审：
- 如果该 ArrayList 所在方法被高频调用（如每秒千次的 RPC 处理），且方法内有 add 循环，却没指定初始容量——大概率每调用一次都经历 10→15→22→33… 这种阶梯式复制，应提醒补容量
- 查看 APM 工具中该方法的 GC 堆内存分配热点，若 Arrays.copyOf 占比突增，往往指向未预估容量的 ArrayList 在反复扩容
- 单元测试中若用 @RepeatedTest(100) 测试含 ArrayList 的逻辑，观察是否每次执行都 new 一个新实例却未设初容——这是典型的测试代码诱导生产隐患
辨是否误用 ArrayList 替代更优结构
扩容问题有时本质是选型错误：
- 只读场景下大量使用 ArrayList，但实际只需遍历——考虑用 Arrays.asList() 或不可变集合（如 ImmutableList.of()），零扩容开销
- 需要频繁头插或中间插入——ArrayList 不适合，应提示改用 LinkedList 或考虑批量构建+反转等模式
- 元素类型固定且数量稳定（如配置项枚举），却用 ArrayList 存储——建议直接用数组或 EnumSet，彻底规避扩容逻辑
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
