abstractcollection 提供基于 iterator() 和 size() 的默认实现，子类必须重写这两个方法；其余方法如 isempty()、contains() 等自动获得通用逻辑，不可变集合需在修改方法中抛 unsupportedoperationexception。
Collection 接口本身不提供具体实现，所有通用逻辑都由 AbstractCollection 抽象类承担；子类只需重写 size() 和 iterator() 两个核心方法，其余方法自动获得基于迭代器的默认行为。
AbstractCollection 提供的默认实现逻辑
AbstractCollection 是 Collection 的骨架实现类，它用统一方式实现大部分方法，全部依赖 iterator() 和 size() 这两个抽象方法。例如：
-
isEmpty() 直接返回
size() == 0； - contains(Object o) 遍历迭代器逐个比较（调用 equals）；
- remove(Object o) 遍历并调用迭代器的 remove()（若支持）；
- addAll(Collection c) 复用 add() 方法逐个添加；
- toArray() 先用 size() 预分配数组，再用 iterator() 填充。
这些实现不要求底层数据结构支持随机访问或索引操作，只依赖“可遍历”和“知道大小”两个前提。
子类必须重写的两个关键方法
任何继承 AbstractCollection 的具体集合类，都必须提供 size() 和 iterator() 的实现，否则无法实例化。这是强制契约：
Java JDK 25
下载
Java JDK 25 来自 OpenJDK 官方归档，版本为 JDK 25，本条下载地址已指向官方 Windows x64 zip 安装包直链，适合调试旧项目或兼容旧版 Java 运行环境。
- size() 应尽量高效 —— 理想情况是 O(1)，比如 ArrayList 维护了 elementCount 字段；链表类如 LinkedList 若缓存了 size 才能保证常数时间，否则需遍历计数（不推荐）；
- iterator() 必须返回一个实现了 Iterator 接口的对象，该对象需正确支持 hasNext()、next()，以及可选的 remove() —— 若集合不允许修改，remove() 应抛 UnsupportedOperationException。
建议重写以提升性能的方法
虽然不是强制，但以下方法若存在更优实现，应主动重写：
- contains(Object o)：若底层支持哈希（如 HashSet）或二分查找（如 TreeSet），就不该依赖线性遍历；
- remove(Object o)：直接定位删除比遍历查找快得多（如 HashMap 的 removeByKey）；
- clear()：若能批量释放资源（如置空数组、断开链表引用），比逐个调用 remove() 更高效；
- toArray(T[] a)：利用已知 size 预分配、避免扩容，还能复用传入数组，减少内存分配。
不可变集合与 UnsupportedOperationException
如果集合设计为不可变（如 Collections.unmodifiableXXX 返回的包装类），应在相应修改方法中明确抛出 UnsupportedOperationException：
- add、remove、addAll、removeAll、retainAll、clear 等均需覆盖并抛异常；
- iterator() 返回的 Iterator 若不支持 remove()，其 remove() 方法也应抛该异常；
- 不必重写只读方法（如 size、contains、isEmpty），直接复用 AbstractCollection 的默认实现即可。
这种设计既满足接口契约，又清晰表达了集合的语义约束。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
