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 不允许实例化接口。常见错误是写成：
立即学习“Java免费学习笔记（深入）”；
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” 栏。
