插门胡的小背心1. 顺序表到底是个什么东西：从数组到抽象数据类型的跳跃
很多人学数据结构的时候，把顺序表简单理解成"数组"，这其实没问题，但也不完全对。数组是编程语言提供的一种基础类型，而顺序表是基于数组实现的一种抽象数据类型。什么意思呢？就是你在写业务代码的时候，不应该直接去操作数组下标、手动管理元素个数，而是通过顺序表暴露出来的接口来操作数据。这个思想上的转变，恰恰是很多入门者卡住的地方。
顺序表的定义其实很朴素：用一段地址连续的存储单元依次存储数据元素。注意"地址连续"这四个字，这是顺序表区别于链表最核心的特征。正因为地址连续，它才能做到O(1)时间内的随机访问，也就是你给我一个下标，我直接拿数组基地址加上偏移量就能取到元素。你可以把它类比成电影院连座的座位，每个座位有固定编号，观众按编号依次坐好。想找第10号座位的人，不需要从头一个个数，直接走过去就行。
但连续地址也带来了一个天然的麻烦：如果要在中间插入或者删除一个元素，你没法像链表那样只是改几个指针了事，必须把后续元素整体往后或者往前挪动。这个挪动操作的时间复杂度是O(n)，顺序表的主要开销都集中在这里。
在实际工程和面试中，顺序表常用的场景包括：需要频繁按下标访问元素的集合（比如排行榜、日志缓存）、元素数量相对稳定且尾部追加为主的任务队列、以及对局部缓存友好性要求较高的数据处理流程。因为顺序表的数据是连续存放的，CPU缓存命中的概率远高于链表，这一点在大数据量迭代时差异极其明显。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. Java手写顺序表：从零搭出一个完整可用的容器
2.1 底层结构设计与字段选择
我自己在实现顺序表的时候，通常会定义两个核心字段：
java复制public class MyArrayList<E> {
private static final int DEFAULT_CAPACITY = 10;
private Object[] data;
private int size;
}
data就是那个连续存储区域的底层数组，size记录当前已存储的元素个数。这里有个特别重要的约定：size既是元素个数，也同时是"下一个元素要填入的位置下标"。比如数组容量是10，当前有3个元素，那size就是3，下次插入就直接放到data[3]。很多初学者容易在这个地方混淆，我建议从一开始就明确这个语义，后面写插入、删除方法时思路会特别清晰。
泛型类型E理论上是可以直接创建泛型数组的，但在Java中由于类型擦除机制，直接new E[10]是会报错的。我通常用Object[]作为底层存储，取值时再做强制类型转换。这属于实现细节，业务层面无感知。
2.2 扩容机制怎么实现才对
容量满时插入新元素怎么办？答案很简单：扩容。我的做法是创建一个新的更大的数组，把旧数据全部迁移过去，再让引用指向新数组。
java复制private void ensureCapacity() {
if (size == data.length) {
int newCapacity = data.length + (data.length >> 1);
data = Arrays.copyOf(data, newCapacity);
}
}
注意这里扩容倍数我选的是1.5倍，不是直接翻倍。这是我在实际项目里比较偏好的方案。如果扩容倍数太大，比如2倍，虽然均摊下来的插入效率很高，但会白白浪费很多内存；如果太小，比如每次只加1，那频繁扩容带来的数组复制开销会非常恐怖。1.5倍是一个在时间和空间之间比较均衡的取值。Java官方ArrayList在JDK 8之后的默认扩容策略就是1.5倍，这也印证了这个选择的合理性。
关于扩容还有个小细节：ensureCapacity这个检查，应该是每次插入之前做，还是每次插入之后做？我在初学阶段一度写成了插入之后检查，结果逻辑稍不留神就容易出现数组越界。我建议养成习惯：在插入方法里，第一步就是做容量检查，保证调用插入时底层数组一定有空位。
3. 核心方法逐个击破：增删改查的全景拆解
3.1 插入方法：头部、尾部和中间位置的做法
顺序表的插入分三种典型位置：头部插入、尾部插入和任意位置插入。尾部插入是最简单的，不需要移动任何元素：
java复制public boolean add(E element) {
ensureCapacity();
data[size++] = element;
return true;
}
但头部插入和中间插入就麻烦多了。假设现在数组里有 [A, B, C, D]，你想在索引1的位置插入X，那C和D要往后挪，把位置1空出来给X。关键在于：要从最后一个元素开始，从后往前依次往后挪，绝不能从前往后。如果从前往后挪，D会被C覆盖，数据就丢了。
java复制public void add(int index, E element) {
if (index < 0 || index > size) {
throw new IndexOutOfBoundsException("Index: " + index + ", Size: " + size);
}
ensureCapacity();
for (int i = size; i > index; i--) {
data[i] = data[i - 1];
}
data[index] = element;
size++;
}
这段代码里的边界条件index > size也很关键。size位置的插入等于尾部追加，是允许的，但index超过size就不合法了。面试时候经常有人漏掉这个判断，导致插入后数组中间出现不连续的空洞。
3.2 删除方法：移位方向是反过来的
删除操作是插入的逆过程。删除索引2的元素后，后面的元素要整体前移。这里的移位方向是从前往后，因为我们是把后面的值覆盖到前面的位置上：
java复制public E remove(int index) {
if (index < 0 || index >= size) {
throw new IndexOutOfBoundsException("Index: " + index + ", Size: " + size);
}
E oldValue = (E) data[index];
for (int i = index; i < size - 1; i++) {
data[i] = data[i + 1];
}
data[--size] = null;
return oldValue;
}
最后一行data[--size] = null是我在实际编码中比较注意的一个地方。把最后一个位置置为null，是为了让GC能够正确回收不再被引用的对象。如果不置null，数组里还残留着一个已经"被删除"的引用，万一后面数组扩容、数据迁移时，这个本该被回收的对象还活着，就会造成内存泄漏。这个问题在内存密集型服务中尤其明显，虽然单次泄漏量不大，但高频删除操作累计下来是很可观的。
3.3 查找与修改：按下标和按值两条路线
顺序表的查找有两种语义。
第一种是按下标找，也叫随机访问，时间复杂度O(1)：
java复制public E get(int index) {
if (index < 0 || index >= size) {
throw new IndexOutOfBoundsException("Index: " + index + ", Size: " + size);
}
return (E) data[index];
}
第二种是按值找，返回第一个匹配元素的下标，时间复杂度O(n)：
java复制public int indexOf(Object element) {
if (element == null) {
for (int i = 0; i < size; i++) {
if (data[i] == null) {
return i;
}
}
} else {
for (int i = 0; i < size; i++) {
if (element.equals(data[i])) {
return i;
}
}
}
return -1;
}
这里有个小细节很多人会忽略：查找null元素时要单独处理，因为element.equals(data[i])在element为null时会抛空指针异常。所以要么正过来用element.equals(data[i])并特判null，要么反过来用data[i].equals(element)，后者就没有这个问题。两种风格在业界都有，但必须想清楚你的数据里允不允许出现null。
修改元素就简单多了，找到对应下标直接覆盖即可：
java复制public E set(int index, E element) {
if (index < 0 || index >= size) {
throw new IndexOutOfBoundsException("Index: " + index + ", Size: " + size);
}
E oldValue = (E) data[index];
data[index] = element;
return oldValue;
}
4. 顺序表的高阶操作与性能深挖
4.1 为什么说均摊时间复杂度是O(1)
尾部插入在最坏情况下会触发扩容，单次操作确实可能是O(n)。但如果我们从多次操作的角度来审视，扩容导致的开销其实是被平摊掉的。
举个具体例子：假设数组初始容量是1，按1.5倍扩容。从容量1扩到2，需要拷贝1个元素；从2扩到3，拷贝2个；从3扩到4，拷贝3个；从4扩到6，拷贝4个；从6扩到9，拷贝6个。把所有扩容拷贝的代价加起来，再除以总插入次数，得到的平均成本是个常数。用更严格的说法：执行n次尾部插入的总时间复杂度是O(n)，均摊到每次就是O(1)。
我在面试候选人聊到这个问题时，发现很多人会背"均摊O(1)"这个结论，但说不清楚为什么。这里我给你们一个能在现场就讲明白的分析方式：每次扩容X个位置，意味着下一次至少能够连续执行X次O(1)的插入，才有可能触发下一次扩容。也就是说，扩容产生的拷贝代价被后续X次普通插入"平摊"掉了。这个逻辑链条比干巴巴的公式容易理解得多。
4.2 数组迁移的极致优化思路
实战中如果做大数据量顺序表的插入，默认的System.arraycopy其实已经足够快了，它是JVM级别的本地方法调用，底层是汇编级别的内存拷贝。但这里有一个工程层面的优化点：减少无效拷贝。
假设你有一个容量10000的表，目前只用了100个位置，此时有人要调用add(50, element)，你会发现数组后面有9900个空位，根本不需要扩容，只要把50到99的50个元素往后挪一位就行。这个操作的拷贝数量是O(n)中的n=50，而不是n=10000。这个逻辑看起来很简单，但我在Code Review时经常看到有人一遇到插入就判断"满了没有"，完全不考虑"被占用的空间是否真的靠近容量上限"，结果白白做了大量冗余拷贝。
所以我的建议是：ensureCapacity里判断的应该是"size == data.length"，也就是实际元素数等于底层数组长度时才扩容，而不是拿着一堆尚未占用的容量瞎操心。这跟"数组长度"和"已用元素数"这两个概念严格区分开是同一个道理。
4.3 清空操作与容量释放策略
清空顺序表clear()有一个容易踩的坑。简单地把size设为0，在逻辑上是可行的，下次插入会覆盖旧值。但这样做有一个隐患：如果当前表里存储的是大批量的对象引用，即使你把size设成了0，底层数组data仍然持有这些对象的强引用，垃圾收集器根本无法回收它们。这又是一处内存泄漏。
正确的做法是遍历数组，把每个位置都赋值为null，然后再把size设为0。如果你用的是Java标准库的ArrayList，它就是这么实现的。如果你自己手写顺序表，千万别图省事只重置size。
那容量要不要在clear的时候收缩？我个人的经验是：如果没有特殊要求，不要收缩。因为clear之后大概率还是会继续使用这个表来存储数据，保持容量不变可以避免下次插入时重新扩容。但如果你的场景是"清空之后这个表还要存活很久，且期间不会存储大量数据"，那手动调用trimToSize把容量缩到和size一样大就是划算的。这个思路和数据库表空间的收缩策略有点类似：高水位不能随便降，频繁升降反而伤性能。
5. 和链表对比：别再只背"数组查快、链表插快"
5.1 两者的本质差异与适用场景
顺序表和链表的对比，是数据结构面试里出现频率最高的题目之一。但很多人给出的答案只停留在"数组随机访问快、链表插入删除快"这个表层，完全没有触及本质。
先看插入删除：链表中间插入节点，确实只需要改两个指针，时间复杂度是O(1)。但前提是你已经持有了那个节点的引用。如果只知道你要在"第5个位置"插入，那你得先遍历链表找到第4个节点，那个查找过程的复杂度是O(n)。而顺序表在中间插入需要移动后续所有元素，同样是O(n)。所以从"按位置插入"这个语义来看，两者的大O复杂度是一致的，只是开销的构成不同：链表花在"找位置"上，顺序表花在"移动元素"上。
但有一个场景顺序表有绝对优势：按下标随机访问。比如你想取第10000个元素，数组直接算个偏移量拿到，O(1)完事。链表呢？你得从head开始next一万次，O(n)跑不掉。这个差异在缓存友好的批量遍历里还会被放大：数组的连续内存天然支持CPU预取，遍历效率极高；链表节点分散在内存各处，每次next都可能触发一次cache miss，惩罚开销非常大。
再看一个很多人忽略的点：内存占用。顺序表每个元素只存数据本身（加上少量预分配的空闲容量），而链表每个节点除了数据还要存至少一个next指针（双向链表还要存prev），这就有额外开销。按最常见的双向链表来算，每个节点多出16字节（两个引用，不考虑压缩指针），1000万个节点的链表，光指针就吃掉160MB内存。这在内存受限的嵌入式或服务端场景下，会是致命的差距。
5.2 实际业务里怎么选
我给一个很落地的选型逻辑，你们可以直接记下来：
- 数据量固定且以读取为主：闭眼选顺序表。
- 频繁在头尾操作：尾部用顺序表没问题，头部频繁插入用
LinkedList或者ArrayDeque。 - 频繁在中间随机位置插入删除：链表的随机访问劣势会导致查找成本很高，此时两者都谈不上高效，你真正该考虑的是跳表或者树结构。
- 需要对已排序数据做范围查询：不能直接用顺序表硬怼，应该配合二分查找或索引。这里就引出一个很经典的话题——索引表的顺序查找。
5.3 索引顺序查找：给顺序表搭一个"目录"
既然提到索引查找，就顺便展开讲讲。顺序表的按值查找是O(n)，数据量大了之后性能不够用。一种经典的优化策略是"索引顺序查找"，也叫分级查找。思路很简单：把数据分成若干块，每一块建立一个索引条目，记录这个块的起始位置和块内最大值（或最小值）。查找时，先用二分法在索引表里定位到目标元素可能所在的块，再在块内做顺序查找。
举个例子，假设有一个长度为1000的有序顺序表，我把它分成10块，每块100个元素。索引表只需要存10个条目的信息。查找一个值时，先在索引表里二分定位到具体哪一块，然后在那100个元素里顺序扫描。最坏情况复杂度是O(n/m + log(m))，其中m是块数。和直接O(n)扫描相比，当n足够大时，性能有明显提升。
网上有个热搜词"索引表的顺序查找"说的就是这个数据结构。这里有个关键点：索引表里的最大值其实就是每一块最后一个元素的值，所以分块时每一块内部可以不用严格全序，但块与块之间必须保持"上一块的最大值小于下一块的最小值"这种有序关系。如果你用顺序表存储的是一个实时变化的数据集，每次插入都要重新维护块边界和索引信息，维护成本很高。所以这个数据结构的适用场景是"数据相对稳定、查询频繁"的业务，典型的就是书籍目录和数据库的稀疏索引。
6. 常见问题与排查技巧实录
6.1 数组越界问题：根源几乎都在边界条件
顺序表最常见的运行时错误就是ArrayIndexOutOfBoundsException。我排查这种问题的经验是：不要只看报错行，要重点检查三处逻辑。第一，插入方法的边界条件判断是index > size还是index >= size——前者允许尾部追加，后者误伤合法操作。第二，删除方法是index >= size还是index > size——注意删除时index不能等于size，因为那是一个空位。第三，遍历操作里用的是i < size还是i < data.length——后者会把空位也遍历进去，导致取到null。
这三处如果写混了，代码可能在大部分数据规模下都跑得好好的，直到某一个临界数据出现才炸。我自己被这种问题坑过几次之后，总结了一个习惯：所有涉及下标的地方，写完之后立刻做一次"最小边界"和"最大边界"的心理测试。比如size=0时执行remove(0)会怎样，size=capacity时执行add()会怎样。这种心理走查在写完一个方法后的10秒钟内就能完成，但能避免无数个调试到深夜的Bug。
6.2 为什么我的顺序表越用越卡
有一种很隐蔽的性能退化：频繁增删导致数组出现大量空洞，但size远小于容量。其实顺序表不存在"逻辑空洞"的玩法，插入删除时元素移动保证了数据始终紧密排列。真正的性能问题出在另一个地方——内存抖动。
场景重现：你的应用高峰期创建了很多顺序表实例，每个实例都调用了扩容。高峰期过后，这些大数组仍然驻留在堆内存里，占着空间不释放。下个高峰期到来时，内存吃紧触发频繁Full GC，整体性能骤降。排查手段很简单：用jmap -histo:live或者MAT看一下堆内存里Object[]的大对象分布，很容易确认是不是顺序表容量爆了。
对应的解法有几种。一是预估初始容量，MyArrayList构造时直接传入大概率的容量上限，避免多次扩容。二是用完即释放，把大对象引用置null，或者调用我前面提到的clear方法手动清空引用。三是如果场景允许，考虑用ArrayList但设置trimToSize把容量收缩回来。说到底顺序表再快也是"大块连续内存"的产物，对象生命周期管理不做好，再好的数据结构也能拖垮整个服务。
6.3 元素迁移时用迭代器会出问题
最后提一个使用层面的经典坑：用Iterator遍历顺序表的同时删元素，会抛出ConcurrentModificationException。原因是迭代器内部维护了一个modCount（修改次数）快照，删除操作会修改这个计数，导致迭代器发现"结构被改动了"立刻罢工。
要安全实现"遍历时删除匹配元素"，有两条路线。一条是用迭代器自身的remove()方法，而不是调用表的remove方法，这样会把modCount同步过来。另一条是用Java 8的removeIf，一行代码搞定，底层就是走的迭代器安全删除，例如：
java复制list.removeIf(item -> item.isExpired());
这条经验虽然不算顺序表专属，但在实际写业务代码时碰到的人特别多。记住：不要在for循环里直接写list.remove(i)，那个反例会写出越界、漏删、并发修改异常三重问题，我见过不止一次。
7. 从顺序表到项目落地：一个完整的业务场景演练
7.1 需求描述：排行榜系统
为了把这些知识串起来，我拿一个很常见的业务需求举例：开发一个轻量级的热门商品排行榜，支持按热度排名，支持实时更新某个商品的排名和热度，支持查询前100名。
用顺序表来设计，最直接的方案是维护一个容量固定100的排行榜数组。score按降序排列，新商品热度变化时，找到它的位置，更新热度后和前一个元素比较，如果热度变高了就往前交换，直到位置正确。这本质上是一个插入排序的变种，因为数据量固定为100，最坏情况下每轮移动100个元素，性能绰绰有余。
java复制public void updateScore(int itemId, int newScore) {
int index = itemIndexMap.get(itemId);
data[index].score = newScore;
while (index > 0 && data[index].score > data[index - 1].score) {
swap(index, index - 1);
itemIndexMap.put(data[index].itemId, index);
itemIndexMap.put(data[index - 1].itemId, index - 1);
index--;
}
}
这里用了一个辅助的HashMap来记录每个商品在数组中的下标，把查找从O(n)降到了O(1)。很多人在设计类似系统时会纠结"怎么在顺序表里快速找到我要更新的元素"，答案往往就是用额外的一个HashMap建立"业务ID到数组下标"的映射关系。这是在数据结构和工程之间做权衡的典型案例：空间换时间，而且收益立竿见影。
7.2 扩容策略在这个场景的取舍
如果排行榜要求支持任意数量的商品参与排名，但只需要展示前100，那么存储结构可以拆成两层：一个HashMap存所有商品的score，另一个容量100的有序顺序表只存前100名的快照。每次更新score时，先更新HashMap，再判断该商品是否值得进入前100，如果值得，就插入有序数组并淘汰最后一名。
这种设计下，有序数组的容量固定为100，永远不会触发扩容。整体性能稳定，内存开销也可控。如果让你直接用顺序表存所有商品并按score排序，每来一个更新你就全表重排，那性能就翻车了。这就是"顺序表虽好，也要看怎么用"的典型体现。
8. 我个人踩过的坑和最后的几条建议
回顾了整个顺序表的实现和各种方法，我最后再说几个自己研究这个主题时的体会。
第一个体会是，学顺序表千万不要只盯着代码本身，要把它放到整个数据结构的坐标系里看。顺序表、链表、跳表、树、哈希表，本质上都是在不同的约束条件下做"数据访问的权衡"。顺序表的灵魂是"连续内存+随机访问"，理解了这一点，你就知道它为什么快，也知道它为什么在插入删除上吃亏，更知道在什么场景下应该放弃它改用别的结构。
第二个体会是，手写一个顺序表是练习基本功的好途径，但生产代码里我强烈建议优先使用标准库的容器，比如Java的ArrayList。除非你有非常明确的性能需求或功能扩展需求，否则自己造的轮子往往在并发、扩容、内存优化等方面远不如经过千万级应用验证的标准实现。手写的主要价值在于学习内部机制，以及在面试时能讲清楚原理。
第三个体会是，边界条件处理是一个人工程素养的真实体现。我面过很多人，能把算法题AC的人不少，但能把remove方法里那个data[--size] = null写出来的人并不多。那些能写出这一行的人，往往是对内存管理有真实理解、踩过线上坑的人。如果你还在学数据结构，我建议你每写一个方法，都追问自己一句：我的操作在边界情况下会怎样？
从顺序表的定义到每一种方法的实现，再到和链表的对比、索引查找的扩展，最后落到排行榜这个实际场景，整个链路其实就是数据结构学习的标准路径：先懂原理，再写代码，再做对比，最后用到业务里。希望这篇梳理能帮你在面试和工程实践中都更有底气。