Java如何用subList获取集合子集

Java中的subList方法看似简单，实则暗藏诸多陷阱：它返回的并非独立副本，而是原集合的实时视图，任何修改（包括clear）都会直接影响原始数据；调用add、remove等结构变更操作常抛出UnsupportedOperationException；索引越界立即失败而非静默处理；并发或单线程下原集合一旦被修改，子列表即刻失效并抛ConcurrentModificationException；更隐蔽的是，LinkedList上的subList性能极差，访问复杂度高达O(n)。真正关键的不是如何调用subList，而是清醒认识到——它只是一扇没有玻璃的窗，窗外的风（原集合的变化）会毫无遮拦地吹进来，稍有不慎便引发意料之外的bug与性能灾难。

subList 返回的是原集合的视图，不是独立副本

调用 subList 得到的 List 对象底层仍指向原 ArrayList（或 LinkedList）的同一段数据，修改子列表会直接影响原集合，反之亦然。这是最常被忽略的设计特性。

• 对 subList 调用 add()、remove() 或 set() 会抛出 UnsupportedOperationException（除非原集合本身支持结构修改且是 ArrayList）
• subList 的 clear() 会真实删除原集合中对应位置的元素
• 若需独立副本，必须显式构造： new ArrayList(list.subList(from, to))

索引越界会立即抛出 IndexOutOfBoundsException

subList(fromIndex, toIndex) 要求 0 ≤ fromIndex ≤ toIndex ≤ list.size()，不满足任一条件就抛异常，不会静默截断或返回空。

• fromIndex == toIndex 是合法的，返回空列表（但仍是视图）
• 常见错误：用 list.subList(0, list.size() + 1) 想“取全部”，实际越界
• 安全写法：取后 N 个元素应写为 list.subList(Math.max(0, list.size() - N), list.size())

subList 在并发修改下会快速失败

如果在获取 subList 后，原集合被其他线程或代码通过非 subList 接口修改（如 add()、remove()），后续对子列表的任何操作（包括 size()、get(0)）都会触发 ConcurrentModificationException。

• 这不是线程安全问题，而是 fail-fast 机制——子列表内部维护了与原集合相同的 modCount 快照
• 即使单线程，只要原集合在 subList 创建后被修改过，子列表就失效
• 避免方式：要么不用 subList 做长期持有，要么确保原集合只读（如包装成 Collections.unmodifiableList）

LinkedList 上 subList 性能较差，慎用

ArrayList.subList 是 O(1) 时间复杂度，因为底层是数组；而 LinkedList.subList 是 O(n)，每次访问子列表元素都要从头遍历链表定位起始节点。

• 对 LinkedList 频繁调用 subList 并迭代，性能可能比直接遍历原链表还差
• 若业务需要频繁切片，优先考虑改用 ArrayList，或手动复制目标范围到新 ArrayList
• JDK 文档明确指出：LinkedList.subList 不推荐用于性能敏感场景

真正麻烦的不是怎么写 subList(from, to)，而是忘记它背后没有数据拷贝、没有线程隔离、也没有结构自由——它只是原集合上的一扇透明窗，开得越大，越容易被窗外的风吹乱。

以上就是《Java如何用subList获取集合子集》的详细内容，更多关于的资料请关注golang学习网公众号！