集合框架入门进阶结业总结_从API调用者向底层设计者的思维转变-java教程-PHP中文网

ArrayList的remove(int)删索引、remove(Object)删值，易误用；遍历时删元素须用Iterator.remove()或removeIf()；HashMap容量应按n/0.75向上取2的幂；AbstractList中未重写方法抛UnsupportedOperationException。

集合框架入门进阶结业总结_从api调用者向底层设计者的思维转变

为什么 `ArrayList` 的 `remove(int)` 和 `remove(Object)` 容易误用

因为两个重载方法行为完全不同，但编译器不会报错，运行时才暴露问题。比如你本想删值 3，却写了 list.remove(3)——它删的是索引为 3 的元素，不是值为 3 的元素。

常见错误现象：IndexOutOfBoundsException（删越界索引），或删错元素（本想删第一个 "abc"，结果删了第 4 个位置的任意对象）。

查文档确认：整数参数走的是 remove(int index)；非 null 引用参数走的是 remove(Object o)
如果目标是按值删除，确保传入的是包装类型或引用对象，例如 list.remove(Integer.valueOf(3))，而不是裸写 3
在泛型为 Integer 的列表里，remove(3) 仍会被解析为删索引——JVM 优先匹配基本类型参数的重载

迭代中修改集合时，`ConcurrentModificationException` 怎么绕开又不踩坑

这不是线程安全问题，而是 fail-fast 机制在单线程下也会触发。只要用 for-each 或显式 Iterator 遍历，同时调用集合自身的 add()/remove()，就炸。

使用场景：过滤列表、批量清理满足条件的元素。

正确做法：用 Iterator.remove()，它是唯一被允许的“边遍历边删”方式
别用 list.remove() 配合 for-each，也别以为转成数组再操作就能躲过——ArrayList 的 iterator() 持有 modCount 快照，一动就校验
Java 8+ 可用 removeIf(Predicate)，它内部封装了安全的迭代逻辑，语义清晰且高效

`HashMap` 初始化容量设多少才不浪费内存又不频繁扩容

默认初始容量是 16，负载因子 0.75，意味着放 12 个键值对就触发第一次扩容。但扩容要 rehash，代价不小；而盲目设大容量，又浪费空间——尤其当 key 是大对象时。

蚂蚁百宝箱Tbox

蚂蚁百宝箱Tbox是一款AI文本写作工具，让AI应用的创作像呼吸一样简单。

下载

性能影响：小容量高频扩容 → CPU 时间涨；大容量低填充率 → 堆内存虚高，GC 压力隐性上升。

估算元素数量 n 后，按公式 capacity = (int) Math.ceil(n / 0.75) 向上取最近的 2 的幂（如 n=20 → Math.ceil(20/0.75)=27 → 实际设 32）
别直接写 new HashMap(100)：构造函数传的不是容量而是“阈值”，HashMap 会把它向上规整为 128（因为内部用 table.length * loadFactor 算扩容点）
如果 key 是字符串且长度固定、散列质量差（比如都以相同前缀开头），即使容量够，也可能因哈希碰撞多导致链表变长，此时得考虑自定义 hashCode() 或换 LinkedHashMap 观察访问模式

从 `Collection` 接口使用者，突然要看 `AbstractList` 源码，该盯哪几行

不是为了背代码，而是理解“为什么 subList() 返回的对象修改会影响原列表”“为什么 Arrays.asList() 返回的 list 不支持 add()”。这些行为差异，全藏在抽象基类对模板方法的实现里。

容易被忽略的地方：很多“不可变”或“视图”行为，不是靠 final 修饰，而是靠抛 UnsupportedOperationException 实现的——它根本没被重写，只是留空或直接 throw。

重点看 AbstractList.set()、add()、remove() 这几个方法体：它们多数直接 throw，说明子类必须重写才能支持对应操作
SubList 类里找 parent 字段和 offset 字段：它没拷贝数据，所有读写最终都委托给原始 ArrayList，所以是强一致性视图
Arrays$ArrayList（即 Arrays.asList() 返回类型）继承自 AbstractList，但没重写 add()，所以一调就崩——这不是 bug，是设计选择