![ebe37bf8df365f32627719e06b0d4f8a.png](https://i-blog.csdnimg.cn/blog_migrate/d34cbfa15966e2a76e580713f83c324e.jpeg)
![7ce662cf4a1a4d3e4f02de5122925ecd.png](https://i-blog.csdnimg.cn/blog_migrate/b0a999e6fd4213a423b55206941617c9.png)
List 可谓是我们经常使用的集合类之一,几乎所有业务代码都离不开 List。既然天天在用,那就没准就会踩中这几个 List 常见坑。
今天我们就来总结这些常见的坑在哪里,捞自己一手,防止后续同学再继续踩坑。
本文设计知识点如下:
![23549df29eddceaa80b7a4fc1646a376.png](https://i-blog.csdnimg.cn/blog_migrate/f9dde147a7d4384a1473f33fee88265e.jpeg)
ArrayList 这是李逵,还是李鬼?
以前实习的时候,写过这样一段简单代码,通过 Arrays#asList 将数组转化为 List 集合。
![4c9dbe32364c5fddab261e02ce768ef1.png](https://i-blog.csdnimg.cn/blog_migrate/f2959e575fc5ba96dfd847a56cd4f809.png)
这段代码表面看起来没有任何问题,编译也能通过,但是真正测试运行的时候将会在第 4 行抛出UnsupportedOperationException。
刚开始很不解,Arrays#asList 返回明明也是一个 ArrayList,为什么添加一个元素就会报错?这以后还能好好新增元素吗?
![ac4f5e3dec6646b48f9d96425aeaf261.png](https://i-blog.csdnimg.cn/blog_migrate/5c69d64bfa14127e21d27861a612c3fe.png)
最后通过 Debug 才发现这个Arrays#asList 返回的 ArrayList 其实是个李鬼,仅仅只是 Arrays 一个内部类,并非真正的 java.util.ArrayList。
![1b2982e9a48bb63a43612ae232061ce4.png](https://i-blog.csdnimg.cn/blog_migrate/87df61dc8e7e8e5ac3cd59d416b4b03e.png)
通过 IDEA,生成这两个的类图,如下:
![efd99cb7f0b08a58b0e3d7b577361db4.png](https://i-blog.csdnimg.cn/blog_migrate/5af91b35d68d907a06c3674e6d913b8c.jpeg)
从上图我们发现,add/remove 等方法实际都成自 AbstractList,而 java.util.Arrays$ArrayList 并没有重写父类的方法。而父类方法恰恰都会抛出 UnsupportedOperationException。
![b4d7d23df4931c2db5f625c17efeda37.png](https://i-blog.csdnimg.cn/blog_migrate/c55af4576a5bd5989dfb48d5aad018b2.png)
这就是为什么这个李鬼 ArrayList 不支持的增删的实际原因。
你用你的心 List,为什么却还互相影响
李鬼 ArrayList 除了不支持增删操作这个坑以外,还存在另外一个大坑,改动内部元素将会同步影响原数组。
![56099a3600870690a13e8fa836774697.png](https://i-blog.csdnimg.cn/blog_migrate/9922d3e52c3e97bb255e42b566bec73c.png)
输出结果:
arrays:[modify_1, modify_2, 3]
list:[modify_1, modify_2, 3]
从日志输出可以看到,不管我们是修改原数组,还是新 List 集合,两者都会互相影响。
查看 java.util.Arrays$ArrayList 实现,我们可以发现底层实际使用了原始数组。
![bf732bc556194c9b88ca846dc2f83383.png](https://i-blog.csdnimg.cn/blog_migrate/b5846c9af4080826a58b82385bfbabec.png)
知道了实际原因,修复的办法也很简单,套娃一层 ArrayList 呗!
List<String> list = new ArrayList<>(Arrays.asList(arrays));
不过这么写感觉十分繁琐,推荐使用 Guava Lists 提供的方法。
List<String> list = Lists.newArrayList(arrays);
通过上面两种方式,我们将新的 List 集合与原始数组解耦,不再互相影响,同时由于此时还是真正的 ArrayList,不用担心 add/remove报错了。
除了 Arrays#asList产生新集合与原始数组互相影响之外,JDK 另一个方法 List#subList 生成新集合也会与原始 List互相影响。
我们来看一个例子:
![37dfb8fbe208d787db5c119f6ceec88c.png](https://i-blog.csdnimg.cn/blog_migrate/d050af1eebd6f8657483fe15c9ab5384.png)
日志输出结果:
integerList:[10, 20, 3]
subList:[10, 20]
查看 List#subList 实现方式,可以发现这个 SubList 内部有一个 parent 字段保存保存最原始 List 。
![2e23732089f3b793cd85815704f3b37c.png](https://i-blog.csdnimg.cn/blog_migrate/e39f3e72c8d954b7e7cd738c2f5a3cf4.jpeg)
所有外部读写动作看起来是在操作 SubList ,实际上底层动作却都发生在原始 List 中,比如 add 方法:
![78bc3b36a71f38782c0d2b9ac69869ae.png](https://i-blog.csdnimg.cn/blog_migrate/ad30e882ee10f000b4df9efcbcbedc65.jpeg)
另外由于 SubList 实际上还在引用原始 List,业务开发中,如果不注意,很可能产生 OOM 问题。
以下例子来自于极客时间: Java业务开发常见错误100例
private static List<List<Integer>> data = new ArrayList<>();
private static void oom() {
for (int i = 0; i < 1000; i++) {
List<Integer> rawList = IntStream.rangeClosed(1, 100000).boxed().collect(Collectors.toList());
data.add(rawList.subList(0, 1));
}
}
data 看起来最终保存的只是 1000 个具有 1 个元素的 List,不会占用很大空间。但是程序很快就会 OOM。
OOM 的原因正是因为每个 SubList 都强引用个一个 10 万个元素的原始 List,导致 GC 无法回收。
这里修复的办法也很简单,跟上面一样,也来个套娃呗,加一层 ArrayList 。
![ad29127dd9f7497c67dfde4d7372e6d2.png](https://i-blog.csdnimg.cn/blog_migrate/d4075c0de5f74872dc2dc4807908701e.png)
不可变集合,说好不变,你怎么就变了
为了防止 List 集合被误操作,我们可以使用 Collections#unmodifiableList 生成一个不可变(immutable)集合,进行防御性编程。
这个不可变集合只能被读取,不能做任何修改,包括增加,删除,修改,从而保护不可变集合的安全。
![ed19ec7363a5e5ab30bfd0c73b2be30e.png](https://i-blog.csdnimg.cn/blog_migrate/b32717ae55a87bc50e6d9f3b81136888.png)
上面最后三行写操作都将会抛出 UnsupportedOperationException 异常
但是你以为这样就安全了吗?
![aea36dd6752fb481aac1ca91d4d85f9d.png](https://i-blog.csdnimg.cn/blog_migrate/487ca065bed03c34b73853b9251c1468.png)
如果有谁不小心改动原始 List,你就会发现这个不可变集合,竟然就变了。。。
![1c3c05e504fa797110ac3664d684c632.png](https://i-blog.csdnimg.cn/blog_migrate/10004abeee747944086b23e29f3cf924.png)
上面单元测试结果将会全部通过,这就代表 Collections#unmodifiableList 产生不可变集合将会被原始 List 所影响。
查看 Collections#unmodifiableList 底层实现方法:
![fd7f704469228fa2bd0e1055bf036c6a.png](https://i-blog.csdnimg.cn/blog_migrate/d48f63c32ef1aba4f367b4a1f2c5ac8f.png)
可以看到这跟上面 SubList 其实是同一个问题,新集合底层实际使用了原始 List。
由于不可变集合所有修改操作都会报错,所以不可变集合不会产生任何改动,所以并不影响的原始集合。但是防过来,却不行,原始 List 随时都有可能被改动,从而影响不可变集合。
可以使用如下两种方式防止上卖弄的情况。
使用 JDK9 List#of 方法。
List<String> list = new ArrayList<>(Arrays.asList("one", "two", "three"));
List<String> unmodifiableList = List.of(list.toArray(new String[]{}));
使用 Guava immutable list
List<String> list = new ArrayList<>(Arrays.asList("one", "two", "three"));
List<String> unmodifiableList = ImmutableList.copyOf(list);
相比而言 Guava 方式比较清爽,使用也比较简单,推荐使用 Guava 这种方式生成不可变集合。
foreach 增加/删除元素大坑
先来看一段代码:
String[] arrays = {"1", "2", "3"};
List<String> list = new ArrayList<>(Arrays.asList(arrays));
for (String str : list) {
if (str.equals("1")) {
list.remove(str);
}
}
上面的代码我们使用 foreach 方式遍历 List 集合,如果符合条件,将会从集合中删除改元素。
这个程序编译正常,但是运行时,程序将会发生异常,日志如下:
java.util.ConcurrentModificationException
at java.base/java.util.ArrayList$Itr.checkForComodification(ArrayList.java:939)
at java.base/java.util.ArrayList$Itr.next(ArrayList.java:893)
可以看到程序最终错误是由 ArrayList$Itr.next 处的代码抛出,但是代码中我们并没有调用该方法,为什么会这样?
实际是因为 foreach 这种方式实际上 Java 给我们提供的一种语法糖,编译之后将会变为另一种方式。
我们将上面的代码产生 class 文件反编来看下最后代码长的啥样。
![6036970ac35cc87360c16f540994af9f.png](https://i-blog.csdnimg.cn/blog_migrate/53285e9d2b13ce5ec2eb9f94234e764b.png)
可以看到 foreach 这种方式实际就是 Iterator 迭代器实现方式,这就是为什么 foreach 被遍历的类需要实现 Iterator接口的原因。
接着我们来看下抛出异常方法:
![5e100f8579c3f822780a636af0c50fde.png](https://i-blog.csdnimg.cn/blog_migrate/b3ffc9c8f103a6563165b5b7df288761.jpeg)
expectedModCount 来源于 list#iterator 方法:
![5e09a9556afa119bf8de6a6c952c17ea.png](https://i-blog.csdnimg.cn/blog_migrate/249a265c114141f5d19286276f527eb8.png)
也就是说刚开始遍历循环的时候 expectedModCount==modCount,下面我们来看下 modCount。
modCount 来源于 ArrayList 的父类 AbstractList,可以用来记录 List 集合被修改的次数。
![6784ae7d3209a2e4e2f84c772e99776f.png](https://i-blog.csdnimg.cn/blog_migrate/f6c887af12ddcac9807205583c684537.jpeg)
ArrayList#remove 之后将会使 modCount 加一,expectedModCount与 modCount 将会不相等,这就导致迭代器遍历时将会抛错。
![534d32bc455e7bd95f8ccade6d763aac.png](https://i-blog.csdnimg.cn/blog_migrate/26697bbedf79b5c314244b582af87e38.png)
modCount 计数操作将会交子类自己操作,ArrayList 每次修改操作(增、删)都会使 modCount 加 1。但是如 CopyOnWriteArrayList 并不会使用 modCount 计数。
所以 CopyOnWriteArrayList 使用 foreach 删除是安全的,但是还是建议使用如下两种删除元素,统一操作。
修复的办法有两种:
使用 Iterator#remove 删除元素
![b7e6cd11ff7a5d89a41e6684947ad767.png](https://i-blog.csdnimg.cn/blog_migrate/0ec7dd012abc8e8795f19a22c784b311.png)
JDK1.8 List#removeIf
![bc1335e2cbe28e67971db60a58d60740.png](https://i-blog.csdnimg.cn/blog_migrate/27dffcb43f2a45be5190d9d69e335aad.png)
推荐使用 JDK1.8 这种方式,简洁明了。
思考
如果我将上面 foreach 代码判断条件简单修改一下:
![3db84d6b6a9b2183b248233b5d504589.png](https://i-blog.csdnimg.cn/blog_migrate/3ce2f7c5dcbd3a23bd46f4c6a1f39a34.png)
运行这段代码,可以发现这段代码又不会报错了,有没有很意外?
感兴趣的同学可以自行研究源码,或者直接查看 @why技术的文章:
这道Java基础题真的有坑!我求求你,认真思考后再回答这道Java基础题真的有坑!我也没想到还有续集。
总结
第一,我们不要先入为主,想当然就认为 Arrays.asList 和 List.subList 就是一个普通,独立的 ArrayList。
如果没办法,使用了 Arrays.asList 和 List.subList ,返回给其他方法的时候,一定要记得再套娃一层真正的 java.util.ArrayList。
第二 JDK 的提供的不可变集合实际非常笨重,并且低效,还不安全,所以推荐使用 Guava 不可变集合代替。
最后,切记,不要随便在 foreach增加/删除元素。