1. 先看清楚ArrayList的定位大部分“方法用不对”的问题都出在选错集合上很多人学ArrayList上来就背方法列表add、get、remove、size……背完就觉得自己会了。但真正在业务代码里写一段时间之后你会发现ArrayList的方法本身并不难难的是在什么场景下选它、什么场景下别用它。选错了集合后面的方法用得再熟也是白搭。ArrayList本质上是一个动态数组。它的底层就是Object数组通过扩容机制实现“自动变长”。这也决定了它最核心的两条性能特征按下标访问元素是O(1)也就是无论你有1万个元素还是100万个元素get(i)的速度几乎一样快。因为底层就是数组拿下标直接算内存地址。在中间插入或删除元素是O(n)因为要移动后面的所有元素。元素越多这个操作的代价越大。这两条特性直接推导出ArrayList的适用场景读多写少、按索引访问多、只在尾部追加数据。比如缓存配置列表、菜单树平铺结果、批量导入的临时数据容器这些都是ArrayList的标准使用场景。那什么时候不要硬用ArrayList我见过不少新手在“需要频繁在头部插入”的时候仍然用ArrayList然后发现数据量一大就卡得不行。这种场景应该用LinkedList因为它的头插是O(1)。还有一个常见的误区ArrayList和LinkedList之争其实没那么重要大多数业务场景下两者差异根本感知不到。真正需要想清楚的是——你到底要不要用List这个接口如果你只需要“按顺序存一堆东西不关心去重和查找”ArrayList没问题。如果你需要“查找某个值是否存在”而且数据量很大那应该考虑HashSet。方法用得好不如容器选得对。另外补充一个容易被忽视的细节ArrayList的默认容量是10扩容时会按原容量的1.5倍增长。在很多次add之后底层数组会频繁发生复制操作。后面我会专门讲ensureCapacity怎么提前规避这个问题。2. 最常用的增删改查方法重点不是“怎么调”而是“返回了什么”这一节是所有ArrayList教程都会讲的但大部分教程只告诉你签名不告诉你调用之后的返回值是什么、什么时候会抛异常、底层到底发生了什么。这里我把日常开发中用得最多的几个方法逐个拆开讲。2.1 add你以为只是在加元素其实背后是一次扩容判断add(E e)是最基础的追加方法。它的返回值永远是true这是从Collection接口继承来的设计——统一了“添加成功与否”的表达方式。实际开发中几乎没有人在add的时候接收这个返回值但你要知道它不是void方便以后看源码或者写框架代码时理解为什么有人return list.add(x)。add(int index, E element)是指定位置插入。注意两个坑index必须在[0, size]之间index等于size表示尾部追加超出这个范围直接抛IndexOutOfBoundsException。这个操作会触发元素移动。比如一个容量10万的列表往头部插入一个元素底层要整体后移10万个引用。这就是之前说的O(n)。addAll(Collection? extends E c)批量追加。我强烈建议批量插入数据时用它而不是在循环里一次次调add。原因有两点一是代码可读性高二是底层会一次性算好需要的容量然后扩容循环add则可能触发多次扩容。2.2 get与set数组下标的好处和“别拿循环查值”的习惯get(int index)是这个集合最具优势的方法——随机访问速度极快。很多ORM框架在封装数据库查询结果时底层就是通过循环get把数据从ResultSet搬到List里的。set(int index, E element)是替换指定位置的元素返回值是被替换掉的旧元素。这个返回值在很多业务场景里很有用。比如实现一个“最近浏览”列表当同一个商品再次被点击时你想把它提到最前面就需要先把原来的位置清掉拿到旧值后做后续处理。要提醒一点get和set都需要下标不越界越界抛IndexOutOfBoundsException。工作中我见过不少这种翻车现场for (int i 0; i list.size(); i)用导致最后一次越界。这就是典型的“差一错误”off-by-one。另外不要用list.get(i)去循环查找某个值。比如有100万条数据你要找id等于10086的那条用for循环get就是O(n)每次get虽然快但架不住要循环100万次。这种场景应该转换成Map来按key查找。这是List作为容器最大的局限也是很多人从“会用”走向“会设计”必须迈过的一道坎。2.3 remove两个重载方法返回值一个是大坑remove是ArrayList里最容易写错的方法因为它有两个重载remove(int index)删除指定下标处的元素返回被删除的元素。remove(Object o)删除第一个匹配到的元素返回boolean。问题出在什么时候当你想删除一个“值为某个int数字”的元素时比如列表内容是[1, 2, 3]你想删掉数字2list.remove(2); // 你以为删的是“值为2的元素”实际上删的是下标2处的元素3 list.remove(Integer.valueOf(2)); // 这才是删掉“值为2的元素”这个坑在真实面试题里经常出现实战中也确实坑过人。某开发者在做配置项清理功能时写的是remove(id)这里的id恰好是int类型结果删掉的不是配置id为“20”的那条而是下标为20的那条。排查了半天才发现是这个重载搞的鬼。建议如果列表存的是Integer、Long这类包装类型删除指定值时一律手动装箱或者用removeIf后面会讲。还有一个需要知道的点remove(Object o)只删除第一个匹配项。如果列表里有两个相同的对象你想全部删掉不能只调一次。需要用循环、removeAll(Collections.singleton(o))或者removeIf(x - x.equals(o))。2.4 clear与isEmpty别再用size() 0了一个细节提升代码可读性clear()清空所有元素。很多人以为它就是把size设为0实际上它的实现是遍历数组把所有位置置为null然后size改为0。这样做是为了让底层数组里的对象可以被垃圾回收防止发生“内存泄漏”——虽然List本身还在但元素已经不在业务意义上存在了。isEmpty()判断是否为空。我在代码评审时见过很多list.size() 0的写法功能没问题但语义不如isEmpty()清晰。isEmpty()在时间复杂度和size() 0完全一致都是O(1)因为size在ArrayList里就是一个实时维护的字段。3. 查找和判断类方法equals是灵魂别只盯着contains和indexOf查找类方法在日常开发中出现的频率非常高。但它们的正确性完全依赖一个前提元素正确实现了equals方法。这节把这些方法讲透。3.1 contains与indexOf时间复杂度的判断别等数据量大了才后悔contains(Object o)判断列表里是否包含指定元素indexOf(Object o)返回第一个匹配位置lastIndexOf(Object o)返回最后一个匹配位置。这三个方法的底层实现都一样——遍历逐个调equals比较时间复杂度O(n)。所以如果你有一个10万条数据的列表要频繁做contains判断性能会非常难看。我之前在某后台管理系统里处理一批订单状态变化时一开始直接用了contains做去重数据量上万后接口响应从几十毫秒变成了几百毫秒后来改成HashSet这个问题直接消失。那么contains好用吗好用数据量小的时候写起来很爽比如判断用户角色集合里有没有“admin”。但一定记住它的性能真相不要在大数据量场景里硬刚。另一个关键是equals。假如你把一个自定义对象放进ArrayList比如User不管User里有没有重写equalscontains都能运行——但结果可能完全不符合预期。不重写equals比较的是对象引用地址重写了equals比较的才是业务字段。比如两个User对象id都是1001name都是“张三”但不重写equalscontains会认为它们不是同一个对象。我建议所有放进集合的自定义对象都重写equals和hashCode这俩必须同时重写不然HashMap、HashSet那边也会出问题。3.2 equals方法ArrayList和ArrayList比较的隐藏逻辑list1.equals(list2)比较的是两个列表是否“顺序和元素都相等”。注意两个前提第一是顺序相同第二是对应位置的元素互相equals。[1, 2, 3]和[3, 2, 1]用equals比较是false。这个场景最常见的应用是单元测试。你用assertEquals(expectedList, actualList)时底层就是调List的equals。如果你的元素没重写equals测试结果会非常诡异——你以为两个列表内容一样测试就是不通过。所以排查“断言不通过”的时候先看一眼元素类有没有正确实现equals。containsAll(Collection? c)判断当前列表是否包含另一集合的所有元素。你要区分它和contains的区别contains是“一个元素在不在里面”containsAll是“一整套东西是不是都包含”。比如权限校验时判断用户权限集合里是否包含所有要求的权限点就很适合用containsAll。3.3 retainAll与removeAll集合运算的“直接用现成方法”套路这两个是批量操作返回boolean表示“调用后列表是否发生了变化”。removeAll(Collection? c)从列表里删除所有包含在c中的元素。相当于差集。retainAll(Collection? c)只保留那些在c中的元素其余全部删掉。相当于交集。举个例子你有两份名单一份是所有员工名单allEmployees一份是技术部名单techEmployees。要找出“非技术部员工”就直接allEmployees.removeAll(techEmployees)。要找出“同时出现在两份名单中的人”就用allEmployees.retainAll(techEmployees)。这种集合运算写法非常简洁但有一点要小心这些操作的底层都是双重循环级的实现数据量大时性能一般。在百万级数据上做removeAll耗时可能达到秒级。如果数据量大更合理的方式是用HashSet辅助比如new HashSet(allEmployees).removeAll(techEmployees)——因为HashSet的contains是O(1)整体复杂度会从O(n*m)降到O(n)。4. 遍历与删除最常见的运行时报错八成出在这一节这是ArrayList实战中事故率最高的区域。很多新手以为自己会遍历就会安全地“边遍历边删除”结果一运行就抛ConcurrentModificationException。更离谱的是有时候同一段代码在某种写法下不抛异常换个写法就抛异常了——这背后是有规律的。4.1 为什么边遍历边remove会抛ConcurrentModificationException先看这段代码ListString list new ArrayList(Arrays.asList(a, b, c, d)); for (String s : list) { if (b.equals(s)) { list.remove(s); } }运行起来十有八九抛ConcurrentModificationException。原因是增强for循环底层用的是IteratorIterator内部有一个modCount的期望值。ArrayList每次结构性修改add、remove、clear等都会让modCount加1。迭代器每次next()时会检查当前的modCount和它创建时的期望值是否一致不一致就认为“有另一个线程或另一段代码在修改列表”于是立刻抛异常这就是fail-fast机制。**为什么有时候不抛异常**比如删除的是倒数第二个元素循环刚好在检查之前结束了异常没来得及抛出。这种情况非常坑——你换一个数据就崩不换就不崩看起来像是“灵异事件”。4.2 安全删除的三种写法按场景选第一种使用Iterator的remove方法IteratorString it list.iterator(); while (it.hasNext()) { String s it.next(); if (b.equals(s)) { it.remove(); // 这是迭代器自己提供的删除方法会同步modCount } }这是官方推荐的写法。it.remove()会把期望值一并更新所以不会触发异常。第二种removeIf方法Java 8list.removeIf(s - b.equals(s));一行搞定底层也是迭代器但把这些细节封装好了。日常代码里最推荐这种写法。第三种倒序for循环for (int i list.size() - 1; i 0; i--) { if (b.equals(list.get(i))) { list.remove(i); } }倒序删除不会影响前面元素的下标所以不会出现“跳过元素”的问题。这种写法不需要迭代器适合你同时还要按下标做复杂判断的场景。这里要额外提醒一件事除了删除边遍历边add同样会抛ConcurrentModificationException。如果你要在遍历过程中“有条件地添加元素”不要用增强for要么用ListIterator的add方法要么先记录要添加的元素遍历结束后统一add。4.3 subList的坑你以为得到的是新列表其实是个“视图”subList(int fromIndex, int toIndex)返回[fromIndex, toIndex)区间内的子列表。很多人以为它像字符串的substring一样是复制了一份其实不是——subList返回的是原列表的视图对子列表的修改会直接影响原列表。ListString list new ArrayList(Arrays.asList(a, b, c, d, e)); ListString sub list.subList(1, 4); // b, c, d sub.remove(c); // 此时list也变成了 a, b, d, e这个特性有时候我们反而想利用它来“截断列表”。比如list.subList(0, 3).clear()可以删除前三个元素比循环remove更高效。但更大的坑在后面如果你在拿到subList之后修改了原列表的结构add/remove然后再去操作subList会抛ConcurrentModificationException。因为你手上的subList是基于原列表的modCount来做校验的。所以实际业务中如果你需要的是一个独立的子集最稳妥的做法是当场复制ListString sub new ArrayList(list.subList(1, 4));4.4 toArray的两个版本带参版本才能拿到指定类型数组toArray()无参版本返回Object[]toArray(T[] a)返回指定类型的数组。日常开发中几乎都用带参版本String[] arr list.toArray(new String[0]);写new String[0]看起来很奇怪但这是现代Java推荐的做法。JVM会根据列表大小自动创建一个恰好大小的数组性能上和传一个大数组相比没有明显差异。不过如果你的列表非常大Java 8之后官方建议可以传一个与size相同大小的数组来减少一次数组创建和复制——两个方向都可以不用过于纠结。重点是List转数组用带泛型参数的toArray不要用无参版本然后强转强转必抛ClassCastException。5. 高级但常用的方法sort、replaceAll、removeIf以及一个“只讲对一半”的面试题Java 8给Collection接口增加了一些默认方法这些方法在ArrayList身上非常好用也是很多教程容易一笔带过的地方。但实际上它们解决问题的效率非常高。5.1 sort与Comparator用Comparator.comparing一行完成排序sort(Comparator? super E c)是List接口的默认方法底层会调用Arrays.sort。排序规则由Comparator决定。自然排序写法list.sort(null)要求元素实现Comparable接口。指定字段排序list.sort(Comparator.comparing(User::getAge))。倒序list.sort(Comparator.comparing(User::getAge).reversed())。多条件排序list.sort(Comparator.comparing(User::getAge).thenComparing(User::getName))。很多人还停留在“用Collections.sort 匿名内部类”的老写法。功能上没问题但代码真的啰嗦。Lambda表达式配合Comparator的方法引用可读性提升不是一点半点。我代码评审时看到新代码还在写三行的匿名Comparator一般会顺手改成一行。排序还有一个容易犯的错误sort会直接修改原列表。如果你希望保留原来的顺序需要先复制一份再排序。如果不需要原列表了直接用sort即可不需要接收返回值——sort的返回类型就是void。5.2 replaceAll批量更新元素时比for循环set更优雅replaceAll(UnaryOperatorE operator)对列表中的每一个元素执行操作并用结果替换原来位置的元素。list.replaceAll(String::toUpperCase);如果要实现“把所有价格为0的商品价格改为默认的9.9元”products.replaceAll(p - p.getPrice() 0 ? p.withPrice(9.9) : p);对比一下用for循环加set的写法replaceAll的表达简洁得多而且不用管下标。值得注意的是如果操作抛异常replaceAll的执行行为是未定义的——可能只改了一半。所以不要在lambda里做可能抛异常的复杂逻辑。5.3 trimToSize和ensureCapacity两个与“扩容机制”有关的性能细节这两个方法特别实用但很少被提起。ensureCapacity(int minCapacity)在大量add之前提前扩容到指定容量避免扩容过程中反复的数组复制。ArrayList默认容量10如果最终要存50万个元素中间可能会触发很多次容量扩展每次扩展都要创建新数组并把旧数组内容整体System.arraycopy复制过去。而ArrayList的扩容倍率是1.5所以你提前ensureCapacity(600000)这种操作能省掉批量写入时大量数组复制的时间。trimToSize()把底层数组的容量精确调整到当前size大小释放无用空间。这个适合“一次性加载很多数据之后列表大小基本不变、内存吃紧”的场景。比如从Excel导入10万行数据到ArrayList处理完成后这个ArrayList大概率还占着15万甚至更大的容量调用trimToSize()可以把它缩到刚好10万。注意扩容到1.5倍意味着ArrayList一旦增长底层容量一定比size大。所以“ArrayList占的内存比它看起来多”是常态别惊讶。5.4 面试题“ArrayList和Vector的区别”为什么只会说对一半几乎每一份面试题里都有“ArrayList与Vector的区别”很多人能说出“ArrayList是线程不安全的Vector是线程安全的ArrayList性能更好”。这话没毛病但不完整。首先要明确Vector的线程安全是靠方法加synchronized实现的代价是每个方法调用都有同步开销。但它所谓的线程安全也只对“单个方法的原子性”有意义。比如if (!vector.contains(item)) { vector.add(item); }这段代码即使全用Vector在并发环境下依然会出问题因为contains和add是两次独立的操作。面对这种“先检查再操作”的组合逻辑你依然需要自己加锁。所以Vector的“线程安全”在大多数业务场景下都没你想象中好用。真正经验的完整回答应该包含两层并发场景下如果要保证“容器整体操作”的线程安全应该用Collections.synchronizedList(new ArrayList())或者直接上CopyOnWriteArrayList。CopyOnWriteArrayList的适用场景是“读多写极少”。它的add和remove操作会复制底层整个数组写代价很高但读操作完全无锁。比如订阅者列表、配置监听器列表就很适合用CopyOnWriteArrayList。6. 关于Arrays.asList的连环坑一个看起来是ArrayList、实际不是ArrayList的对象这一段放在最后是因为它的隐蔽性实在太高了。很多新手甚至工作两三年的开发者都在Arrays.asList上栽过跟头。Arrays.asList(a, b, c)返回的对象确实实现了List接口但不是java.util.ArrayList而是Arrays类内部的一个私有静态类。它有两个致命限制不能add和remove调用会抛UnsupportedOperationException。原因很简单——内部类没有实现“结构性修改”的能力它的底层数组是固定大小的。它与原数组共享数据。如果这个数组后续被改asList返回的列表也会变。所以Arrays.asList适合用来“创建一个固定大小的列表视图片段”比如初始化常量集合、作为测试数据源。一旦你需要“能增删的独立ArrayList”必须重新包一层ListString list new ArrayList(Arrays.asList(a, b, c));另一个常见坑是基本类型数组的问题Arrays.asList(1, 2, 3)在Java里看起来正常但如果你写int[] arr {1, 2, 3}; Arrays.asList(arr)得到的List长度是1里面放的是整个int[]。因为基本类型数组无法直接转换为泛型数组asList把arr当成了一个元素。解决办法是用Integer[]而不是int[]或者用Java 8的Stream来处理。7. 面试高频追问ArrayList源码级的细节复盘既然标题是“ArrayList常用方法”最后再补一层——有些细节面试常问而且直接关系到你是否真的理解这些常用方法。7.1 扩容的具体过程是什么样的初始DEFAULT_CAPACITY 10。第一次add时如果底层数组还是空的初始状态会直接分配容量10的数组。之后每次add如果发现size 1 elementData.length就执行扩容旧容量记为oldCapacity新容量 oldCapacity (oldCapacity 1)也就是1.5倍。用Arrays.copyOf把旧元素复制到新数组。新容量如果还不够就取实际需要的值比如addAll一整个大集合时会直接扩容到刚好容纳。如果容量超过了MAX_ARRAY_SIZE会走大数组分支。理解这个流程你就明白为什么“大量追加前用ensureCapacity”有意义。核心就是减少复制次数。7.2 modCount到底为什么存在modCount是AbstractList里一个受保护的字段记录“结构性修改次数”。所有迭代器包括增强for循环背后的Iterator在创建时会记录当时的modCount每次迭代校验当前modCount和记录值是否一致。不一致就抛ConcurrentModificationException。这个机制是fail-fast思想的体现——宁愿快速出错也不要在错误状态下继续运行产生不可预期的结果。7.3 为什么ArrayList的equals方法O(n)但很多人拿它做全列表比较因为List的equals实现就是遍历两个列表逐个元素比较。它是O(n)已经是这类“顺序敏感的比较”能达到的最优复杂度了。但要注意如果你的业务只需要“两个列表包含的元素集合相同不管顺序”那不该用equals应该先排序或者转成Set再比较。8. 我自己写业务代码时的习惯清单方法全部讲完了按我个人经验整理了一份ArrayList使用时的自检清单写代码时照着过一遍能省不少排查时间明确这个List是“读多”还是“写多”。写多且频繁在头部/中间插入考虑LinkedList读多ArrayList没问题。如果元素是自定义对象必须先确认equals和hashCode是否已重写。没重写contains、remove(Object)、indexOf、distinct去重都可能不符合预期。不要在增强for里直接remove或add。要么用Iterator要么用removeIf要么用倒序for。remove(int)和remove(Object)搞清楚参数类型。你存的是Integer删值就必须装箱。大批量add之前调用ensureCapacity用完不再变大的长列表可以trimToSize。需要子集且要独立操作时new ArrayList(list.subList(a, b))复制一份。用Arrays.asList创建出来的List本质不可变要能增删就new ArrayList包装一层。并发环境下不要裸用ArrayList。读多写少用CopyOnWriteArrayList读少写多或读写均衡就用Collections.synchronizedList或手动加锁。ArrayList本身不难难的是在具体场景里做对选择、避开源码层面的隐性坑。把这八个习惯内化之后再去用它的常用方法你会发现代码的稳定性和可读性完全是两个层次。最后再说一个小技巧写完之后多看一眼IDE的“代码提示”里方法签名——有的工具会把数组越界、类型不匹配等问题用弱警告提前标出来比自己硬找高效得多。
1. 先看清楚ArrayList的定位大部分“方法用不对”的问题都出在选错集合上很多人学ArrayList上来就背方法列表add、get、remove、size……背完就觉得自己会了。但真正在业务代码里写一段时间之后你会发现ArrayList的方法本身并不难难的是在什么场景下选它、什么场景下别用它。选错了集合后面的方法用得再熟也是白搭。ArrayList本质上是一个动态数组。它的底层就是Object数组通过扩容机制实现“自动变长”。这也决定了它最核心的两条性能特征按下标访问元素是O(1)也就是无论你有1万个元素还是100万个元素get(i)的速度几乎一样快。因为底层就是数组拿下标直接算内存地址。在中间插入或删除元素是O(n)因为要移动后面的所有元素。元素越多这个操作的代价越大。这两条特性直接推导出ArrayList的适用场景读多写少、按索引访问多、只在尾部追加数据。比如缓存配置列表、菜单树平铺结果、批量导入的临时数据容器这些都是ArrayList的标准使用场景。那什么时候不要硬用ArrayList我见过不少新手在“需要频繁在头部插入”的时候仍然用ArrayList然后发现数据量一大就卡得不行。这种场景应该用LinkedList因为它的头插是O(1)。还有一个常见的误区ArrayList和LinkedList之争其实没那么重要大多数业务场景下两者差异根本感知不到。真正需要想清楚的是——你到底要不要用List这个接口如果你只需要“按顺序存一堆东西不关心去重和查找”ArrayList没问题。如果你需要“查找某个值是否存在”而且数据量很大那应该考虑HashSet。方法用得好不如容器选得对。另外补充一个容易被忽视的细节ArrayList的默认容量是10扩容时会按原容量的1.5倍增长。在很多次add之后底层数组会频繁发生复制操作。后面我会专门讲ensureCapacity怎么提前规避这个问题。2. 最常用的增删改查方法重点不是“怎么调”而是“返回了什么”这一节是所有ArrayList教程都会讲的但大部分教程只告诉你签名不告诉你调用之后的返回值是什么、什么时候会抛异常、底层到底发生了什么。这里我把日常开发中用得最多的几个方法逐个拆开讲。2.1 add你以为只是在加元素其实背后是一次扩容判断add(E e)是最基础的追加方法。它的返回值永远是true这是从Collection接口继承来的设计——统一了“添加成功与否”的表达方式。实际开发中几乎没有人在add的时候接收这个返回值但你要知道它不是void方便以后看源码或者写框架代码时理解为什么有人return list.add(x)。add(int index, E element)是指定位置插入。注意两个坑index必须在[0, size]之间index等于size表示尾部追加超出这个范围直接抛IndexOutOfBoundsException。这个操作会触发元素移动。比如一个容量10万的列表往头部插入一个元素底层要整体后移10万个引用。这就是之前说的O(n)。addAll(Collection? extends E c)批量追加。我强烈建议批量插入数据时用它而不是在循环里一次次调add。原因有两点一是代码可读性高二是底层会一次性算好需要的容量然后扩容循环add则可能触发多次扩容。2.2 get与set数组下标的好处和“别拿循环查值”的习惯get(int index)是这个集合最具优势的方法——随机访问速度极快。很多ORM框架在封装数据库查询结果时底层就是通过循环get把数据从ResultSet搬到List里的。set(int index, E element)是替换指定位置的元素返回值是被替换掉的旧元素。这个返回值在很多业务场景里很有用。比如实现一个“最近浏览”列表当同一个商品再次被点击时你想把它提到最前面就需要先把原来的位置清掉拿到旧值后做后续处理。要提醒一点get和set都需要下标不越界越界抛IndexOutOfBoundsException。工作中我见过不少这种翻车现场for (int i 0; i list.size(); i)用导致最后一次越界。这就是典型的“差一错误”off-by-one。另外不要用list.get(i)去循环查找某个值。比如有100万条数据你要找id等于10086的那条用for循环get就是O(n)每次get虽然快但架不住要循环100万次。这种场景应该转换成Map来按key查找。这是List作为容器最大的局限也是很多人从“会用”走向“会设计”必须迈过的一道坎。2.3 remove两个重载方法返回值一个是大坑remove是ArrayList里最容易写错的方法因为它有两个重载remove(int index)删除指定下标处的元素返回被删除的元素。remove(Object o)删除第一个匹配到的元素返回boolean。问题出在什么时候当你想删除一个“值为某个int数字”的元素时比如列表内容是[1, 2, 3]你想删掉数字2list.remove(2); // 你以为删的是“值为2的元素”实际上删的是下标2处的元素3 list.remove(Integer.valueOf(2)); // 这才是删掉“值为2的元素”这个坑在真实面试题里经常出现实战中也确实坑过人。某开发者在做配置项清理功能时写的是remove(id)这里的id恰好是int类型结果删掉的不是配置id为“20”的那条而是下标为20的那条。排查了半天才发现是这个重载搞的鬼。建议如果列表存的是Integer、Long这类包装类型删除指定值时一律手动装箱或者用removeIf后面会讲。还有一个需要知道的点remove(Object o)只删除第一个匹配项。如果列表里有两个相同的对象你想全部删掉不能只调一次。需要用循环、removeAll(Collections.singleton(o))或者removeIf(x - x.equals(o))。2.4 clear与isEmpty别再用size() 0了一个细节提升代码可读性clear()清空所有元素。很多人以为它就是把size设为0实际上它的实现是遍历数组把所有位置置为null然后size改为0。这样做是为了让底层数组里的对象可以被垃圾回收防止发生“内存泄漏”——虽然List本身还在但元素已经不在业务意义上存在了。isEmpty()判断是否为空。我在代码评审时见过很多list.size() 0的写法功能没问题但语义不如isEmpty()清晰。isEmpty()在时间复杂度和size() 0完全一致都是O(1)因为size在ArrayList里就是一个实时维护的字段。3. 查找和判断类方法equals是灵魂别只盯着contains和indexOf查找类方法在日常开发中出现的频率非常高。但它们的正确性完全依赖一个前提元素正确实现了equals方法。这节把这些方法讲透。3.1 contains与indexOf时间复杂度的判断别等数据量大了才后悔contains(Object o)判断列表里是否包含指定元素indexOf(Object o)返回第一个匹配位置lastIndexOf(Object o)返回最后一个匹配位置。这三个方法的底层实现都一样——遍历逐个调equals比较时间复杂度O(n)。所以如果你有一个10万条数据的列表要频繁做contains判断性能会非常难看。我之前在某后台管理系统里处理一批订单状态变化时一开始直接用了contains做去重数据量上万后接口响应从几十毫秒变成了几百毫秒后来改成HashSet这个问题直接消失。那么contains好用吗好用数据量小的时候写起来很爽比如判断用户角色集合里有没有“admin”。但一定记住它的性能真相不要在大数据量场景里硬刚。另一个关键是equals。假如你把一个自定义对象放进ArrayList比如User不管User里有没有重写equalscontains都能运行——但结果可能完全不符合预期。不重写equals比较的是对象引用地址重写了equals比较的才是业务字段。比如两个User对象id都是1001name都是“张三”但不重写equalscontains会认为它们不是同一个对象。我建议所有放进集合的自定义对象都重写equals和hashCode这俩必须同时重写不然HashMap、HashSet那边也会出问题。3.2 equals方法ArrayList和ArrayList比较的隐藏逻辑list1.equals(list2)比较的是两个列表是否“顺序和元素都相等”。注意两个前提第一是顺序相同第二是对应位置的元素互相equals。[1, 2, 3]和[3, 2, 1]用equals比较是false。这个场景最常见的应用是单元测试。你用assertEquals(expectedList, actualList)时底层就是调List的equals。如果你的元素没重写equals测试结果会非常诡异——你以为两个列表内容一样测试就是不通过。所以排查“断言不通过”的时候先看一眼元素类有没有正确实现equals。containsAll(Collection? c)判断当前列表是否包含另一集合的所有元素。你要区分它和contains的区别contains是“一个元素在不在里面”containsAll是“一整套东西是不是都包含”。比如权限校验时判断用户权限集合里是否包含所有要求的权限点就很适合用containsAll。3.3 retainAll与removeAll集合运算的“直接用现成方法”套路这两个是批量操作返回boolean表示“调用后列表是否发生了变化”。removeAll(Collection? c)从列表里删除所有包含在c中的元素。相当于差集。retainAll(Collection? c)只保留那些在c中的元素其余全部删掉。相当于交集。举个例子你有两份名单一份是所有员工名单allEmployees一份是技术部名单techEmployees。要找出“非技术部员工”就直接allEmployees.removeAll(techEmployees)。要找出“同时出现在两份名单中的人”就用allEmployees.retainAll(techEmployees)。这种集合运算写法非常简洁但有一点要小心这些操作的底层都是双重循环级的实现数据量大时性能一般。在百万级数据上做removeAll耗时可能达到秒级。如果数据量大更合理的方式是用HashSet辅助比如new HashSet(allEmployees).removeAll(techEmployees)——因为HashSet的contains是O(1)整体复杂度会从O(n*m)降到O(n)。4. 遍历与删除最常见的运行时报错八成出在这一节这是ArrayList实战中事故率最高的区域。很多新手以为自己会遍历就会安全地“边遍历边删除”结果一运行就抛ConcurrentModificationException。更离谱的是有时候同一段代码在某种写法下不抛异常换个写法就抛异常了——这背后是有规律的。4.1 为什么边遍历边remove会抛ConcurrentModificationException先看这段代码ListString list new ArrayList(Arrays.asList(a, b, c, d)); for (String s : list) { if (b.equals(s)) { list.remove(s); } }运行起来十有八九抛ConcurrentModificationException。原因是增强for循环底层用的是IteratorIterator内部有一个modCount的期望值。ArrayList每次结构性修改add、remove、clear等都会让modCount加1。迭代器每次next()时会检查当前的modCount和它创建时的期望值是否一致不一致就认为“有另一个线程或另一段代码在修改列表”于是立刻抛异常这就是fail-fast机制。**为什么有时候不抛异常**比如删除的是倒数第二个元素循环刚好在检查之前结束了异常没来得及抛出。这种情况非常坑——你换一个数据就崩不换就不崩看起来像是“灵异事件”。4.2 安全删除的三种写法按场景选第一种使用Iterator的remove方法IteratorString it list.iterator(); while (it.hasNext()) { String s it.next(); if (b.equals(s)) { it.remove(); // 这是迭代器自己提供的删除方法会同步modCount } }这是官方推荐的写法。it.remove()会把期望值一并更新所以不会触发异常。第二种removeIf方法Java 8list.removeIf(s - b.equals(s));一行搞定底层也是迭代器但把这些细节封装好了。日常代码里最推荐这种写法。第三种倒序for循环for (int i list.size() - 1; i 0; i--) { if (b.equals(list.get(i))) { list.remove(i); } }倒序删除不会影响前面元素的下标所以不会出现“跳过元素”的问题。这种写法不需要迭代器适合你同时还要按下标做复杂判断的场景。这里要额外提醒一件事除了删除边遍历边add同样会抛ConcurrentModificationException。如果你要在遍历过程中“有条件地添加元素”不要用增强for要么用ListIterator的add方法要么先记录要添加的元素遍历结束后统一add。4.3 subList的坑你以为得到的是新列表其实是个“视图”subList(int fromIndex, int toIndex)返回[fromIndex, toIndex)区间内的子列表。很多人以为它像字符串的substring一样是复制了一份其实不是——subList返回的是原列表的视图对子列表的修改会直接影响原列表。ListString list new ArrayList(Arrays.asList(a, b, c, d, e)); ListString sub list.subList(1, 4); // b, c, d sub.remove(c); // 此时list也变成了 a, b, d, e这个特性有时候我们反而想利用它来“截断列表”。比如list.subList(0, 3).clear()可以删除前三个元素比循环remove更高效。但更大的坑在后面如果你在拿到subList之后修改了原列表的结构add/remove然后再去操作subList会抛ConcurrentModificationException。因为你手上的subList是基于原列表的modCount来做校验的。所以实际业务中如果你需要的是一个独立的子集最稳妥的做法是当场复制ListString sub new ArrayList(list.subList(1, 4));4.4 toArray的两个版本带参版本才能拿到指定类型数组toArray()无参版本返回Object[]toArray(T[] a)返回指定类型的数组。日常开发中几乎都用带参版本String[] arr list.toArray(new String[0]);写new String[0]看起来很奇怪但这是现代Java推荐的做法。JVM会根据列表大小自动创建一个恰好大小的数组性能上和传一个大数组相比没有明显差异。不过如果你的列表非常大Java 8之后官方建议可以传一个与size相同大小的数组来减少一次数组创建和复制——两个方向都可以不用过于纠结。重点是List转数组用带泛型参数的toArray不要用无参版本然后强转强转必抛ClassCastException。5. 高级但常用的方法sort、replaceAll、removeIf以及一个“只讲对一半”的面试题Java 8给Collection接口增加了一些默认方法这些方法在ArrayList身上非常好用也是很多教程容易一笔带过的地方。但实际上它们解决问题的效率非常高。5.1 sort与Comparator用Comparator.comparing一行完成排序sort(Comparator? super E c)是List接口的默认方法底层会调用Arrays.sort。排序规则由Comparator决定。自然排序写法list.sort(null)要求元素实现Comparable接口。指定字段排序list.sort(Comparator.comparing(User::getAge))。倒序list.sort(Comparator.comparing(User::getAge).reversed())。多条件排序list.sort(Comparator.comparing(User::getAge).thenComparing(User::getName))。很多人还停留在“用Collections.sort 匿名内部类”的老写法。功能上没问题但代码真的啰嗦。Lambda表达式配合Comparator的方法引用可读性提升不是一点半点。我代码评审时看到新代码还在写三行的匿名Comparator一般会顺手改成一行。排序还有一个容易犯的错误sort会直接修改原列表。如果你希望保留原来的顺序需要先复制一份再排序。如果不需要原列表了直接用sort即可不需要接收返回值——sort的返回类型就是void。5.2 replaceAll批量更新元素时比for循环set更优雅replaceAll(UnaryOperatorE operator)对列表中的每一个元素执行操作并用结果替换原来位置的元素。list.replaceAll(String::toUpperCase);如果要实现“把所有价格为0的商品价格改为默认的9.9元”products.replaceAll(p - p.getPrice() 0 ? p.withPrice(9.9) : p);对比一下用for循环加set的写法replaceAll的表达简洁得多而且不用管下标。值得注意的是如果操作抛异常replaceAll的执行行为是未定义的——可能只改了一半。所以不要在lambda里做可能抛异常的复杂逻辑。5.3 trimToSize和ensureCapacity两个与“扩容机制”有关的性能细节这两个方法特别实用但很少被提起。ensureCapacity(int minCapacity)在大量add之前提前扩容到指定容量避免扩容过程中反复的数组复制。ArrayList默认容量10如果最终要存50万个元素中间可能会触发很多次容量扩展每次扩展都要创建新数组并把旧数组内容整体System.arraycopy复制过去。而ArrayList的扩容倍率是1.5所以你提前ensureCapacity(600000)这种操作能省掉批量写入时大量数组复制的时间。trimToSize()把底层数组的容量精确调整到当前size大小释放无用空间。这个适合“一次性加载很多数据之后列表大小基本不变、内存吃紧”的场景。比如从Excel导入10万行数据到ArrayList处理完成后这个ArrayList大概率还占着15万甚至更大的容量调用trimToSize()可以把它缩到刚好10万。注意扩容到1.5倍意味着ArrayList一旦增长底层容量一定比size大。所以“ArrayList占的内存比它看起来多”是常态别惊讶。5.4 面试题“ArrayList和Vector的区别”为什么只会说对一半几乎每一份面试题里都有“ArrayList与Vector的区别”很多人能说出“ArrayList是线程不安全的Vector是线程安全的ArrayList性能更好”。这话没毛病但不完整。首先要明确Vector的线程安全是靠方法加synchronized实现的代价是每个方法调用都有同步开销。但它所谓的线程安全也只对“单个方法的原子性”有意义。比如if (!vector.contains(item)) { vector.add(item); }这段代码即使全用Vector在并发环境下依然会出问题因为contains和add是两次独立的操作。面对这种“先检查再操作”的组合逻辑你依然需要自己加锁。所以Vector的“线程安全”在大多数业务场景下都没你想象中好用。真正经验的完整回答应该包含两层并发场景下如果要保证“容器整体操作”的线程安全应该用Collections.synchronizedList(new ArrayList())或者直接上CopyOnWriteArrayList。CopyOnWriteArrayList的适用场景是“读多写极少”。它的add和remove操作会复制底层整个数组写代价很高但读操作完全无锁。比如订阅者列表、配置监听器列表就很适合用CopyOnWriteArrayList。6. 关于Arrays.asList的连环坑一个看起来是ArrayList、实际不是ArrayList的对象这一段放在最后是因为它的隐蔽性实在太高了。很多新手甚至工作两三年的开发者都在Arrays.asList上栽过跟头。Arrays.asList(a, b, c)返回的对象确实实现了List接口但不是java.util.ArrayList而是Arrays类内部的一个私有静态类。它有两个致命限制不能add和remove调用会抛UnsupportedOperationException。原因很简单——内部类没有实现“结构性修改”的能力它的底层数组是固定大小的。它与原数组共享数据。如果这个数组后续被改asList返回的列表也会变。所以Arrays.asList适合用来“创建一个固定大小的列表视图片段”比如初始化常量集合、作为测试数据源。一旦你需要“能增删的独立ArrayList”必须重新包一层ListString list new ArrayList(Arrays.asList(a, b, c));另一个常见坑是基本类型数组的问题Arrays.asList(1, 2, 3)在Java里看起来正常但如果你写int[] arr {1, 2, 3}; Arrays.asList(arr)得到的List长度是1里面放的是整个int[]。因为基本类型数组无法直接转换为泛型数组asList把arr当成了一个元素。解决办法是用Integer[]而不是int[]或者用Java 8的Stream来处理。7. 面试高频追问ArrayList源码级的细节复盘既然标题是“ArrayList常用方法”最后再补一层——有些细节面试常问而且直接关系到你是否真的理解这些常用方法。7.1 扩容的具体过程是什么样的初始DEFAULT_CAPACITY 10。第一次add时如果底层数组还是空的初始状态会直接分配容量10的数组。之后每次add如果发现size 1 elementData.length就执行扩容旧容量记为oldCapacity新容量 oldCapacity (oldCapacity 1)也就是1.5倍。用Arrays.copyOf把旧元素复制到新数组。新容量如果还不够就取实际需要的值比如addAll一整个大集合时会直接扩容到刚好容纳。如果容量超过了MAX_ARRAY_SIZE会走大数组分支。理解这个流程你就明白为什么“大量追加前用ensureCapacity”有意义。核心就是减少复制次数。7.2 modCount到底为什么存在modCount是AbstractList里一个受保护的字段记录“结构性修改次数”。所有迭代器包括增强for循环背后的Iterator在创建时会记录当时的modCount每次迭代校验当前modCount和记录值是否一致。不一致就抛ConcurrentModificationException。这个机制是fail-fast思想的体现——宁愿快速出错也不要在错误状态下继续运行产生不可预期的结果。7.3 为什么ArrayList的equals方法O(n)但很多人拿它做全列表比较因为List的equals实现就是遍历两个列表逐个元素比较。它是O(n)已经是这类“顺序敏感的比较”能达到的最优复杂度了。但要注意如果你的业务只需要“两个列表包含的元素集合相同不管顺序”那不该用equals应该先排序或者转成Set再比较。8. 我自己写业务代码时的习惯清单方法全部讲完了按我个人经验整理了一份ArrayList使用时的自检清单写代码时照着过一遍能省不少排查时间明确这个List是“读多”还是“写多”。写多且频繁在头部/中间插入考虑LinkedList读多ArrayList没问题。如果元素是自定义对象必须先确认equals和hashCode是否已重写。没重写contains、remove(Object)、indexOf、distinct去重都可能不符合预期。不要在增强for里直接remove或add。要么用Iterator要么用removeIf要么用倒序for。remove(int)和remove(Object)搞清楚参数类型。你存的是Integer删值就必须装箱。大批量add之前调用ensureCapacity用完不再变大的长列表可以trimToSize。需要子集且要独立操作时new ArrayList(list.subList(a, b))复制一份。用Arrays.asList创建出来的List本质不可变要能增删就new ArrayList包装一层。并发环境下不要裸用ArrayList。读多写少用CopyOnWriteArrayList读少写多或读写均衡就用Collections.synchronizedList或手动加锁。ArrayList本身不难难的是在具体场景里做对选择、避开源码层面的隐性坑。把这八个习惯内化之后再去用它的常用方法你会发现代码的稳定性和可读性完全是两个层次。最后再说一个小技巧写完之后多看一眼IDE的“代码提示”里方法签名——有的工具会把数组越界、类型不匹配等问题用弱警告提前标出来比自己硬找高效得多。
