因此，當涉及到Java Collections API時，我們傾向于認為已經了解了所有內容。 我們知道我們的身邊方式列表 ， 設置 ， 地圖 ， Iterables ， 迭代器 。 我們已經為Java 8的Collections API增強做好了準備。

但是隨后，我們偶爾會偶然發現其中一個奇怪的怪癖，這些怪癖源于JDK的深度及其向后兼容的悠久歷史。 讓我們看看無法修改的集合

不可修改的收藏

Collections API不會反映集合是否可修改。 那里
不是不可變的List ， Set或Collection基類型，可變的子類型可以擴展。 因此，JDK中不存在以下API：

// Immutable part of the Collection API public interface Collection {boolean contains(Object o);boolean containsAll(Collection<?> c);boolean isEmpty();int size();Object[] toArray();<T> T[] toArray(T[] array); }// Mutable part of the Collection API public interface MutableCollection extends Collection {boolean add(E e);boolean addAll(Collection<? extends E> c);void clear();boolean remove(Object o);boolean removeAll(Collection<?> c);boolean retainAll(Collection<?> c); }

現在，可能有原因，為什么在Java早期就沒有以這種方式實現事情。 很有可能，可變性不被視為值得在類型層次結構中占據其自身類型的功能。 因此，出現了Collections幫助器類，其中包含有用的方法，例如unmodifiableList() ， unmodifiableSet() ， unmodifiableCollection()以及其他方法。 但是要當心使用不可修改的集合！ Javadoc中提到了一個非常奇怪的事情 ：返回的集合不會將hashCode和equals操作傳遞到后備集合，而是依賴于Object的equals和hashCode方法。 在后備集合是集合或列表的情況下，必須保留這些操作的合同。 “保留這些行動的合同”。 那很模糊。 它背后的原因是什么？ 這個堆棧溢出答案給出了一個很好的解釋：

UnmodifiableList是UnmodifiableCollection，但相反情況并非如此-包裹列表的UnmodifiableCollection不是UnmodifiableList。 因此，如果將包裝List a的UnmodifiableCollection與包裝相同List a的UnmodifiableList進行比較，則兩個包裝器不應相等。 如果只是傳遞給包裝列表，它們將是相等的。 盡管這種推理是正確的，但其含義可能是出乎意料的。

底線

最重要的是，您不能依賴Collection.equals() 。 雖然List.equals()和Set.equals()定義明確，但不要信任Collection.equals() 。 它的行為可能沒有意義。 當在方法簽名中接受Collection時，請記住這一點：

public class MyClass {public void doStuff(Collection<?> collection) {// Don't rely on collection.equals() here!} }

參考：在Java，SQL和JOOQ博客上，我們的JCG合作伙伴 Lukas Eder提出的Java Collections API怪癖 。

翻譯自: https://www.javacodegeeks.com/2013/03/java-collections-api-quirks.html

總結

以上是生活随笔為你收集整理的Java Collections API怪癖的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。