因此，当涉及到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
摘抄笔记)
