Java集合框架概述与Collection继承结构解析

Collection接口只约束List、Set、Queue三大单列集合分支，不包括Map系列；它是接口不能实例化，所有实现类方法语义一致但时间复杂度差异显著。

Java集合框架里Collection接口到底管哪些类

Collection 是 Java 集合体系的顶层接口之一，但它**不包括 Map 系列**（比如 HashMap、TreeMap），这点很多人一上来就混淆。它只约束“单列集合”——也就是每个元素独立存在、不以键值对形式组织的容器。

真正继承自 Collection 的是三大分支：List、Set、Queue。它们各自再往下延伸出具体实现类，比如：

• ArrayList、LinkedList 实现 List
• HashSet、TreeSet 实现 Set
• PriorityQueue、ArrayDeque 实现 Queue

注意：Stack 虽然历史久，但它是 Vector 的子类，而 Vector 实现了 List，所以它也间接属于 Collection 体系——不过现在基本被 Deque 替代了。

为什么不能直接 new Collection<String>()

因为 Collection 是接口，不是类，JVM 不允许实例化接口。常见错误是写成：

Collection<String> coll = new Collection<String>(); // 编译报错：Cannot instantiate the type Collection<String>

必须用它的某个实现类来构造对象：

• 要允许重复 + 有序 → 选 ArrayList 或 LinkedList
• 要自动去重 + 无序 → 用 HashSet
• 要自动去重 + 按自然顺序或自定义排序 → 用 TreeSet
• 要先进先出队列行为 → 优先考虑 ArrayDeque（比 LinkedList 更快）

别图省事写个 new ArrayList() 而不加泛型——这会导致编译期类型检查失效，运行时可能抛 ClassCastException。

Collection 接口方法在不同实现类中行为差异大不大

大部分方法语义一致，但关键几个操作的**时间复杂度和是否支持**差别明显：

• add(E e)：所有实现都支持，但 HashSet 是 O(1) 平均，ArrayList 是 O(1) 均摊（扩容时 O(n)）
• remove(Object o)：ArrayList 是 O(n)，因为要遍历找元素；HashSet 是 O(1) 平均；LinkedList 也是 O(n)，且没有随机访问优化
• contains(Object o)：同上，HashSet 快，ArrayList 慢
• iterator() 返回的迭代器是否支持 remove()？ArrayList 和 HashSet 支持；但某些只读包装类（如 Collections.unmodifiableList() 包装后的）调用会抛 UnsupportedOperationException

别假设“用了 Collection 接口就等于性能透明”——底层实现决定一切。选错实现类，一个 contains() 就能把 O(1) 变成 O(n²) 循环里反复调用。

Collection 继承树里容易被忽略的“断层”点

最常被跳过的其实是 Iterable 接口。从 JDK 1.5 开始，Collection 扩展自 Iterable，所以所有集合都能用 for-each 循环。但反过来，**不是所有实现了 Iterable 的类都是 Collection 子类**——比如 Scanner、自定义的流式数据源，它们能 for-each，但不支持 size()、isEmpty() 这些 Collection 方法。

另一个坑是 Arrays.asList() 返回的对象：它确实是 List 子类型，也实现了 Collection，但它是固定大小的——调用 add() 或 remove() 会直接抛 UnsupportedOperationException。真要改，得包一层 new ArrayList<>(...)。

继承关系看着线性，实际用的时候，每个节点都卡着具体行为边界。光看 UML 图没用，得盯住 Javadoc 里每个方法的 “Throws” 和 “Specified by” 栏。