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

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

本文設計知識點如下：

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 不支援的增刪的實際原因。

你用你的新 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 。

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

為了防止 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 這種方式生成不可變集合。

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 將會不相等，這就導致迭代器遍歷時將會拋錯。

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

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

修復的辦法有兩種：

使用 Iterator#remove 刪除元素

JDK1.8 List#removeIf

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

思考

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

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

感興趣的同學可以自行研究原始碼，或者直接檢視 @why技術的文章：

這道Java基礎題真的有坑！我求求你，認真思考後再回答
這道Java基礎題真的有坑！我也沒想到還有續集。

總結

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

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

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

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

最後（求點贊，求關注）

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

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

歡迎關注我的公眾號：程式通事，獲得日常乾貨推送。如果您對我的專題內容感興趣，也可以關注我的部落格：studyidea.cn