Java集合框架是接口与实现类组成的体系，核心解决对象容器统一管理问题；Collection（List/Set/Queue）与Map为两条独立主线，泛型擦除、迭代器失效和数据结构约束是关键难点。
Java集合框架不是一套“工具包”，而是一套接口与实现类组成的、有明确继承和实现关系的体系。它解决的核心问题是：统一管理对象容器的行为，同时让不同数据结构（如数组、链表、哈希表、树）能以一致的方式被使用。
Collection 和 Map 是两条完全独立的主线
Collection 接口是所有单列集合（List、Set、Queue）的根接口，定义了 add()、remove()、contains() 等通用操作；Map 接口则是双列集合（HashMap、TreeMap、LinkedHashMap）的根接口，不继承 Collection，也没有 add() 方法——它的基本操作是 put() 和 get()。
常见误解是把 Map 当作 Collection 的子类，实际上二者在顶层就分道扬镳。想遍历 Map 中的键值对，得用 entrySet() 转成 Set 才能接入 Collection 体系。
List、Set、Queue 各自的不可替代性
三者都继承 Collection，但语义和约束完全不同：
立即学习“Java免费学习笔记（深入）”；
-
List：有序、可重复、支持下标访问（get(int index)）。典型实现ArrayList（数组-backed，随机访问快）、LinkedList（链表-backed，频繁增删首尾快） -
Set：无序（HashSet）、不可重复、不保证插入顺序；LinkedHashSet保留插入顺序；TreeSet按自然序或比较器排序 -
Queue：专为“队列行为”设计，核心方法是offer()（入队）、poll()（出队）、peek()（查看队首）。PriorityQueue不是先进先出，而是按优先级出队
选错类型会导致逻辑错误：比如用 HashSet 存订单记录却依赖插入顺序，或用 ArrayList 做高并发下的任务队列（缺乏线程安全）。
泛型擦除带来的运行时陷阱
Java 集合在编译后全部丢失泛型信息，即所谓“类型擦除”。这意味着：
-
ArrayList和ArrayList在运行时都是ArrayList，JVM 不知道它们的区别 -
instanceof无法判断泛型类型：list instanceof ArrayList是编译错误 - 反射获取泛型实际类型需通过
Field.getGenericType()或Method.getGenericReturnType()，且仅对声明处的泛型有效
最常踩的坑是反序列化：用 ObjectInputStream 读出一个 ArrayList，你无法靠运行时类型确认它里面存的是 String 还是 User，必须靠上下文约定或额外元数据。
迭代器失效问题只发生在结构性修改时
调用 Iterator 的 next() 或 hasNext() 不会触发异常；但若在遍历过程中，用集合自身的方法（如 list.remove()）修改结构，下次调用 next() 就抛 ConcurrentModificationException。
正确做法只有两种：
- 用迭代器自己的
remove()方法（it.remove()），它会同步更新内部修改计数 - 收集待删元素，遍历结束后再批量删除（
list.removeAll(toRemove)）
注意：CopyOnWriteArrayList 是个例外，它允许遍历时修改，但代价是每次写都复制整个数组，只适合读多写极少场景。
真正难的不是记住类图，而是理解每种集合背后的数据结构约束、并发行为、以及泛型擦除对运行时能力的限制。很多 bug 出现在跨层使用时——比如把 HashMap 传给期望 Map 的方法，却在内部强转成 LinkedHashMap 去依赖顺序，这种耦合一旦换实现就崩。
