说实话，写Java代码这么久，Zui让人头秃的往往不是那些复杂的算法逻辑，而是那些你自以为“闭着眼睛douNeng写对”的基础API。就在前两天我本来以为Neng准点下班的，结果被一个kan似人畜无害的集合操作硬生生拖在了工位上整整三个小时。那种kan着屏幕上红色的报错信息，脑子里一片空白的绝望感，我想大家多少dou体会过吧。

事情的起因特别简单，简单到我现在dou不好意思说出来。我正在处理一段业务逻辑，需要对一个列表进行排序，然后取其中的一部分数据进行后续处理。这有什么难的呢？我想dou没想，就直接祭出了`Collections.sort`和`List.subList`这两个“大杀器”。结果，这一用不要紧，直接给我挖了个大坑。今天咱们就来好好复盘一下这个让人抓狂的“坑”，顺便聊聊Java集合框架里那些容易被忽视的细节。

那个让人崩溃的下午：问题复现

为了让大家感同身受，我把当时那段让我痛不欲生的代码简化了一下。大概的逻辑是这样的：我们有一个数字列表，先排个序，然后截取前半部分，Zui后修改一下截取出来的子列表。

List numbers = new ArrayList<>);
Collections.sort; // 先排个序，这hen合理吧
List subList = numbers.subList; // 取前三个小的
subList.set; // 修改子列表的第一个元素
System.out.println;
System.out.println;

当时我的预期是`subList`就是一份独立的数据，我改它，跟原来的`numbers`有个毛线关系啊？结果控制台打印出来的东西，直接让我怀疑人生：

原始列表: 
子列表: 

kan到没？原始列表竟然被改了！这完全不符合直觉啊。我当时的第一反应是：我电脑是不是中病毒了？还是JDK出Bug了？当然理智告诉我，肯定是我自己哪里理解偏了。但这还没完，geng刺激的在后面。Ru果在获取子列表之后我不小心动了原始列表的结构，比如往里面加个元素，那场面就geng血腥了。

List numbers = new ArrayList<>);
List subList = numbers.subList;
numbers.add; // 手贱，改了原始列表
System.out.println); // 试图访问子列表

这段代码一跑，直接给你甩一个大大的`ConcurrentModificationException`。这就hen搞笑了我明明是在单线程里跑的代码，哪里来的并发修改异常？这也就是标题里说的，让我花了三个小时才调试出来的“坑”。

刨根问底：视图与副本的恩怨情仇

为了搞清楚这到底是怎么回事，咱们得钻进源码里kankan。hen多时候，kan文档不如kan代码来得实在。虽然kan源码有点枯燥，但这往往是解决问题的捷径。

问题的核心就在于`ArrayList.subList`这个方法。你可Neng会以为，它像`new ArrayList`那样，给你把数据拷贝一份出来返回给你。但实际上，它是个“骗子”。它返回的其实是一个`ArrayList`的内部类，叫`SubList`。

public List subList {
    subListRangeCheck;
    return new SubList;
}

注意kan这个构造函数，它传了一个`this`进去。这意味着什么？意味着这个`SubList`手里紧紧攥着原始列表的引用！它根本不是什么独立的副本，它只是原始列表的一个“视图”。这就好比你在墙上开了个窗户，你透过窗户kan外面的风景，Ru果你透过窗户往外面扔石头，外面的风景自然就变了。

这个`SubList`内部并没有重新存一份数据，它只是记录了几个关键参数：`offset`、`size`以及`parent`。当你调用`subList.get`的时候，它实际上是在调用`parent.get`。

咱们再kankan刚才那个修改子列表导致原始列表跟着变的代码，kankan`SubList`的`set`方法是怎么写的：

public E set {
    rangeCheck;
    checkForComodification;
    E oldValue = ArrayList.this.elementData;
    ArrayList.this.elementData = element;
    return oldValue;
}

kan到了吗？`ArrayList.this.elementData = element;` 这行代码直接操作了原始列表的底层数组！所以你修改子列表，实际上就是在修改原始列表对应位置的数据。这就是为什么“牵一发而动全身”的原因。

那个诡异的异常又是怎么回事？

那为什么修改原始列表的结构会导致子列表抛出`ConcurrentModificationException`呢？这就要提到Java集合里一个著名的机制——modCount了。

ArrayList里维护了一个`modCount`字段，每当列表的结构发生改变，这个计数器就会加一。而`SubList`在创建的时候，会记录下当前原始列表的`modCount`值。

每次你在操作子列表的时候，它dou会先调用一个`checkForComodification`方法：

final void checkForComodification {
    if 
        throw new ConcurrentModificationException;
}

Ru果你在拿到子列表后又去动了原始列表，那么原始列表的`modCount`就变了。当你再去操作子列表时子列表发现：“咦？怎么现在的`modCount`跟我当初记录的不一样了？肯定有人背着我偷偷改了数据！”于是为了保护数据的一致性，它就果断抛出了异常。

这就是为什么在单线程环境下也会出现并发修改异常的原因。这名字确实有点误导人，让人以为是多线程并发的问题，其实它geng多是表达一种“快速失败”的保护机制。

填坑指南：如何安全地使用子列表

既然知道了原理，那咱们就得想办法避开这些坑。毕竟`subList`这个方法在处理大数据量的时候，因为不需要拷贝数据，效率还是hen高的，直接弃用不用有点可惜。

1. 明确你的需求：视图还是副本？

这是Zui重要的一点。Ru果你只是想临时读取一下列表的某一部分，而且确定在读取期间原始列表不会被修改，那用`subList`完全没问题，它既省内存又快。

但是Ru果你需要把子列表传给别的模块，或者后续需要对子列表进行修改，并且不希望影响原始列表，那就千万别偷懒。一定要把它变成一个独立的副本。Zui简单的方式就是用构造器：

List numbers = new ArrayList<>);
// 创建一个真正的副本，切断与原始列表的联系
List subListCopy = new ArrayList<>);
numbers.add; // 现在怎么改原始列表dou不怕了
subListCopy.set; // 改副本也不影响原始列表

这样写，虽然多了一点点内存开销，但是换来的是代码的健壮性和安全性，这笔买卖绝对划算。特别是在复杂的业务逻辑中，防御性编程Neng帮你省下无数个调试的夜晚。

2. 使用不可变集合

Ru果你的业务场景允许，Ke以考虑使用Guava库提供的`ImmutableList`，或者其他不可变集合。不可变集合一旦创建就不Neng修改，这从根源上杜绝了意外修改的可Neng性。

List numbers = ImmutableList.of;
List subList = numbers.subList;
// subList.set; // 这行代码会直接抛出UnsupportedOperationException

虽然这kan起来有点限制自由，但特别是作为参数传递的时候，不可变对象Neng极大地减少出错的概率。

顺便聊聊其他常见的集合“坑”

既然说到了集合的坑，我就顺便多唠叨两句。除了`subList`，Java集合里还有几个让人防不胜防的陷阱。

Arrays.asList的局限性

hen多新手喜欢用`Arrays.asList`来把数组转成List，觉得方便快捷。但是这个方法返回的List并不是我们熟悉的`java.util.ArrayList`，而是一个内部类`Arrays.ArrayList`。这个家伙是固定大小的，不支持增删操作。

String myArray = {"a", "b", "c"};
List myList = Arrays.asList;
myList.add; // 抛出UnsupportedOperationException

Ru果你需要对这个List进行增删，还是得乖乖地用`new ArrayList<>)`包一层。

遍历时删除元素

这也是个老生常谈的问题了。hen多人在遍历List的时候，想顺手删掉一些元素，结果直接写个for循环然后调用`remove`。这也会触发`ConcurrentModificationException`。

标准的姿势之一是使用迭代器，并调用迭代器的`remove`方法。或者，Ru果你用的是Java 8以上，用`removeIf`方法简直不要太爽：

list.removeIf);

这代码写出来既简洁又安全，kan着就舒服。

回过头来kan，这Java集合框架虽然强大，用起来也方便，但里面的门道确实不少。`subList`这个坑，本质上是因为它为了性Neng牺牲了一部分易用性，采用了“视图”的设计模式。Ru果我们不了解其背后的实现原理，hen容易就会掉进坑里花大把时间去调试。

写代码这事儿，有时候真的不Neng想当然。哪怕是Zui简单的API，稍微翻翻源码，或者写个小小的测试用例验证一下可Neng就Neng帮你省下好几个小时的Debug时间。希望我这次踩过的坑，Neng给大家提个醒。下次再用`subList`的时候，千万记得问自己一句：“我到底是要个视图，还是要个副本？”

好了今天的分享就到这里。希望大家以后写代码douNeng顺顺利利，准点下班！Ru果觉得这篇文章对你有帮助，别忘了点个赞或者收藏一下万一以后真的遇到了这个问题，还Neng回来kankan怎么救急。

---