做Java的这几年，我几乎每天都要跟List打交道。不管是从数据库批量捞数据、接口接收JSON数组，还是内存里做中间结果暂存，List始终是集合框架里出场率最高的选手。但有个现象很普遍：很多工作了三五年的同学，你让他背"ArrayList和LinkedList的区别"，他能脱口而出"一个数组一个链表"；可你要是追一句"你的业务系统里为什么默认选ArrayList？数据量到多少万该换？"，不少人就卡壳了。
这篇内容我不打算重复那些面试八股，而是站在实际开发的角度，把List接口的几个核心实现类重新拆一遍。从底层数据结构、扩容机制、线程安全策略，到真实场景里的性能优化、问题排查，尽量把"为什么这样选"讲透。不管你是刚入行的新人，还是准备跳槽想系统捋一遍集合框架的老兵，这篇都应该能帮你把List这块的知识补实。
1. List接口的定位与学习意义
1.1 为什么说List是集合框架的"门面"
List是Collection接口下最重要的一条分支，它定义的核心契约是：有序、可重复、可通过下标访问。这三个词分解开就是：元素按插入顺序排列，同一个对象可以出现多次，支持通过索引快速定位。
整个Java集合框架里，Collection下面有List、Set、Queue三大接口，Map是独立一脉。但如果你统计一个真实项目里import的集合类型，List的占比通常超过一半。原因不复杂——大部分业务数据本质上是"一组东西"，而"一组东西"最直观的建模方式就是列表，用户列表、订单列表、日志列表，全都可以抽象成List。
但List只是个接口，真正干活的是它的实现类。这也是学习集合框架最容易忽略的点：接口决定了"能做什么"，实现类决定了"做得多快、花多大代价"。理解了这一层，你才能在生产环境里做出合理选型，而不是永远new ArrayList<>()一把梭。
1.2 接口设计背后：面向抽象编程的价值
List接口存在的意义不只是"约法三章"，它更大的价值在于让上层代码和具体实现解耦。举个例子，你的方法签名里如果写的是List<String> process(List<String> input)，调用方传入ArrayList或者LinkedList都能正常运行，将来想换实现类，调用处完全不用动。
我在实际重构里见过很多反面案例：有人把方法参数直接写成ArrayList<String>，理由是"反正内部就是用的ArrayList"。短时间看没问题，一旦某个场景需要换成CopyOnWriteArrayList解决并发问题，或者换成LinkedList做高频头尾操作，所有与这个参数有关的方法签名全要跟着改。所以从第一天写代码起，List引用、ArrayList实现，这个习惯要养成。
另外，List接口还定义了subList、indexOf、listIterator等一套丰富的方法族。面试里常问的"List和Set有什么区别""为什么List允许重复"，本质都是在考察你是否理解接口契约背后的业务诉求——有序性和重复性在很多场景下是不可妥协的，比如事务日志、操作记录，顺序错了整个业务就乱了。
2. 四个核心实现类的底层原理拆解
2.1 ArrayList：动态数组的扩容哲学
ArrayList的底层就是一个Object[]数组，加一个size字段记录实际元素个数。你往里面add元素时，它会检查数组容量够不够，不够就触发grow方法扩容。
JDK 8以后的扩容逻辑是：新容量 = 旧容量 + (旧容量 >> 1)，也就是扩容1.5倍。我第一次看源码时觉得奇怪，为什么不直接翻倍？后来查资料和测试才明白，1.5倍是一个平衡点：扩容倍数太小，频繁复制数组，写入性能差；倍数太大，比如翻倍，一次性申请的内存太多，浪费严重。如果旧容量是10，扩容后是15，多出来的5个空位可能在后续几次add里就被填满了，而翻倍到20的话，有10个空位是长期闲置的。
grow方法里还有一个细节：如果minCapacity比1.5倍算出来的值还大（比如你一次性addAll了一万个元素），那就直接用minCapacity作为新容量。之后还有一个判断，如果新容量超过MAX_ARRAY_SIZE（一般认为是Integer.MAX_VALUE - 8），会走hugeCapacity，防止内存溢出。
关键点来了：扩容伴随数组复制，Arrays.copyOf底层是System.arraycopy，这是一个native方法，大批量复制时效率很高，但依然有耗时。如果你的业务是循环往一个ArrayList里插入大量数据，比如几百万条，最好像new ArrayList<>(initialCapacity)这样预先指定容量。我曾经处理过一个导入功能，3万行Excel数据逐行add，不指定容量时扩容了十几次，总共耗时80多毫秒；指定初始容量后，耗时降到30毫秒以内。单看一次操作不大，但在高频调用的接口里，这种开销会被放大。
2.2 LinkedList：双向链表的时间换空间
LinkedList的底层是双向链表，每个节点（Node）持有prev、next和item三个字段。所以它没有"容量"概念，添加元素就是new一个Node挂到链尾，天然没有扩容复制这回事。
很多人背八股时说"LinkedList适合频繁插入删除"，这句话要打个大大的问号。准确的说法是：LinkedList在头部插入、头部删除、以及在已知节点位置前后插入时效率高。但如果你只是随机往链表中间插入，你得先花O(n)时间遍历到那个位置，遍历成本已经把链表操作的优势抵消得差不多了。
我在性能测试里对比过：往一个包含10万元素的List中间位置插入数据，ArrayList耗时约600毫秒（大量元素要后移），LinkedList耗时约1.2秒（光定位就遍历了一半节点）。所以在"频繁插入删除"这件事上，只有操作位置集中在头和尾时，LinkedList才有明显优势。
还有一个容易踩的坑：LinkedList实现了Deque接口，所以你可以当栈、当队列用。但如果你需要的只是"先进先出"的队列，现代JDK里更推荐ArrayDeque，它底层是循环数组，内存紧凑、CPU缓存友好，综合表现比LinkedList更好。LinkedList的实际用武之地在"需要频繁在头部插入且不知道总规模"的场景，以及"需要在迭代过程中删除当前节点"的场景（iterator.remove()是O(1)）。
2.3 Vector与Stack：被时代淘汰的线程安全类
Vector是JDK 1.0就有的老前辈，它的实现和ArrayList几乎一样，区别在于所有关键方法都加了synchronized。听起来"线程安全"是好事，但代价是所有读写操作串行化，并发量稍大就成瓶颈。
我见过一些老项目，里面全是Vector，问同事为什么，回答说"线程安全啊"。实际上，Vector的方法级同步粒度太粗，比如你"先判断isEmpty再get"这两个操作之间，别的线程完全可能插入修改，照样有并发问题。更合理的做法要么用CopyOnWriteArrayList应对读多写少，要么用Collections.synchronizedList包一层并在外部自己加锁控制复合操作，要么干脆用ConcurrentLinkedDeque这类并发容器。
Stack继承了Vector，本质上还是一个动态数组，只是加了push、pop、peek几个栈方法。日常写代码我强烈建议别用Stack，用ArrayDeque就好。原因还是性能：Stack继承自Vector，方法同步有开销，而且ArrayDeque的栈操作更快。面试时要能说出这个观点，会显得你确实读过源码、对比过性能，而不是只背过"栈是先进后出"。
2.4 CopyOnWriteArrayList：读多写少场景的利器
CopyOnWriteArrayList是java.util.concurrent包下的并发List，它的设计用一个词概括就是"写时复制"：每次add、set、remove，都会把整个底层数组复制一份，在新数组上做修改，然后把volatile的数组引用指向新数组。读操作不加锁，直接读当前数组引用。
这个设计有两个鲜明特点：第一，读操作永远不需要锁，性能极高；第二，迭代器是弱一致性的，迭代过程中其他线程修改了List，迭代器不会抛ConcurrentModificationException，但你也看不到那些修改。缺点同样明显：写操作代价极高，每写一次就要全量复制数组，元素越多，单次写越慢，内存占用也翻倍。
所以选型建议很清晰：读多写少、集合规模不大（最多几千条）、对写实时性要求不苛刻的场景，比如缓存黑白名单、配置项列表，用CopyOnWriteArrayList非常舒服。反过来，如果你的集合有几万条数据，而且写入频率很高，千万别用，你会把内存和CPU都烧掉，老老实实加锁或者用ConcurrentHashMap自己管理更实在。
3. 性能基准对比与适用场景判定
3.1 时间复杂度：一切判断的起点
谈性能不能凭感觉，先看算法的复杂度。下面是List几个实现类在不同操作下的时间复杂度，这张表我建议你存下来，面试和设计时都管用：
| 操作 | ArrayList | LinkedList | CopyOnWriteArrayList |
|---|---|---|---|
| get(index) | O(1) | O(n) | O(1) |
| add(E) 尾部追加 | 均摊O(1)，扩容时O(n) | O(1) | O(n)，复制全数组 |
| add(index, E) 指定位置 | O(n)，元素后移 | O(n)，定位开销 + O(1)插入 | O(n) |
| remove(index) | O(n)，元素前移 | O(n)，定位开销 + O(1)删除 | O(n) |
| remove(Object) | O(n) 查 + O(n) 移 | O(n) 查 + O(1) 删 | O(n)，还要复制 |
| 头部插入 | O(n) | O(1) | O(n) |
这里说一下我的理解：复杂度不是唯一指标，但它帮你框定"理论上谁更快"。比如get(index)，ArrayList是数组下标直接寻址，LinkedList要一个一个节点next，数据量一大差距就是天壤之别。10万元素，ArrayList的get是纳秒级，LinkedList是微秒级，差两个数量级。
3.2 内存开销与GC压力：被忽视的成本
复杂度之外，内存占用常常被忽略。ArrayList每个元素就是数组里的一个引用（4字节或8字节，取决于JVM是否开启压缩指针），数组本身有少量对象头开销。LinkedList每个节点除了item引用，还有prev和next两个引用，再加上节点对象头，单个元素的额外内存开销大约多出24字节。如果存100万个Integer，LinkedList比ArrayList多出约24MB内存，这在堆内存有限的服务里不是小数目。
CopyOnWriteArrayList更夸张，写时复制意味着"旧数组 + 新数组"同时存在，最坏情况下内存暂时翻倍。GC压力也跟着涨，因为每次写操作都会产生新数组，老数组等着被回收，年轻代GC频率会明显上升。我曾经在一个定时任务里用CopyOnWriteArrayList存监控日志，每分钟全量替换一次，结果GC频率翻了3倍，后来改成"复用数组 + 显式加锁"才把GC压下去。
3.3 场景判定速查表
结合复杂度和内存，我把日常最常见的业务场景和推荐选型整理成了一张表，新手可以直接对照着选：
| 业务场景 | 推荐类型 | 理由 |
|---|---|---|
| 构建数据列表并随机访问 | ArrayList | 下标访问O(1)，内存紧凑 |
| FIFO队列 | ArrayDeque | 循环数组，CPU缓存友好 |
| 栈（LIFO） | ArrayDeque | 避免Vector的同步开销 |
| 频繁头尾增删 | LinkedList | 头尾节点操作O(1) |
| 读多写少的共享配置 | CopyOnWriteArrayList | 无锁读，高吞吐 |
| 大数据量并发读写 | 自定义锁 + ArrayList | 可控性强，避免全量复制 |
这套选型逻辑的底层原则就一条：让数据结构和访问模式匹配。你主要按下标读，就选数组；你主要在两端增删，就选链表或双端队列；你对并发有要求，先想清楚是读多还是写多。
4. 实战：List性能优化与代码重构
4.1 预估容量：给ArrayList一个准确的起点
前面提过，ArrayList扩容是1.5倍加复制。当你明确知道大概会放多少元素时，直接指定初始容量是最简单的优化。代码示例：
// 反例：默认容量10，插入10万条数据会触发多次扩容复制 List<String> list = new ArrayList<>(); for (int i = 0; i < 100_000; i++) { list.add("item-" + i); } // 正例：预估容量，避免扩容 List<String> list = new ArrayList<>(100_000); for (int i = 0; i < 100_000; i++) { list.add("item-" + i); }初看这只是"省了几次数组复制"，但高频接口里积少成多。我曾经优化过一个报表导出接口，原来每次导出一万条记录，ArrayList扩容了5~6次，加上后续的数据处理，接口平均耗时180ms；改成精确预估后降到120ms，其中约60ms的差距就来自扩容复制。做法很简单：能拿到条数的，比如list.size()、SQLcount(*)结果，直接传给构造函数。
4.2 批量操作与批量删除的正确姿势
批量添加时，addAll比自己循环add更高效。原因在于addAll内部会先计算所需总容量，一次性扩容到位，再批量复制，少了循环里的多次容量检查。写代码时注意：
// 反例：循环add，每个元素都可能触发扩容检查 for (String item : sourceList) { targetList.add(item); } // 正例：批量添加，一次扩容到位 targetList.addAll(sourceList);批量删除也一样。如果你要按条件删除一批元素，最忌讳的是在for循环里用list.remove(i)，因为每次删除都会让后续元素前移，整体时间复杂度会变成O(n*m)。正确的方案有两个：从后往前遍历删除，或者用removeIf（JDK 8+）。
// 推荐：removeIf，内部用迭代器删除，避免并发修改异常 list.removeIf(s -> s.length() < 3); // 或者：倒序遍历，逐项remove for (int i = list.size() - 1; i >= 0; i--) { if (list.get(i).length() < 3) { list.remove(i); } }removeIf的底层是Iterator的remove方法，对ArrayList而言，它其实是把"找到要删的位置"和"批量前移"合并了，能在一个循环里完成，比"遍历→查下标→remove"这种组合高效得多。我在一次清洗脏数据时，用removeIf替换手工for循环删除，处理10万条数据耗时从2.1秒降到400毫秒，效果立竿见影。
4.3 别在循环里做隐藏的O(n)操作
这是List性能优化里最常见的隐形杀手。典型的反面代码是在for循环里调用list.indexOf(x)或list.contains(x)来判重、找位置：
// 反例：外层n，内层indexOf也是O(n)，整体O(n^2) for (String id : idList) { if (allList.indexOf(id) >= 0) { // do something } }两个List一嵌套，整体就变成O(n^2)。数据量小看不出来，数据量上万就开始卡，上十万基本不可用。正确的姿势是把内层List转成HashSet，利用HashSet的O(1)查询把复杂度降下来：
Set<String> allSet = new HashSet<>(allList); for (String id : idList) { if (allSet.contains(id)) { // do something } }这个优化我在真实项目里救过一次火。当时有个会员标签计算任务，两层List都是2万条，原来的O(n^2)跑了将近15分钟，超时报警。改成HashSet后，一次执行只要3秒。记住一个原则：List适合存有序数据，不适合做查找容器；需要频繁contains的场合，第一反应是HashSet，不是List。
4.4 subList、Arrays.asList与不可变集合的坑
这几个都是List里非常容易踩坑的"语法糖"。
先说subList。它返回的不是一个独立的新List，而是原List的视图。什么意思？你对subList做修改，会直接反映到原List上；原List的size一旦变化，之前拿到的subList再操作就会抛ConcurrentModificationException。
List<String> list = new ArrayList<>(List.of("a", "b", "c", "d")); List<String> sub = list.subList(1, 3); // [b, c] list.add("e"); // 修改原List sub.get(0); // 抛出ConcurrentModificationException如果你需要的是"快照"，务必包一层新容器：new ArrayList<>(list.subList(1, 3))。
再说Arrays.asList。它返回的是一个固定长度的List，底层就是传入的数组，所以你不能对它add或remove，否则抛UnsupportedOperationException。它适合做"数组转List的只读展示"，不适合当普通ArrayList用。
String[] arr = {"a", "b", "c"}; List<String> list = Arrays.asList(arr); list.add("d"); // 运行时异常最后是不可变集合。JDK 9+提供的List.of()创建的List，同样不可变，也不允许null元素。优点是内存占用更小、天然线程安全；缺点是如果你想动态增删，别用它。我见过有人图省事List.of(...)返回后又在别处add，结果线上直接抛异常，排查半天才发现是这里。
5. 常见问题与排查技巧实录
5.1 ConcurrentModificationException的真相
ConcurrentModificationException是List开发里出现频率最高的运行时异常之一。它的触发原理是：ArrayList内部维护了一个modCount字段，每次结构性修改（add、remove、clear等）都会加1。迭代器创建时会记录当前的modCount，迭代过程中每走一步都检查expectedModCount是否还等于modCount，不等就抛异常。
所以解决这个问题有三条路：
- 用迭代器的remove方法，不要用List的remove。
- 用
CopyOnWriteArrayList，它的迭代器不检查modCount，天然免疫这个异常。 - 先用普通for循环收集要删的元素，循环结束后统一removeAll。
// 正确示例：迭代器删除 Iterator<String> it = list.iterator(); while (it.hasNext()) { String s = it.next(); if (s.length() < 3) { it.remove(); } }值得一提的是，modCount这种"快速失败"（fail-fast）机制并不是为了绝对正确，而是为了快速暴露并发修改问题。单线程环境下如果你一边迭代一边修改，同样会触发，这种场景多半是代码逻辑写拧了，优先修结构。
5.2 内存里List占用过多的排查思路
服务内存告警，dump文件一看，发现某个List占了很大比例，这种场景我遇过好几次。排查步骤一般是：
- 先看List里存的是什么类型的对象。如果存的是大对象（比如整个数据库记录的映射），考虑只保留必要字段，或者用轻量级DTO。
- 看List本身是否被长期持有。比如把数据存在
static字段里，又没清理，就会像内存泄漏一样只增不减。解决方式是定期清理或改用弱引用。 - 看List的容量是否虚高。
ArrayList的底层数组一旦扩容，即使你clear()了，数组容量也还在。要真正释放，需要重新new ArrayList<>()或者用trimToSize()。
list.clear(); list.trimToSize(); // 将底层数组容量缩减到size，释放空闲内存这个trimToSize是个冷门方法，知道的人不多，但在长生命周期对象里非常实用。比如一个缓存List高峰期扩展到10万容量，低谷期只有几百条，不trimToSize的话，10万个引用位置的内存就白白占着了。
5.3 面试中List相关的高频八股
结合这么多年的面试和被面经验，List主题下真正高频的问题其实就那几个，但每个都能往深了挖：
- ArrayList和LinkedList的区别？别只答"数组 vs 链表"，要补充扩容机制、内存占用、随机访问复杂度、头尾插入差异。
- ArrayList线程安全吗？如何让它线程安全？答案是不安全。可以用
Collections.synchronizedList包一层，但复合操作要自己加锁；读多写少可以用CopyOnWriteArrayList。 - ArrayList扩容机制？1.5倍，
grow方法，System.arraycopy，以及MAX_ARRAY_SIZE的判断。 - 为什么ArrayList的modCount要做fail-fast？为了快速暴露并发问题，避免脏数据默默蔓延。
- Arrays.asList和List.of的区别？前者是数组视图，可变结构但不可增删；后者是不可变集合，完全不能修改。
- subList的坑知道吗？视图、ConcurrentModificationException、要快照就得重新包装。
这些问题与其说是考记忆，不如说是考有没有真正读过源码、踩过坑。回答时带上实际案例和性能数据，面试官一眼就知道你是写过代码的，而不是纯背八股。
5.4 写代码时的几个习惯性建议
最后分享几个我自己平时写List相关代码时坚持的小习惯：
- 能预估容量就预估，哪怕只是模糊的数量级，也远比默认10起步强。
- 方法参数和返回类型尽量用
List，不要用ArrayList，方便将来切实现。 - 遍历时不要改动List结构，要改就明确用迭代器、
removeIf或者收集之后统一处理。 - 不要在循环里做
contains、indexOf、subList这些O(n)操作，先问自己"这里该不该换Set或Map"。 - 并发场景先想清楚读多还是写多，再决定用
CopyOnWriteArrayList还是显式加锁。
这些习惯每个单看都不起眼，但组合在一起就是代码性能的"地板"。一个集合操作写得烂，可能只影响一个接口的延迟；但如果整个项目里到处是O(n^2)的List操作，线上服务的CPU和GC就会用脚投票。
我个人在实际项目里最大的体会是：List这块的知识从来不是"背完就完"的静态内容，它跟JVM内存、GC行为、并发模型强耦合。你每多了解一层底层原理，写出来的代码就更稳一点。尤其是这几年业务系统越来越卷，接口RT稍微高一点就报警，集合选型这类"地基"问题反而最值得花时间打磨。
最后再多说一个小技巧：排查List相关性能问题时，别急着改代码，先用jvisualvm或者async-profiler看一眼热点方法。很多时候瓶颈不在"用了哪个List"上，而在"对List做了多少次无谓的遍历和复制"上。找准病灶再动手，优化效果才能立竿见影。
