sublist返回原list的视图而非副本，结构性修改（如add、remove）会同步影响原列表并可能引发concurrentmodificationexception；安全做法是只读使用或立即转为new arraylist(sublist)副本。
subList 返回的是原始 List 的视图（view），不是新副本，对子列表的结构性修改会直接影响原列表，反之亦然。 这是 Java 中最容易踩坑的集合行为之一，关键在于理解“结构修改”与“元素修改”的区别，以及视图的生命周期约束。
subList 的基本用法和返回值本质
调用 list.subList(fromIndex, toIndex) 会返回一个实现了 List 接口的内部类（如 ArrayList.SubList），它不复制数据，而是持有一个指向原列表的引用，并记录起始/结束索引。这意味着：
- 读取操作（
get、contains、遍历）访问的是原列表对应位置的元素； - 修改元素值（
set(i, x)）会直接更新原列表中该位置的值； - 但添加、删除、清空等结构性操作会同步反映到原列表上——可能引发
ConcurrentModificationException或意外改变原结构。
哪些操作属于“结构性修改”？为什么危险？
结构性修改指改变 List 大小或内部数组结构的操作，包括：add、addAll、remove、removeAll、retainAll、clear、sort（某些实现）、replaceAll（若底层触发 resize）。这些操作会：
- 触发子列表的“修改计数校验”，一旦原列表被其他线程或代码路径结构性修改，后续对 subList 的任何操作（哪怕只是
size()）都可能抛出ConcurrentModificationException； - 直接调整原列表底层数组，导致 subList 的索引边界失效（例如在 subList 范围前插入元素，原
subList.get(0)可能变成原列表第 2 个元素）； - 若原列表随后被修改（如
list.remove(0)），subList 可能抛异常或返回错误数据。
安全使用 subList 的三个实践原则
避免陷阱的核心是：把 subList 当作只读视图，或立即转为独立副本。
-
只读场景：仅调用
get、contains、indexOf、stream()等非结构性方法；可配合Collections.unmodifiableList(subList)显式禁止误操作； -
需要修改时，先复制：用
new ArrayList(list.subList(i, j))创建全新独立列表，后续增删不影响原 list； - 避免长期持有 subList 引用：不要将 subList 存入字段或跨方法传递——它的有效性依赖于原列表未被结构性修改，这点极难保证。
一个典型翻车示例与修复
错误写法：
ArrayList<string> list = new ArrayList(Arrays.asList("a", "b", "c", "d"));
List<string> sub = list.subList(1, 3); // ["b", "c"]
sub.add("x"); // ✅ 合法但危险：list 变成 ["a", "b", "c", "x", "d"]，sub.size()=3
list.add("y"); // ⚠️ 原列表结构性修改
sub.get(0); // ❌ 抛 ConcurrentModificationException</string></string>
正确修复：
List<string> safeSub = new ArrayList(list.subList(1, 3)); // 独立副本
safeSub.add("x"); // 不影响 list
list.add("y"); // 安全</string>Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
