List 使用踩坑记录

最新推荐文章于 2024-07-24 15:12:14 发布

寸劲开苍穹

最新推荐文章于 2024-07-24 15:12:14 发布

阅读量158

点赞数

分类专栏： java基础文章标签： list java 数据结构

原文链接：https://mp.weixin.qq.com/s/9bw2-pkuYSKEnstb4KGsqQ

版权

java基础专栏收录该内容

18 篇文章 0 订阅

订阅专栏

文章目录

1. ArrayList 这是李逵，还是李鬼？
2. 你用你的新 List，为什么却还互相影响
3. 不可变集合，说好不变，你怎么就变了
4. foreach 增加/删除元素大坑
5. 总结

List可谓是我们经常使用的集合类之一，几乎所有业务代码都离不开 List。既然天天在用，那就没准就会踩中这几个 List常见坑。
今天我们就来总结这些常见的坑在哪里，捞自己一手，防止后续同学再继续踩坑。

本文设计知识点如下：
List 踩坑大全

1. ArrayList 这是李逵，还是李鬼？

以前实习的时候，写过这样一段简单代码，通过Arrays#asList将数组转化为List集合。

这段代码表面看起来没有任何问题，编译也能通过，但是真正测试运行的时候将会在第4行抛出 UnsupportedOperationException。

刚开始很不解，Arrays#asList返回明明也是一个ArrayList，为什么添加一个元素就会报错？这以后还能好好新增元素吗？

最后通过Debug才发现这个Arrays#asList返回的ArrayList其实是个李鬼，仅仅只是Arrays一个内部类，并非真正的 java.util.ArrayList。

通过 IDEA，生成这两个的类图，如下：

从上图我们发现，add/remove等方法实际都来自AbstractList，而 java.util.Arrays$ArrayList并没有重写父类的方法。而父类方法恰恰都会抛出UnsupportedOperationException。

这就是为什么这个李鬼 ArrayList不支持的增删的实际原因。

2. 你用你的新 List，为什么却还互相影响

李鬼ArrayList除了不支持增删操作这个坑以外，还存在另外一个大坑，改动内部元素将会同步影响原数组。

输出结果：

arrays:[modify_1, modify_2, 3]
list:[modify_1, modify_2, 3]

从日志输出可以看到，不管我们是修改原数组，还是新 List 集合，两者都会互相影响。

查看java.util.Arrays$ArrayList实现，我们可以发现底层实际使用了原始数组。

知道了实际原因，修复的办法也很简单，套娃一层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互相影响。

我们来看一个例子：

日志输出结果：

integerList:[10, 20, 3]
subList:[10, 20]

查看List#subList实现方式，可以发现这个SubList内部有一个 parent字段保存保存最原始List。

所有外部读写动作看起来是在操作SubList ，实际上底层动作却都发生在原始List中，比如add方法：

另外由于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。

3. 不可变集合，说好不变，你怎么就变了

为了防止List集合被误操作，我们可以使用 Collections#unmodifiableList生成一个不可变（immutable）集合，进行防御性编程。

这个不可变集合只能被读取，不能做任何修改，包括增加，删除，修改，从而保护不可变集合的安全。

上面最后三行写操作都将会抛出UnsupportedOperationException异常

但是你以为这样就安全了吗？

如果有谁不小心改动原始List，你就会发现这个不可变集合，竟然就变了。。。

上面单元测试结果将会全部通过，这就代表 Collections#unmodifiableList产生不可变集合将会被原始List所影响。

查看Collections#unmodifiableList底层实现方法：

可以看到这跟上面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这种方式生成不可变集合。

4. 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文件反编来看下最后代码长的啥样。

可以看到foreach这种方式实际就是Iterator迭代器实现方式，这就是为什么foreach 被遍历的类需要实现Iterator接口的原因。

接着我们来看下抛出异常方法：

expectedModCount来源于 list#iterator方法：

也就是说刚开始遍历循环的时候expectedModCount==modCount，下面我们来看下modCount。

modCount来源于ArrayList的父类AbstractList，可以用来记录List集合被修改的次数。

ArrayList#remove之后将会使modCount加一，expectedModCount与 modCount将会不相等，这就导致迭代器遍历时将会抛错。