一口氣帶你踩完五個 List 的大坑，真的是處處坑啊！|原創

List 可謂是我們經常使用的集合類之一，幾乎所有業務代碼都離不開 List。既然天天在用，那就沒準就會踩中這幾個 List 常見坑。

今天我們就來總結這些常見的坑在哪裡，撈自己一手，防止後續同學再繼續踩坑。

本文設計知識點如下：

List 踩坑大全

ArrayList 這是李逵，還是李鬼？

以前實習的時候，寫過這樣一段簡單代碼，通過 ArraysasList 返回明明也是一個 ArrayList，為什麼添加一個元素就會報錯？這以後還能好好新增元素嗎？

最後通過 Debug 才發現這個ArraysasList產生新集合與原始數組互相影響之外，JDK 另一個方法 ListsubList 實現方式，可以發現這個 SubList 內部有一個 parent 欄位保存保存最原始 List 。

image-20200419163334939

所有外部讀寫動作看起來是在操作 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 。

不可變集合，說好不變，你怎麼就變了

為了防止 List 集合被誤操作，我們可以使用 CollectionsunmodifiableList 產生不可變集合將會被原始 List 所影響。

查看 Collectionsof 方法。

List<String> list = new ArrayList<>(Arrays.asList(&34;, &34;, &34;));List<String> unmodifiableList = List.of(list.toArray(new String[]{}));

使用 Guava immutable list

List<String> list = new ArrayList<>(Arrays.asList(&34;, &34;, &34;));List<String> unmodifiableList = ImmutableList.copyOf(list);

相比而言 Guava 方式比較清爽，使用也比較簡單，推薦使用 Guava 這種方式生成不可變集合。

foreach 增加/刪除元素大坑

先來看一段代碼：

String[] arrays = {&34;, &34;, &34;};List<String> list = new ArrayList<>(Arrays.asList(arrays));for (String str : list) {    if (str.equals(&34;)) {        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 文件反編來看下最後代碼長的啥樣。

fanbainyi

可以看到 foreach 這種方式實際就是 Iterator 迭代器實現方式，這就是為什麼 foreach 被遍歷的類需要實現 Iterator接口的原因。

接著我們來看下拋出異常方法：

expectedModCount 來源於 listremove 之後將會使 modCount 加一，expectedModCount與 modCount 將會不相等，這就導致迭代器遍歷時將會拋錯。

modCount 計數操作將會交子類自己操作，ArrayList 每次修改操作（增、刪）都會使 modCount 加 1。但是如 CopyOnWriteArrayList 並不會使用 modCount 計數。

所以 CopyOnWriteArrayList 使用 foreach 刪除是安全的，但是還是建議使用如下兩種刪除元素，統一操作。

修復的辦法有兩種：

使用 IteratorremoveIf

推薦使用 JDK1.8 這種方式，簡潔明了。

思考

如果我將上面 foreach 代碼判斷條件簡單修改一下：

remove

運行這段代碼，可以發現這段代碼又不會報錯了，有沒有很意外？

感興趣的同學可以自行研究源碼，或者直接查看 @why技術的文章：

總結

第一，我們不要先入為主，想當然就認為 Arrays.asList 和 List.subList 就是一個普通，獨立的 ArrayList。

如果沒辦法，使用了 Arrays.asList 和 List.subList ，返回給其他方法的時候，一定要記得再套娃一層真正的 java.util.ArrayList。

第二 JDK 的提供的不可變集合實際非常笨重，並且低效，還不安全，所以推薦使用 Guava 不可變集合代替。

最後，切記，不要隨便在 foreach增加/刪除元素。

最後（求點讚，求關注）

你在 List 集合使用過程還踩過什麼坑，歡迎留言討論。

我是樓下小黑哥，我們下篇文章再見~