Java集合的这个坑，我调试了整整3小时才爬出来

• Java集合的这个坑，我调试了整整3小时才爬出来*

---

引言

在Java开发中，集合框架（Collections Framework）是我们日常使用最频繁的组件之一。无论是List、Set还是Map，它们为数据的存储和操作提供了强大的支持。然而，正是因为其使用频率高，隐藏在其中的一些"坑"往往会让开发者付出惨痛的调试代价。最近，我就因为一个看似简单的集合操作，花了整整3小时才找到问题的根源。本文将详细剖析这个问题的背景、原因以及解决方案，希望能帮助其他开发者避免类似的陷阱。

问题背景

问题的起因是这样的：我在处理一个List时，尝试使用Collections.sort()方法对列表进行排序，然后在后续的逻辑中使用了List.subList()方法获取子列表。然而，当我尝试修改子列表时，却意外地发现原始列表也被修改了，而且更诡异的是，在某些情况下还会抛出ConcurrentModificationException。这完全不符合我的预期，于是我开始了一段漫长的调试之旅。

问题复现

为了更好地理解这个问题，我们先来看一段简化后的代码：

List<Integer> numbers = new ArrayList<>(Arrays.asList(3, 1, 4, 1, 5, 9));
Collections.sort(numbers); // 排序
List<Integer> subList = numbers.subList(1, 4); // 获取子列表
subList.set(0, 100); // 修改子列表
System.out.println("Original list: " + numbers);
System.out.println("Sub list: " + subList);

运行这段代码后，输出如下：

Original list: [1, 100, 1, 4, 5, 9]
Sub list: [100, 1, 4]

可以看到，修改子列表subList的同时，原始列表numbers也被修改了！这就是问题的核心所在。

深入分析

1. subList()的实现原理

为了理解这个问题，我们需要深入探讨List.subList()方法的实现。以ArrayList为例，subList()方法返回的是一个SubList内部类的实例，而不是一个新的ArrayList。SubList是原始列表的一个"视图"（view），它直接引用了原始列表的数据结构。这意味着任何对子列表的修改都会直接反映到原始列表上。

以下是ArrayList.subList()的简化实现：

public List<E> subList(int fromIndex, int toIndex) {
    return new SubList(this, fromIndex, toIndex);
}

SubList内部类通过offset和size来标识子列表的范围，所有的操作（如get、set、add等）都是基于原始列表的：

public E set(int index, E element) {
    rangeCheck(index);
    checkForComodification();
    E oldValue = ArrayList.this.elementData(offset + index);
    ArrayList.this.elementData[offset + index] = element;
    return oldValue;
}

从代码中可以看出，subList.set()直接修改了原始列表的底层数组。

2. ConcurrentModificationException的触发条件

另一个让人头疼的问题是ConcurrentModificationException。这个问题通常出现在以下场景中：

List<Integer> numbers = new ArrayList<>(Arrays.asList(3, 1, 4, 1, 5, 9));
List<Integer> subList = numbers.subList(1, 4);
numbers.add(10); // 修改原始列表
System.out.println(subList); // 这里会抛出ConcurrentModificationException

这是因为SubList在每次操作时会检查原始列表的modCount（修改计数器）是否与创建子列表时的值一致。如果原始列表被修改（如添加或删除元素），modCount会增加，导致子列表的操作抛出异常。

3. 排序与子列表的交互问题

回到最初的问题，Collections.sort()对原始列表进行排序后，子列表的"视图"仍然依赖于原始列表的底层数组。因此，对子列表的修改会直接影响到原始列表。这种隐式的依赖关系往往容易被忽视，尤其是在复杂的业务逻辑中。

解决方案

1. 创建子列表的独立副本

如果希望子列表的修改不影响原始列表，最简单的方法是创建一个新的ArrayList：

List<Integer> subList = new ArrayList<>(numbers.subList(1, 4));

这样，subList就是一个独立的列表，对它的修改不会影响原始列表。

2. 避免在子列表存在时修改原始列表

如果需要保留子列表的"视图"特性，必须确保在子列表的生命周期内不修改原始列表的结构（如添加或删除元素）。如果必须修改，可以先将子列表转换为独立副本：

List<Integer> subList = numbers.subList(1, 4);
List<Integer> subListCopy = new ArrayList<>(subList);
numbers.add(10); // 修改原始列表
// 使用subListCopy而不是subList

3. 使用不可变集合

如果业务逻辑允许，可以使用不可变集合（如Guava的ImmutableList）来避免意外的修改：

List<Integer> numbers = ImmutableList.of(3, 1, 4, 1, 5, 9);
List<Integer> subList = numbers.subList(1, 4);
// subList.set(0, 100); // 抛出UnsupportedOperationException

最佳实践

1. 明确区分视图与副本 ：在使用subList()时，必须清楚它是视图还是副本。视图会反映原始列表的修改，而副本是独立的。
2. 防御性编程：如果无法确保原始列表不被修改，应优先使用副本。
3. 文档注释：在代码中明确标注子列表的特性，避免其他开发者误用。
4. 单元测试覆盖：针对子列表的使用场景编写单元测试，确保其行为符合预期。

总结

Java集合框架虽然强大，但其中隐藏的陷阱也不少。subList()方法的设计初衷是为了提供一种高效的方式操作列表的子范围，但其"视图"特性往往会让开发者踩坑。通过深入理解其实现原理，我们可以更好地规避这些问题。希望本文能帮助你减少调试时间，写出更健壮的代码！