企业官网建设流程全解析

老实说，顺序表这个词听起来挺学院派，但把它翻译成大白话，就是一个“能自动长大的数组”。作为数据结构课上最早遇到的线性表形态，几乎所有 Java 初学者都绕不开手写顺序表这一步。它要解决的问题也很直接：原生数组长度固定、插入删除需要手动搬移数据、数组越界全靠人肉盯——顺序表把这些脏活累活全部封装成add、remove、get这样的方法，让使用者只关心元素本身，不用管底层到底怎么搬、怎么扩。

这篇文章不是只贴一段能跑的代码那么简单。我会带着“为什么这么写”的思路，用 Java 从零手写一个支持泛型、动态扩容、安全遍历的顺序表，并讲清楚三个高频考点：扩容机制里的搬移成本到底怎么摊；迭代器的 fail-fast 机制为什么要靠一个modCount计数器；以及为什么底层数组必须用Object[]而不是直接new E[]。适合刚学完 Java 基础准备攻数据结构的人，也适合已经在写业务代码、想补齐基本功的开发者。我尽量用大白话，把顺序表里所有容易踩的坑都摆到你面前。

1. 顺序表到底是什么：先搞懂数组的痛点

1.1 数组的三宗罪：固定长度、手动搬移、越界全靠自觉

Java 里数组是最基础的内建容器，int[] arr = new int[10]一行代码就能用。但它有一个绕不开的硬伤：长度在创建那一刻就锁死了。想装第 11 个元素，没有余量就只能另开一段更大的内存，然后把旧数组里的元素一个一个拷过去，最后让引用指向新数组。这个过程听起来不复杂，但你要是写在业务代码里，每个插入点都要重复一遍，很快你就会发现代码里到处都是拷贝循环，读起来像灾难现场。

更难受的是插入和删除。想在数组中间位置插入一个元素，必须先把该位置以及之后的所有元素整体往后挪一格，给新元素腾地方；反过来删除中间元素，要把它后面的所有元素整体往前挪一格，把空洞填上。这个“搬移”动作本身不难，难的是你不能搬错方向、不能越界、还要考虑边界位置的特殊情况。曾经我有一次在项目里手写了一个业务列表对象，删除时直接data[i] = data[i + 1]一路覆盖下去，结果漏了最后一个位置的清理，导致最后一个元素被复制了一份残留。这种问题非常隐蔽，因为数据量小的时候根本看不出来，等到数据量大了、内存紧张了才会突然冒出来。

第三个痛点是没有真正的边界检查能力。数组的下标越界抛ArrayIndexOutOfBoundsException，但那只是 JVM 层面的最后一道防线，本质上属于运行时才能暴露的错误。程序员需要的是一个能主动拦截非法下标的容器：插入时检查index是否小于 0、删除时检查index是否超过了当前元素个数，而不是等数组抛异常了再排查。

1.2 顺序表替我们解决了什么

顺序表的思路并不复杂：底层仍然是一段连续的内存数组，但它额外维护了一个size变量，用来记录“当前实际存了多少个元素”，而不是直接使用数组的length。这个看起来微小的区别，立刻让容量和元素数量解耦了。数组的length代表“最多能装多少”，顺序表的size代表“已经装了多少”。中间那些空闲位置对使用者不可见，你用get(i)的时候只会取到真正存放元素的位置，永远不会意识到背后还有空余空间。

同时，顺序表把扩容逻辑收敛到一个内部方法里。每一次add之前先检查空间是否够用，不够就内部扩一次容，使用者完全无感知。插入和删除时需要的元素搬移，也封装成几个标准方法，内部反复验证边界条件，外部调用者只需要传入下标即可。这样设计之后，你会发现心智负担大幅下降：你不再需要关心数组空间够不够、下标有没有越界、最后一位有没有残留对象，因为这些问题在顺序表内部已经反复处理过了。

这也解释了为什么几乎每本教材、每个课程都会让你手写一次顺序表。它体积不大，但集中体现了面向对象封装、底层内存操作、边界条件设计这几个基本功。写好一个健壮的顺序表，再去学链表、栈、队列、跳表，都会轻松很多。

1.3 顺序表擅长什么、不擅长什么

顺序表最大的优势是随机访问。底层是连续内存，get(index)可以通过首地址加偏移量直接算出目标位置，一步到位，时间复杂度是 O(1)。这个特性决定了它非常适合做按序号读数据的场景：排行榜查询、日志列表翻页、按索引读取配置项等等。

它的短板也来自连续内存：在中间插入或删除一个元素，平均需要搬移一半的元素，时间复杂度是 O(n)。如果业务逻辑是高频地在列表头部插入数据，顺序表会非常痛苦。我实际测过一个简单的场景，向一个容量 10 万的有序表头部循环插入数据，耗时是尾部插入的几百倍，原因就是每次插入都要搬移全部数据。此时你应该考虑链表，它是为“任意位置高频插入删除”而生的。这个取舍在最后一章我会专门展开。

2. 动手之前必须想清楚的设计问题

2.1 底层数组为什么是 Object[] 而不是 E[]

很多人第一次写泛型顺序表，会自然而然地写private E[] data;，然后紧接着在构造方法里写data = new E[10];，编译直接报错。原因要追溯到 Java 泛型的类型擦除机制：在运行时，E这个类型参数的信息是不存在的，编译器无法确认E具体是什么类型，更不可能生成new E[10]这种需要具体类型信息的字节码。

解决方案是绕道Object[]。用Object[]作为底层存储，对外暴露方法时再用强制类型转换把元素还原成E类型。这样做的代价是需要写一些@SuppressWarnings("unchecked")注解，但换来的是泛型的灵活性和类型安全。每次都写注解看起来有点丑，实际上这是 JDK 源码自己的做法——翻开 ArrayList 的源码，你会发现里面存的也是Object[] elementData，而不是E[]。

转换的细节也值得注意。取元素时：

@SuppressWarnings("unchecked") public E get(int index) { checkIndex(index); return (E) data[index]; }

这里编译器虽然会警告“unchecked cast”，但逻辑上是安全的。因为整个容器的设计保证了：凡是add进去的元素，调用方必须传入E类型的对象；凡是get出来的位置，必然之前被add写入过一个合法元素。只要不通过反射等歪门邪道破坏内部结构，类型擦除不会造成实际安全问题。

一个小坑：不要把Object[]暴露成公共 API。如果你写了一个Object[] toArray()方法，直接把内部数组返回出去，调用方就可以通过修改数组元素来绕过顺序表的边界检查，甚至插入 null 之外的类型，彻底破坏容器的不变量。正确的做法是返回一个拷贝：Arrays.copyOf(data, size)。这一点在面试里也经常被追问。

2.2 默认容量、扩容倍数怎么选

容量策略是顺序表设计里最需要权衡的部分。初始容量如果太小，比如写成 1，那么第二次 add 就要扩容，前几次插入会频繁发生数组拷贝，白白浪费性能；初始容量如果太大，比如写 4096，一个只存 3 个元素的列表就白白占用了几十 KB 堆内存。JDK 的 ArrayList 默认容量是 10，这是一个经过多年实践验证的平衡值：对于大多数业务场景，它既能显著减少前期的扩容次数，又不会浪费太多内存。

扩容倍数也有讲究。常见的选择有 1.5 倍、2 倍、甚至 1.25 倍。倍数越大，扩容触发频率越低，但每次扩容后浪费的空闲空间越多；倍数越小，空间利用率越高，但扩容越频繁。1.5 倍是 JDK 的选择，这个值能让扩容前后数组长度保持一个比较合理的比例关系，并且整体内存占用增长相对平滑。

一个需要记住的公式是：扩容搬移的总均摊成本只跟扩容倍数有关。假设初始容量为 C，扩容倍数为 f（f > 1），那么建表后第 k 次扩容时，搬移的元素总数约等于 C × (1 + f + f² + ... + fᵏ)。这个等比数列求和后，均摊到前面的每一次插入操作上，是一个常数。f 越大，常数越小，意味着单个插入的均摊时间越接近 O(1)；f 越小，常数越大，但空间越省。1.5 倍就是在这种空间与时间的博弈里找出的一个工程折中。

2.3 要不要缩容，什么时候缩

缩容是很多初学实现里缺失的一环。试想有这样一个列表：从 10 万条数据涨到 100 万条，然后业务上批量删掉了 90 万条，此时size只有 10 万，但底层数组容量可能还是 100 万级别。这 90 万条数据占用的内存并不会因为元素被删除而自动释放，白白浪费堆空间。对于长生命周期的大列表，这种浪费必须处理。

缩容策略不能太激进。如果每次删除都触发缩容，就会出现一种叫“缩容抖动”的现象：删除一个元素后缩容，紧接着又加回来一个元素触发扩容，底层数组反复拷贝，性能急剧劣化。比较稳妥的规则是：当size小于容量的四分之一时，才将容量缩为原来的一半。这样即使缩容之后立刻有少量数据涌入，容量的半价缓冲也足够消化，不会马上再次扩容。

清理缩容还有一个容易忽略的细节：缩容前要把被裁剪掉的那部分元素置为null。如果直接Arrays.copyOf(data, newCapacity)，被裁剪区域的旧引用在对象仍然被数组中引用时无法被垃圾回收——说直白点，你把容量缩了，但被裁掉的那几个位置上的对象引用还残留在旧数组里，如果这个旧数组对象本身还被引用，那对象就无法被回收。所以手动把多余位置的引用清空，是防止内存泄漏的基本功课。

3. 完整实现：增删改查与动态扩容

3.1 类骨架与构造方法

把前面的设计决策落地成代码。类骨架如下：

import java.util.Arrays; import java.util.Iterator; import java.util.NoSuchElementException; public class MyArrayList<E> implements Iterable<E> { private Object[] data; private int size; private int modCount; private static final int DEFAULT_CAPACITY = 10; public MyArrayList() { this.data = new Object[DEFAULT_CAPACITY]; } public MyArrayList(int initialCapacity) { if (initialCapacity < 0) { throw new IllegalArgumentException("Illegal Capacity: " + initialCapacity); } this.data = new Object[initialCapacity]; } public int size() { return size; } public boolean isEmpty() { return size == 0; } }

modCount这个字段先记住，它是为迭代器服务的结构修改计数器。任何会改变size数量或者改变元素排列位置的操作，比如add、remove、clear，都必须让modCount++。如果只是替换某个位置的值（set），元素的个数和排列没有变化，一般不需要计数。

构造方法里对initialCapacity的负值检查不能省。有人可能觉得new Object[-1]抛异常就够了，但那个异常是NegativeArraySizeException，语义不够明确。我们主动抛IllegalArgumentException可以给出更友好的错误信息，这也是 JDK 的做法。

3.2 扩容触发条件与搬移动作

每次插入前调用ensureCapacity(size + 1)，它的职责很纯粹：判断当前底层数组长度是否足够容纳新元素，不够就调用grow方法扩容。

private void ensureCapacity(int minCapacity) { if (minCapacity > data.length) { grow(minCapacity); } } private void grow(int minCapacity) { int oldCapacity = data.length; int newCapacity = oldCapacity + (oldCapacity >> 1); if (newCapacity < minCapacity) { newCapacity = minCapacity; } data = Arrays.copyOf(data, newCapacity); }

这里的oldCapacity + (oldCapacity >> 1)就是 1.5 倍扩容。右移一位等价于除以 2，所以新容量等于旧容量加上旧容量的一半。用位运算纯粹是为了快一点，可读性也能接受。if (newCapacity < minCapacity)这个保护不能丢，否则遇到极端情况：比如初始容量是 0，旧容量加一半还是 0，永远扩不到minCapacity。

Arrays.copyOf内部会分配新数组，并把旧数组中的元素复制过去。这一步是扩容的全部成本。复制完，旧数组对象失去了引用，会被垃圾回收。理解这一点很重要：扩容不是“把数据搬一下”这么简单，它包含一次新内存分配、一次数组拷贝、一次旧引用置空，三者都会产生开销。所以扩容次数要尽量少，这也从侧面说明了初始容量不能设得太小的原因。

3.3 插入细节：为什么必须从后往前搬

尾部追加元素是最简单的：ensureCapacity之后直接data[size++] = element。但任意位置插入就没那么简单了，核心逻辑是这样的：

public void add(int index, E element) { checkIndexForAdd(index); ensureCapacity(size + 1); System.arraycopy(data, index, data, index + 1, size - index); data[index] = element; size++; modCount++; }

System.arraycopy(data, index, data, index + 1, size - index)的意思是把index到size - 1这一段元素全部向后平移一格。为什么必须从后往前搬？因为这是同一个数组内部的拷贝，如果从前往后搬，前面的元素会先覆盖掉后面的元素，导致数据错乱。

举个具体例子：数组已经有 [A, B, C, D]，现在要在 index=1 的位置插入 X。如果从前往后搬：先把 A 挪到位置 1，再拿 A 的新值去覆盖位置 2，结果是 [A, A, A, A]，后面全乱了。而从后往前搬：先把 D 挪到位置 4，再把 C 挪到位置 3，再 B 挪到位置 2，空出位置 1，整个过程互不干扰，最后得到 [A, X, B, C, D]。这就是为什么任意位置插入必须倒着搬的原因。

System.arraycopy是 JVM 提供的 native 方法，底层会针对不同平台尝试使用更高效的拷贝方式，比手动写 for 循环复制要快得多。日常业务开发可能感觉不到差异，但如果你做的是高性能容器，这里就是必须抠的细节。

checkIndexForAdd的价值在于把非法下标拦截在外。插入操作的合法范围是0 <= index <= size，下标等于 size 时表示追加到末尾，这个逻辑必须单独实现一次。删除和获取操作的合法范围是0 <= index < size，两者边界不同，不能共用同一个检查方法。

3.4 删除、修改与查找的实现要点

删除元素时，需要把index之后的所有元素向前平移一格。这里的方向与插入相反，是从前往后搬。删除中间元素后，size减一，但原来最后一个位置仍残留着被搬移后的一份重复引用，必须手动置为null。

@SuppressWarnings("unchecked") public E remove(int index) { checkIndex(index); E old = (E) data[index]; int numMoved = size - index - 1; if (numMoved > 0) { System.arraycopy(data, index + 1, data, index, numMoved); } data[--size] = null; modCount++; return old; }

data[--size] = null这行是我特别想强调的。先让size减一，再把新 size 位置上的元素清空，这样既维护了元素个数，也释放了最后一个旧位置的引用。如果不做这一步，删除元素后那个位置还指向一个对象，而这个对象对外不可见、永远无法通过容器访问，但它仍然占用内存，这就是隐性的内存泄漏。

修改元素的操作相对简单：校验下标、取出旧值、写入新值、返回旧值。注意set操作不要加modCount，因为元素个数和排列顺序都没有变化。查找元素分为按下标查和按内容查两种。按下标查是顺序表的强项，get直接返回data[index]，O(1) 操作。按内容查需要遍历数组，用equals逐一比较：

public int indexOf(Object o) { for (int i = 0; i < size; i++) { if (o == null ? data[i] == null : o.equals(data[i])) { return i; } } return -1; }

这里的o == null ? data[i] == null : o.equals(data[i])是一种兼容 null 的写法：如果要查找的元素是 null，就直接跟数组里的 null 位置比较；否则调用equals进行比较。很多新手只写o.equals(data[i])，遇到 list 里存了 null 的情况直接抛 NPE。这种细节虽然不起眼，但在生产环境中很可能就是事故源头。

4. 迭代器与遍历安全：fail-fast 是怎么工作的

4.1 实现 Iterable，让 for-each 变成可能

顺序表实现了Iterable<E>接口后，就可以直接使用for (E e : list)这种增强 for 循环遍历了。编译器在遇到 for-each 时，会隐式调用iterator()方法拿到迭代器，然后循环调用hasNext()和next()。所以实现一个正确的迭代器，等于给了这个容器最自然的遍历语法。

迭代器本质上是一个快照游标，它保存了遍历过程中的当前位置信息。我的实现里用了两个辅助变量：cursor表示下一个要返回的元素位置，lastRet表示上一个返回的位置（没有则设为 -1）。这样设计的好处是，迭代器的remove方法可以清楚知道“上一次是通过哪个位置取的元素”，从而安全地删除它。

4.2 modCount 计数器和快速失败机制

如果在迭代过程中，外部代码直接调用容器本身的remove或add方法，迭代器内部的状态就会和容器真实状态脱节。比如你正迭代到下标 3，此时外层把下标 1 的元素删掉了，那么原本下标 4 的元素移动到了下标 3，迭代器以为下一个要访问的是老下标 4，实际老下标 4 已经变成了另一个元素。遍历结果就会错乱，甚至造成重复访问或遗漏。

为了解决这个问题，Java 的容器设计引入了 fail-fast 机制。思路很简单：迭代器在创建时记录下当时的modCount，保存为expectedModCount。每次调用next()之前，先检查当前容器的modCount是否还等于expectedModCount，如果不相等，说明容器在迭代过程中被结构性修改过，立即抛出ConcurrentModificationException。

private class Itr implements Iterator<E> { int cursor; int lastRet = -1; int expectedModCount = modCount; @Override public boolean hasNext() { return cursor != size; } @SuppressWarnings("unchecked") @Override public E next() { checkForComodification(); if (cursor >= size) { throw new NoSuchElementException(); } E element = (E) data[cursor]; lastRet = cursor; cursor++; return element; } @Override public void remove() { if (lastRet < 0) { throw new IllegalStateException(); } checkForComodification(); MyArrayList.this.remove(lastRet); cursor = lastRet; lastRet = -1; expectedModCount = modCount; } private void checkForComodification() { if (modCount != expectedModCount) { throw new ConcurrentModificationException(); } } }

这里有一个关键细节：迭代器自己的remove方法在调完MyArrayList.this.remove(lastRet)之后，需要立刻把expectedModCount更新为最新的modCount。否则下一次调用next()时，modCount已经变了，而expectedModCount还是旧值，就会误判为结构被修改过而抛异常。这个 bug 是我在实际写容器时最容易犯的错误之一，很多教程里的迭代器实现甚至会漏掉这一行，导致一个“明明没被外部修改却抛异常”的诡异现象。

4.3 迭代器 remove：从内部删除为什么推荐

迭代器提供了自己的remove方法，而且是单参数删除，不需要传下标，直接删除“上一次遍历到的元素”。这在按条件筛选数据时特别好用：遍历一遍，遇到不满足条件的就iterator.remove()，不用维护一堆待删除下标再二次循环。

为什么推荐用迭代器的remove而不是在 for-each 里直接调容器remove？因为 for-each 中的iterator.next()已经捕获了expectedModCount，此时再调外层的remove会让modCount变化，下一次循环检查时就抛异常。有一种常见错误写法就是：

for (Integer num : list) { if (num < 0) { list.remove(num); // 抛 ConcurrentModificationException } }

正确写法是：

Iterator<Integer> it = list.iterator(); while (it.hasNext()) { if (it.next() < 0) { it.remove(); } }

另外要提一个坑：如果你用contains方法来判断并删除，在高并发场景下，这个“先判断再删除”的组合操作并不是原子的。多个线程同时判断到同一个元素都存在，然后一起删除，可能把原本只想删一条的数据删成两条。迭代器的remove同理，它只保证单线程语义。真的要支持并发修改，应该加锁或者使用并发容器。

5. 实战排雷：从性能陷阱到异常排查

5.1 扩容搬移的均摊成本计算

很多文章都会提到“扩容是 O(n) 的操作”，这句话只说对了一半。单次扩容确实是 O(n)，但如果把多次扩容的累计成本平分到每一次add操作上，结论是均摊 O(1)。这个均摊分析是动态数组性能的核心论据，值得展开算一遍。

设初始容量为 C，扩容倍数为 f。第 k 次扩容时，数组容量从 C × f^(k-1) 变成 C × f^k，这次扩容需要搬移旧容量那么多个元素，也就是 C × f^(k-1) 个。把前 k 次扩容的搬移量加起来，是一个等比数列求和，约等于 C × (f^k - 1) / (f - 1)。而此时列表已经成功插入了 C × f^k 个元素。因此每个插入操作平均摊到的搬移量大约是：

总搬移量 / 插入次数 ≈ C × f^k / (f - 1) / (C × f^k) = 1 / (f - 1)

这个结果非常漂亮：均摊成本只跟扩容倍数有关，跟数据规模无关。当 f = 1.5 时，均摊到每次插入的搬移量大概是 2 个元素；当 f = 2 时，均摊量是 1 个元素。也就是说，扩容倍数从 1.5 提高到 2，单次插入的均摊成本只从 2 降到 1，收益有限，但内存浪费率却上升了非常多。这就是为什么 1.5 倍比 2 倍更受欢迎——性能差距不大，内存更节省。

第一次扩容下面这段代码，我想让你看看ArrayList里面的他：

5.2 扩容倍数 1.5 和 2 的选择：一张表说清楚

为了直观理解不同扩容倍数的差异，我手工模拟了从初始容量 10 开始、添加 10 万个元素的过程，记录扩容次数、最终容量和最大浪费量。结果如下：

从这张实测表可以看得很清楚：2 倍扩容虽然扩容次数少，但浪费容量接近一半；1.5 倍扩容用稍微多一点的扩容次数，换来了更低的浪费率。如果你的元素本身占内存很大，比如一个对象几百字节，那么 2 倍扩容的空间浪费会非常可观。反过来，如果元素很轻量，比如存 Integer，2 倍扩容也无伤大雅。这取决于你的实际场景。

理论之外的工程经验是：如果你提前知道要存大概 N 条数据，直接使用MyArrayList(int initialCapacity)构造方法指定容量，可以把扩容次数压低到 0，这是在性能敏感场景下最推荐的做法。这一点我在后面会再强调。

5.3 遍历中删除元素为什么会抛 ConcurrentModificationException

我在 4.3 节演示了 for-each 中直接删除会抛异常。为了说明这个机制的价值，我再举一个更隐蔽的案例：在一个迭代器遍历过程中，外部线程同时向列表添加元素。

由于单线程的modCount在每次add时也会自增，迭代器的expectedModCount保存的是创建时候的值，两个值一旦不一致，next()就会立刻抛ConcurrentModificationException。这是故意设计的快速失败，而不是 bug。它的意义在于：容器无法保证在并发修改下遍历结果仍然正确，与其让你拿到错误数据然后排查半天，不如立刻告诉你“这里出事了，赶紧停下来”。

排查这个异常时，常见的误区是把所有锅都甩给多线程。实际上单线程也会触发：你的代码里，先用迭代器遍历，在遍历体里又调用了list.remove或者list.add，这就足够触发。排查思路很简单：拿到堆栈，找到抛异常的位置，再看当前线程在迭代过程中有没有对同一个 list 做出结构性修改。如果有，要么改用迭代器的remove，要么在遍历结束后再统一删除，要么使用并发容器。

5.4 元素清空不置 null 会导致内存泄漏

前面提过remove方法里data[--size] = null的作用，这里把内存泄漏的问题单独讲透。很多人用顺序表存图片、文件、大对象之类的引用时，只关注容器里的元素个数，却忽略了容器自己持有的对象引用。只要容器还活着，这些对象就不会被垃圾回收。如果你把 100 万条数据处理完后调用了clear()，但clear()只是把size置 0，那就等于把底层数组里所有的元素引用都“隐藏”了，但数组本身还在，数组里存的引用也还在。这些对象永远不会被回收，直到容器对象自己被回收。

正确的clear实现必须遍历一遍数组，把所有位置都置为null，再重置size。代价是 O(n)，但这是必要的清理成本：

public void clear() { for (int i = 0; i < size; i++) { data[i] = null; } size = 0; modCount++; }

还有一个相关的操作：手动调用ensureCapacity保护机制之后，底层数组可能膨胀得很大，但实际只存了几个元素。这时候你可以提供trimToSize()方法，把底层容量缩到和 size 一致，释放多余空间。它的实现就是data = Arrays.copyOf(data, size)，但同样要注意清空被裁剪区域的引用。JDK 的 ArrayList 就有这个方法，但日常很少用到，因为缩容也有成本。真正需要的是在批量删除后、对象长期持有列表引用时调用一次。

6. 与链表的取舍及源码印证

6.1 顺序表和链表怎么选

顺序表与链表的取舍，本质上是“连续内存 + 随机访问”与“离散内存 + 灵活插入”的取舍。我做一个简单的对照：

实际业务里，绝大多数日常需求是“往末尾追加、按顺序遍历、按下标取某个值”，这时候顺序表完胜。只有一种场景链表有明显优势：你有一个明确的“要在列表头部反复插入删除”的需求。比如实现一个 LRU 缓存，每次访问都要把元素移动到链表头部，链表结构天然适合。还有就是在不确定总数据量、且插入删除集中在头尾两端的情况下，链表更稳。

从内存分配的角度看，链表每个节点都是单独分配的，分散在堆内存各处，遍历时 CPU 缓存命中率低，性能往往比直觉上差很多。顺序表则是一整块连续内存，访问时局部性好，硬件层面更友好。这也是为什么很多性能敏感的项目即使知道可能需要插入删除，也仍然优先用顺序表的原因。

6.2 从手写实现反推 JDK 源码的设计思路

手写一遍顺序表之后，再去看 JDK 的ArrayList源码，你会发现自己能秒懂很多当初觉得很奇怪的写法。

比如ArrayList的底层字段叫private transient Object[] elementData;，size叫private int size;，它也有modCount，并且继承自抽象的AbstractList。它的grow方法里int newCapacity = oldCapacity + (oldCapacity >> 1);跟我前面写的一模一样。它也有严格的rangeCheck和rangeCheckForAdd，分开检查“可读下标”和“可插入下标”。它的remove方法也会在搬移元素后将elementData[--size] = null置空。这些不是我抄它，而是所有健壮的动态数组实现都必然会收敛到同一套设计——边界、搬移、置空、快失败，一个都不能少。

还有一个值得品味的细节：ArrayList的ensureCapacity是一个 public 方法，它的存在告诉你，JDK 的设计者也认为“预分配容量”是一个值得暴露给使用者的能力。当你提前知道大概要装多少元素，手动指定容量或提前调用一次ensureCapacity，就可以彻底避开扩容的搬移成本。我也是在实际项目里用 ArrayList 存过几十万条记录之后，才真正理解这个 API 的价值。

源码里还藏着一些我上面没提到的优化：ArrayList为了支持随机访问get时避免每次检查size，内部把modCount和expectedModCount分离，迭代器通过SubList的实现也独立维护了一套修改计数。这些细节不是一次能全讲完的，但只要你把上面这个手写版彻底吃透，再去看 JDK 源码，阅读成本会低很多。

写到这里，我自己最真实的体会是：顺序表最大的锻炼价值不在“能跑”，而在“把边界想清楚”。插入时下标能不能等于 size、扩容后旧数组还要不要管、迭代器 remove 之后 expectedModCount 要不要重置、clear 之后要不要把数组置 null——每一个问题都会在你上线后以奇怪的方式回报你。如果你正准备面试或复习基本功，强烈建议把我上面的代码完整跑一遍，然后故意改几个边界条件看看报错，再回来对照这篇文章的排查点，你会比直接背代码多记住十倍。后续我还会基于这个顺序表改造一个环形队列版本，以及聊聊多线程下如何加锁让容器变安全，有兴趣可以把完整代码存下来，到时候直接拿来改。