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

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技術的文章：

總結

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

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

第二 JDK 的提供的不可變集合實際很是笨重，而且低效，還不安全，因此推薦使用 Guava 不可變集合代替。

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

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

最後（求點贊，求關注）

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

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

歡迎關注個人公衆號：程序通事，得到平常乾貨推送。若是您對個人專題內容感興趣，也能夠關注個人博客： studyidea.cn