列表增加元素通常很快，但扩容时需要复制数组。理解均摊成本，也要留意迭代器的修改约束。
本文使用JDK 7，示例为方法体或类定义片段。源码学习需要区分语言规则、公共接口约定与某个版本的实现。本文把讨论范围固定在 Java 7，不把后续版本的集合结构或语法写进来。
1. 从现象推到机制
ArrayList 的连续引用数组支持按下标访问，插入到中间则需要移动后续元素。扩容带来的复制是偶发成本，不意味着每次添加都复制。遍历时用列表自身删除会破坏迭代器的修改计数约定。
图中的四个节点分别表示数组容量、元素追加、迭代游标、安全删除。顺着实线检查输入如何变成输出，再沿虚线核对反馈条件。图示表达的是本文讨论的关系，不是实测曲线或现场截图。
2. 最小实现与输入条件
用迭代器自己的 remove 方法删除匹配项，把删除和游标维护交给同一套机制。不要把 fail-fast 异常当成并发安全保障。
1
2
3
4
5
6
Iterator<String> it = list.iterator();
while (it.hasNext()) {
if (it.next().isEmpty()) {
it.remove();
}
}
将片段放入独立的小工程，补齐 imports（导入声明）和调用入口。观察返回值、异常类型及对象状态；并发实验需要重复交错，单次没有出错不能证明线程安全。
3. 用对照区分原因
下表列出需要主动改变的条件。预期行为来自机制分析，复现时还需记录运行环境和原始输出，不能将预期当作已经测得的结果。
| 改变的条件 | 需要验证的行为 |
|---|---|
| 连续追加大量元素 | 会经历容量变化而非每次重新分配 |
| 删除中间元素 | 后续引用需要前移 |
| 迭代期间直接改列表 | 可能抛并发修改异常 |
对照 1：连续追加大量元素
会经历容量变化而非每次重新分配。观察时记录容量增长时的复制路径。把这个条件与基准情形分开，有助于判断变化来自哪一层；若得到相反结果，应先核对前提，再修改实现。
对照 2：删除中间元素
后续引用需要前移。观察时记录下标和剩余顺序。把这个条件与基准情形分开，有助于判断变化来自哪一层；若得到相反结果，应先核对前提，再修改实现。
对照 3：迭代期间直接改列表
可能抛并发修改异常。观察时记录修改来自迭代器还是外部列表。把这个条件与基准情形分开，有助于判断变化来自哪一层；若得到相反结果，应先核对前提，再修改实现。
4. 适用条件与取舍
预分配容量适合已知数量的批量写入，但容量过大也占空间。实际性能应结合访问模式和元素数量，不能笼统认定链表更适合所有插入。
一次正常运行只覆盖了这组输入。继续扩展前，应把上面的异常对照保留下来，尤其关注“迭代期间直接改列表”这一分支。后续方案若改变了图中任意一处依赖，原来的判断就要重新验证，不能仅凭界面相似或返回值相同沿用结论。
