Java ArrayList.subList 为什么会突然抛 ConcurrentModificationException：父列表结构修改与视图边界

把订单列表的中间一段交给另一个方法处理时，很多 Java 代码会直接传入 list.subList(from, to)。它看起来像一个新列表，实际却是父列表上的视图；如果父列表随后单独执行了 add 或 remove，这个视图就可能在下一次访问时抛出 ConcurrentModificationException。解决关键不是捕获异常，而是分清“通过视图修改”和“绕过视图改父列表”这两条路径。

subList 适合在父列表稳定期间做范围操作；需要独立生命周期时，立即复制成 new ArrayList(view)，不要把原视图长期缓存。

先看清 subList 到底返回了什么

下面的最小例子把三个动作放在一起：先从父列表取出下标 1 到 3 的视图，再用视图替换元素，最后从父列表新增元素。

List parent = new ArrayList(List.of("A", "B", "C", "D"));
List view = parent.subList(1, 3);

view.set(0, "B2");       // 非结构修改，parent 也能看到
System.out.println(parent); // [A, B2, C, D]

parent.add("E");         // 父列表结构修改
System.out.println(view); // 视图语义失效，常见表现为 CME

set 不会改变父列表大小，所以这一步仍然保持视图关系。parent.add 改变了结构，而它不是通过 view 发起的；此后不要再依赖这个视图的行为。JDK 文档把这种状态描述为返回列表的语义变为未定义，ConcurrentModificationException 只是常见的快速失败表现。

配图中的 ArrayList parent 指父列表，subList view 指范围视图；set 是元素替换，add 和 clear 是结构操作，绕过视图修改后可能到达 ConcurrentModificationException。

为什么异常常常出现在下一行

开发者容易把异常归因到真正的 add 行，但失败点可能是稍后的 view.size()、view.get(0) 或迭代器创建。视图内部需要记录父列表的结构变化；父列表被绕过修改后，视图检查到预期状态不一致，就可能快速失败。

List parent = new ArrayList(List.of("A", "B", "C", "D"));
List view = parent.subList(1, 3);
parent.remove(0);

// 不要把下面的异常当作业务分支
for (String item : view) {
    System.out.println(item);
}

这里还有一个重要边界：fail-fast 是尽力而为的缺陷探测，不是并发安全协议。不要用“捕获 CME 后重试”来修正共享列表的生命周期；应让修改者和视图的所有者遵守明确的访问规则。

两种稳定写法：视图负责范围操作，副本负责独立生命周期

只删除父列表中的连续范围

如果目标就是删除父列表的一段，让视图执行 clear()。这是文档明确支持的范围删除习惯，修改路径始终由视图转发到父列表。

List parent = new ArrayList(List.of("A", "B", "C", "D", "E"));
parent.subList(1, 4).clear();
System.out.println(parent); // [A, E]

这段代码执行后不要继续使用一个事先保存的旧视图。若还要操作新的范围，按当前父列表的下标重新取得视图。

把一段数据交给异步任务或长期对象

需要跨方法、跨线程或跨请求保存时，视图不合适。创建副本会切断与父列表的结构关联：

List parent = new ArrayList(List.of("A", "B", "C", "D"));
List snapshot = new ArrayList(parent.subList(1, 3));
parent.add("E");
System.out.println(snapshot); // [B, C]
System.out.println(parent);   // [A, B, C, D, E]

副本不是并发容器。如果多个线程还会修改 snapshot，仍需使用合适的同步策略或并发集合；复制只解决“这个对象不再跟随父列表变化”的问题。

第二张图用 parent list、view.clear()、new ArrayList(view)、parent.add()、stale view 和 re-create view 标出两种生命周期选择：范围删除走视图，长期保存走副本。

三个容易误判的边界

第一，subList(from, to) 的右端点不包含在范围内，subList(1, 3) 只覆盖下标 1 和 2。第二，父列表的 set 通常不会触发结构变化，但这不等于所有读取都适合并发进行。第三，视图和父列表都不应跨越不受控的生命周期长期缓存，尤其是批处理队列把父列表反复追加时。

如果必须在多线程场景共享列表，先决定共享的是不可变快照、受保护的可变集合，还是消息传递中的一次性数据。仅把 ArrayList 换成 synchronizedList，也不能自动修复“视图创建后父列表被独立结构修改”的设计问题。

常见问题

subList 会复制数据吗？

不会。它是父列表支撑的视图；需要快照时显式创建 new ArrayList(view)。

捕获 ConcurrentModificationException 后重新取 subList 可以吗？

重新建立视图可能是修复的一部分，但不能靠异常驱动正常流程。更好的做法是先确定父列表的修改边界，并在结构修改后按当前下标重新取视图。

什么时候最适合用 subList？

父列表稳定、范围操作短且修改入口可控时最合适，例如批量删除连续区间。若数据要交给异步任务或长期保存，优先复制。

最后的判断标准

看到 subList 时先问一句：这个对象是临时范围操作，还是要脱离父列表独立存在？前者让视图完成操作，后者创建副本；一旦父列表要在视图存活期间独立增删，就必须重新设计边界，而不是把 CME 当成可忽略的偶发异常。