List 可謂是我們經(jīng)常使用的集合類之一，幾乎所有業(yè)務(wù)代碼都離不開 List。既然天天在用，那就沒準(zhǔn)就會(huì)踩中這幾個(gè) List 常見坑。
今天我們就來(lái)總結(jié)這些常見的坑在哪里，撈自己一手，防止后續(xù)同學(xué)再繼續(xù)踩坑。
本文設(shè)計(jì)知識(shí)點(diǎn)如下：
ArrayList 這是李逵，還是李鬼？
以前實(shí)習(xí)的時(shí)候，寫過(guò)這樣一段簡(jiǎn)單代碼，通過(guò) Arrays#asList 將數(shù)組轉(zhuǎn)化為 List 集合。
這段代碼表面看起來(lái)沒有任何問(wèn)題，編譯也能通過(guò)，但是真正測(cè)試運(yùn)行的時(shí)候?qū)?huì)在第 4 行拋出UnsupportedOperationException。
剛開始很不解，Arrays#asList 返回明明也是一個(gè) ArrayList，為什么添加一個(gè)元素就會(huì)報(bào)錯(cuò)？這以后還能好好新增元素嗎？
最后通過(guò) Debug 才發(fā)現(xiàn)這個(gè)Arrays#asList 返回的 ArrayList 其實(shí)是個(gè)李鬼，僅僅只是 Arrays 一個(gè)內(nèi)部類，并非真正的 java.util.ArrayList。
通過(guò) IDEA，生成這兩個(gè)的類圖，如下：
從上圖我們發(fā)現(xiàn)，add/remove 等方法實(shí)際都成自 AbstractList，而 java.util.Arrays$ArrayList 并沒有重寫父類的方法。而父類方法恰恰都會(huì)拋出 UnsupportedOperationException。
這就是為什么這個(gè)李鬼 ArrayList 不支持的增刪的實(shí)際原因。
你用你的心 List，為什么卻還互相影響
李鬼 ArrayList 除了不支持增刪操作這個(gè)坑以外，還存在另外一個(gè)大坑，改動(dòng)內(nèi)部元素將會(huì)同步影響原數(shù)組。
輸出結(jié)果：
arrays:[modify_1, modify_2, 3]
list:[modify_1, modify_2, 3]
從日志輸出可以看到，不管我們是修改原數(shù)組，還是新 List 集合，兩者都會(huì)互相影響。
查看 java.util.Arrays$ArrayList 實(shí)現(xiàn)，我們可以發(fā)現(xiàn)底層實(shí)際使用了原始數(shù)組。
知道了實(shí)際原因，修復(fù)的辦法也很簡(jiǎn)單，套娃一層 ArrayList 唄！
List list = new ArrayList<>(Arrays.asList(arrays));
不過(guò)這么寫感覺十分繁瑣，推薦使用?Guava Lists?提供的方法。
List list = Lists.newArrayList(arrays);
通過(guò)上面兩種方式，我們將新的 List 集合與原始數(shù)組解耦，不再互相影響，同時(shí)由于此時(shí)還是真正的 ArrayList，不用擔(dān)心 add/remove報(bào)錯(cuò)了。
除了 Arrays#asList產(chǎn)生新集合與原始數(shù)組互相影響之外，JDK 另一個(gè)方法 List#subList 生成新集合也會(huì)與原始 List互相影響。
我們來(lái)看一個(gè)例子：
日志輸出結(jié)果：
integerList:[10, 20, 3]
subList:[10, 20]
查看 List#subList 實(shí)現(xiàn)方式，可以發(fā)現(xiàn)這個(gè) SubList 內(nèi)部有一個(gè) parent 字段保存保存最原始 List 。
所有外部讀寫動(dòng)作看起來(lái)是在操作 SubList ，實(shí)際上底層動(dòng)作卻都發(fā)生在原始 List 中，比如 add 方法：
另外由于 SubList 實(shí)際上還在引用原始 List，業(yè)務(wù)開發(fā)中，如果不注意，很可能產(chǎn)生?OOM?問(wèn)題。
以下例子來(lái)自于極客時(shí)間：Java業(yè)務(wù)開發(fā)常見錯(cuò)誤100例
private static List> data = new ArrayList<>();
private static void oom() {
for (int i = 0; i < 1000; i++) {
List rawList = IntStream.rangeClosed(1, 100000).boxed().collect(Collectors.toList());
data.add(rawList.subList(0, 1));
}
}
data 看起來(lái)最終保存的只是 1000 個(gè)具有 1 個(gè)元素的 List，不會(huì)占用很大空間。但是程序很快就會(huì)?OOM。
OOM?的原因正是因?yàn)槊總€(gè) SubList 都強(qiáng)引用個(gè)一個(gè) 10 萬(wàn)個(gè)元素的原始 List，導(dǎo)致 GC 無(wú)法回收。
這里修復(fù)的辦法也很簡(jiǎn)單，跟上面一樣，也來(lái)個(gè)套娃唄，加一層 ArrayList 。
不可變集合，說(shuō)好不變，你怎么就變了
為了防止 List 集合被誤操作，我們可以使用 Collections#unmodifiableList 生成一個(gè)不可變（immutable）集合，進(jìn)行防御性編程。
這個(gè)不可變集合只能被讀取，不能做任何修改，包括增加，刪除，修改，從而保護(hù)不可變集合的安全。
上面最后三行寫操作都將會(huì)拋出 UnsupportedOperationException 異常
但是你以為這樣就安全了嗎？
如果有誰(shuí)不小心改動(dòng)原始 List，你就會(huì)發(fā)現(xiàn)這個(gè)不可變集合，竟然就變了。。。
上面單元測(cè)試結(jié)果將會(huì)全部通過(guò)，這就代表 Collections#unmodifiableList 產(chǎn)生不可變集合將會(huì)被原始 List 所影響。
查看 Collections#unmodifiableList 底層實(shí)現(xiàn)方法：
可以看到這跟上面 SubList 其實(shí)是同一個(gè)問(wèn)題，新集合底層實(shí)際使用了原始 List。
由于不可變集合所有修改操作都會(huì)報(bào)錯(cuò)，所以不可變集合不會(huì)產(chǎn)生任何改動(dòng)，所以并不影響的原始集合。但是防過(guò)來(lái)，卻不行，原始 List 隨時(shí)都有可能被改動(dòng)，從而影響不可變集合。
可以使用如下兩種方式防止上賣弄的情況。
使用 JDK9 List#of 方法。
List list = new ArrayList<>(Arrays.asList("one", "two", "three"));
List unmodifiableList = List.of(list.toArray(new String[]{}));
使用 Guava immutable list
List list = new ArrayList<>(Arrays.asList("one", "two", "three"));
List unmodifiableList = ImmutableList.copyOf(list);
相比而言 Guava 方式比較清爽，使用也比較簡(jiǎn)單，推薦使用 Guava 這種方式生成不可變集合。
foreach 增加/刪除元素大坑
先來(lái)看一段代碼：
String[] arrays = {"1", "2", "3"};
List list = new ArrayList<>(Arrays.asList(arrays));
for (String str : list) {
if (str.equals("1")) {
list.remove(str);
}
}
上面的代碼我們使用 foreach 方式遍歷 List 集合，如果符合條件，將會(huì)從集合中刪除改元素。
這個(gè)程序編譯正常，但是運(yùn)行時(shí)，程序?qū)?huì)發(fā)生異常，日志如下：
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)
可以看到程序最終錯(cuò)誤是由 ArrayList$Itr.next 處的代碼拋出，但是代碼中我們并沒有調(diào)用該方法，為什么會(huì)這樣?
實(shí)際是因?yàn)?foreach 這種方式實(shí)際上 Java 給我們提供的一種語(yǔ)法糖，編譯之后將會(huì)變?yōu)榱硪环N方式。
我們將上面的代碼產(chǎn)生 class 文件反編來(lái)看下最后代碼長(zhǎng)的啥樣。
可以看到 foreach 這種方式實(shí)際就是 Iterator 迭代器實(shí)現(xiàn)方式，這就是為什么 foreach 被遍歷的類需要實(shí)現(xiàn) Iterator接口的原因。
接著我們來(lái)看下拋出異常方法：
expectedModCount 來(lái)源于 list#iterator 方法：
也就是說(shuō)剛開始遍歷循環(huán)的時(shí)候 expectedModCount==modCount，下面我們來(lái)看下 modCount。
modCount 來(lái)源于 ArrayList 的父類 AbstractList，可以用來(lái)記錄 List 集合被修改的次數(shù)。
ArrayList#remove 之后將會(huì)使 modCount 加一，expectedModCount與 modCount 將會(huì)不相等，這就導(dǎo)致迭代器遍歷時(shí)將會(huì)拋錯(cuò)。
modCount 計(jì)數(shù)操作將會(huì)交子類自己操作，ArrayList 每次修改操作（增、刪）都會(huì)使 modCount 加 1。但是如 CopyOnWriteArrayList 并不會(huì)使用 modCount 計(jì)數(shù)。
所以 CopyOnWriteArrayList 使用 foreach 刪除是安全的，但是還是建議使用如下兩種刪除元素，統(tǒng)一操作。
修復(fù)的辦法有兩種：
使用 Iterator#remove 刪除元素
JDK1.8 List#removeIf
推薦使用 JDK1.8 這種方式，簡(jiǎn)潔明了。
思考
如果我將上面 foreach 代碼判斷條件簡(jiǎn)單修改一下：
運(yùn)行這段代碼，可以發(fā)現(xiàn)這段代碼又不會(huì)報(bào)錯(cuò)了，有沒有很意外？
感興趣的同學(xué)可以自行研究源碼
這道Java基礎(chǔ)題真的有坑！我求求你，認(rèn)真思考后再回答這道Java基礎(chǔ)題真的有坑！我也沒想到還有續(xù)集。
總結(jié)
第一?我們不要先入為主，想當(dāng)然就認(rèn)為 Arrays.asList 和 List.subList 就是一個(gè)普通，獨(dú)立的 ArrayList。
如果沒辦法，使用了 Arrays.asList 和 List.subList ，返回給其他方法的時(shí)候，一定要記得再套娃一層真正的 java.util.ArrayList。
第二 JDK 的提供的不可變集合實(shí)際非常笨重，并且低效，還不安全，所以推薦使用 Guava 不可變集合代替。
最后，切記，不要隨便在 foreach增加/刪除元素
喜歡這篇文章的朋友們點(diǎn)贊 評(píng)論支持一下小編哦，有需要Java相關(guān)資料的私信小編領(lǐng)取。
