java集合框架核心目标是提供可互换、行为明确的接口与实现，解决对象组的存储、检索、遍历、排序及线程安全切换；不为统一写法而生，而是基于语义差异（collection表元素组，map表映射）、性能契约（如arraylist.get()为o(1)）和运行时需求（动态扩容、类型擦除）设计。
Java集合框架（Java Collections Framework, JCF）不是为“统一容器写法”而生的，它的核心目标是：用一套可互换、有明确定义行为的接口和实现，解决运行时对象组的存储、检索、遍历、排序、线程安全切换等高频但易出错的操作。
为什么不用数组？——类型擦除与动态扩容的刚性需求
数组在编译期绑定类型且长度固定，而业务中常需：
- 存入不同子类实例（如
List<animal></animal>里加Dog和Cat），靠泛型 + 接口抽象避免重复类型检查 - 元素数量不确定（如读取文件行、HTTP响应列表），
ArrayList内部用Object[]+grow()自动扩容，比手动new数组更安全 - 需要快速按值查找（
HashSet的hashCode()/equals()协议）或按插入顺序迭代（LinkedHashMap），这些行为无法靠数组原语表达
Collection 和 Map 为何不合并？——数据关系建模的本质差异
这是设计上最常被误解的一点：Collection 表达“一组独立元素”，Map 表达“键值对映射关系”。二者语义不可互化：
- 把
Map<string user></string>强转成Collection<user></user>会丢失所有 key 信息，无法反查 -
TreeSet要求元素可比较（Comparable或传Comparator），而TreeMap只对key做比较，value完全无约束 - 并发场景下，
ConcurrentHashMap支持高并发putIfAbsent()，但没有对应的线程安全Collection实现（Collections.synchronizedList()是粗粒度锁）
为什么提供那么多实现类？——性能契约比语法糖更重要
每种实现都明确承诺特定操作的时间复杂度，开发者据此选型，而非凭感觉：
立即学习“Java免费学习笔记（深入）”；
-
ArrayList.get(int)是 O(1)，但remove(int)是 O(n)；LinkedList.removeFirst()是 O(1)，但get(int)是 O(n) -
HashSet.contains(Object)平均 O(1)，依赖正确重写hashCode()；若全返回相同 hash 值，退化为 O(n) -
PriorityQueue不是排序队列，而是堆结构——peek()快，但遍历时不保证有序，要全排序得转Arrays.sort()
真正容易被忽略的，是「接口方法的默认实现」从 Java 8 开始大量出现（如 Collection.removeIf()、Map.computeIfAbsent()），它们让底层实现可以复用逻辑，但调用者必须清楚：这些默认方法内部仍可能触发 iterator() 遍历，对 ConcurrentModificationException 敏感，不能假设它们比手写循环更“底层”或“高效”。
