一口氣帶你踩完五個 List 的大坑,真的是處處坑啊!

文章來源:https://mp.weixin.qq.com/s/pDYi3yvS7qCWswWs3g6skw


一口氣帶你踩完五個 List 的大坑,真的是處處坑啊!

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

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

本文設計知識點如下:

一口氣帶你踩完五個 List 的大坑,真的是處處坑啊!

List 踩坑大全

ArrayList 這是李逵,還是李鬼?

以前實習的時候,寫過這樣一段簡單代碼,通過 Arrays#asList 將數組轉化為 List 集合。

一口氣帶你踩完五個 List 的大坑,真的是處處坑啊!

這段代碼表面看起來沒有任何問題,編譯也能通過,但是真正測試運行的時候將會在第 4 行拋出 UnsupportedOperationException。

剛開始很不解,Arrays#asList 返回明明也是一個 ArrayList,為什麼添加一個元素就會報錯?這以後還能好好新增元素嗎?

一口氣帶你踩完五個 List 的大坑,真的是處處坑啊!

最後通過 Debug 才發現這個Arrays#asList 返回的 ArrayList 其實是個李鬼,僅僅只是 Arrays 一個內部類,並非真正的 java.util.ArrayList。

一口氣帶你踩完五個 List 的大坑,真的是處處坑啊!

通過 IDEA,生成這兩個的類圖,如下:

一口氣帶你踩完五個 List 的大坑,真的是處處坑啊!

從上圖我們發現,add/remove 等方法實際都來自 AbstractList,而java.util.Arrays$ArrayList 並沒有重寫父類的方法。而父類方法恰恰都會拋出UnsupportedOperationException。

一口氣帶你踩完五個 List 的大坑,真的是處處坑啊!

這就是為什麼這個李鬼 ArrayList 不支持的增刪的實際原因。


你用你的新 List,為什麼卻還互相影響

李鬼 ArrayList 除了不支持增刪操作這個坑以外,還存在另外一個大坑,改動內部元素將會同步影響原數組。

一口氣帶你踩完五個 List 的大坑,真的是處處坑啊!

輸出結果:

<code>arrays:[modify_1, modify_2, 3]
list:[modify_1, modify_2, 3]/<code>

從日誌輸出可以看到,不管我們是修改原數組,還是新 List 集合,兩者都會互相影響。

查看 java.util.Arrays$ArrayList 實現,我們可以發現底層實際使用了原始數組。

一口氣帶你踩完五個 List 的大坑,真的是處處坑啊!

知道了實際原因,修復的辦法也很簡單,套娃一層 ArrayList 唄!

<code>List<string> list = new ArrayList<>(Arrays.asList(arrays));/<string>/<code>

不過這麼寫感覺十分繁瑣,推薦使用 Guava Lists 提供的方法。

<code>List<string> list = Lists.newArrayList(arrays);/<string>/<code>

通過上面兩種方式,我們將新的 List 集合與原始數組解耦,不再互相影響,同時由於此時還是真正的 ArrayList,不用擔心 add/remove報錯了。

除了 Arrays#asList產生新集合與原始數組互相影響之外,JDK 另一個方法 List#subList生成新集合也會與原始 List 互相影響。

我們來看一個例子:

一口氣帶你踩完五個 List 的大坑,真的是處處坑啊!

日誌輸出結果:

<code>integerList:[10, 20, 3]
subList:[10, 20]/<code>

查看 List#subList 實現方式,可以發現這個 SubList 內部有一個 parent 字段保存保存最原始 List 。

一口氣帶你踩完五個 List 的大坑,真的是處處坑啊!

所有外部讀寫動作看起來是在操作 SubList ,實際上底層動作卻都發生在原始 List 中,比如 add 方法:

一口氣帶你踩完五個 List 的大坑,真的是處處坑啊!

另外由於 SubList 實際上還在引用原始 List,業務開發中,如果不注意,很可能產生 OOM問題。

以下例子來自於極客時間:Java業務開發常見錯誤100例

<code>private static List<list>> 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));
}

}/<integer>/<list>/<code>

data 看起來最終保存的只是 1000 個具有 1 個元素的 List,不會佔用很大空間。但是程序很快就會 OOM

OOM 的原因正是因為每個 SubList 都強引用個一個 10 萬個元素的原始 List,導致 GC 無法回收。

這裡修復的辦法也很簡單,跟上面一樣,也來個套娃唄,加一層 ArrayList 。

一口氣帶你踩完五個 List 的大坑,真的是處處坑啊!

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

為了防止 List 集合被誤操作,我們可以使用 Collections#unmodifiableList 生成一個不可變(immutable)集合,進行防禦性編程。

這個不可變集合只能被讀取,不能做任何修改,包括增加,刪除,修改,從而保護不可變集合的安全。

一口氣帶你踩完五個 List 的大坑,真的是處處坑啊!

上面最後三行寫操作都將會拋出 UnsupportedOperationException 異常

但是你以為這樣就安全了嗎?

一口氣帶你踩完五個 List 的大坑,真的是處處坑啊!

如果有誰不小心改動原始 List,你就會發現這個不可變集合,竟然就變了。。。

一口氣帶你踩完五個 List 的大坑,真的是處處坑啊!

上面單元測試結果將會全部通過,這就代表 Collections#unmodifiableList 產生不可變集合將會被原始 List 所影響。

查看 Collections#unmodifiableList 底層實現方法:

一口氣帶你踩完五個 List 的大坑,真的是處處坑啊!

可以看到這跟上面 SubList 其實是同一個問題,新集合底層實際使用了原始 List

由於不可變集合所有修改操作都會報錯,所以不可變集合不會產生任何改動,所以並不影響的原始集合。但是防過來,卻不行,原始 List 隨時都有可能被改動,從而影響不可變集合。

可以使用如下兩種方式防止上賣弄的情況。

使用 JDK9 List#of 方法。

<code>List<string> list = new ArrayList<>(Arrays.asList("one", "two", "three"));
List<string> unmodifiableList = List.of(list.toArray(new String[]{}));/<string>/<string>/<code>

使用 Guava immutable list

<code>List<string> list = new ArrayList<>(Arrays.asList("one", "two", "three"));
List<string> unmodifiableList = ImmutableList.copyOf(list);/<string>/<string>/<code>

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


foreach 增加/刪除元素大坑

先來看一段代碼:

<code>String[] arrays = {"1", "2", "3"};
List<string> list = new ArrayList<>(Arrays.asList(arrays));
for (String str : list) {
if (str.equals("1")) {
list.remove(str);
}
}/<string>/<code>

上面的代碼我們使用 foreach 方式遍歷 List 集合,如果符合條件,將會從集合中刪除改元素。

這個程序編譯正常,但是運行時,程序將會發生異常,日誌如下:

<code>java.util.ConcurrentModificationException
\tat java.base/java.util.ArrayList$Itr.checkForComodification(ArrayList.java:939)
\tat java.base/java.util.ArrayList$Itr.next(ArrayList.java:893)/<code>

可以看到程序最終錯誤是由 ArrayList$Itr.next 處的代碼拋出,但是代碼中我們並沒有調用該方法,為什麼會這樣?

實際是因為 foreach 這種方式實際上 Java 給我們提供的一種語法糖,編譯之後將會變為另一種方式。

我們將上面的代碼產生 class 文件反編來看下最後代碼長的啥樣。

一口氣帶你踩完五個 List 的大坑,真的是處處坑啊!

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

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

一口氣帶你踩完五個 List 的大坑,真的是處處坑啊!

expectedModCount 來源於 list#iterator 方法:

一口氣帶你踩完五個 List 的大坑,真的是處處坑啊!

也就是說剛開始遍歷循環的時候 expectedModCount==modCount,下面我們來看下modCount。

modCount 來源於 ArrayList 的父類 AbstractList,可以用來記錄 List 集合被修改的次數。

一口氣帶你踩完五個 List 的大坑,真的是處處坑啊!

ArrayList#remove 之後將會使 modCount 加一,expectedModCount與 modCount 將會不相等,這就導致迭代器遍歷時將會拋錯。

一口氣帶你踩完五個 List 的大坑,真的是處處坑啊!

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

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

修復的辦法有兩種:

使用 Iterator#remove 刪除元素

一口氣帶你踩完五個 List 的大坑,真的是處處坑啊!

iterator

JDK1.8 List#removeIf

一口氣帶你踩完五個 List 的大坑,真的是處處坑啊!

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

思考

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

一口氣帶你踩完五個 List 的大坑,真的是處處坑啊!

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


總結

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

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

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

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

對了,在這裡說一下,我目前是在職Java開發,如果你現在正在學習Java,瞭解Java,渴望成為一名合格的Java開發工程師,在入門學習Java的過程當中缺乏基礎入門的視頻教程,可以關注並私信我:01。獲取。我這裡有最新的Java基礎全套視頻教程。


分享到:


相關文章: