深入理解顺序表：从ArrayList源码到手写实现与实战对比

前阵子有个读者私信我，问了个挺有代表性的问题：数组都用了这么多年，add、remove用得不顺心，到底该不该自己封装一个？我当时回了一句：你先去把ArrayList源码读三遍，读完了再决定。这个问题的本质，其实是数据结构与算法里最基础也最容易被低估的一类结构——线性表。今天这篇第5篇，我们就来聊聊线性表的第一种存储形态：顺序表，也就是Java里ArrayList的底层实现。

这篇内容适合正在学数据结构与算法的学生、准备面试的开发者，以及想真正把代码写明白的初级工程师。你会看到三样东西：顺序表为什么存在、ArrayList的扩容机制到底在做什么、以及我手写一个可用的顺序表并拿它到实际场景里跑一遍。我把源码、手写实现和踩坑经验都放在一起，照着敲一遍，比死记八遍定义都有用。

1. 为什么数组这么好用，我们还需要"顺序表"这层壳子

1.1 数组的三大痛点：容量不可变、插入删除移动、语义缺失

每一位写过数组的人，早晚都会撞上这三个问题。

第一，数组长度在创建时就定死了。我早期写过一段库存管理代码，预估1000条记录，结果活动上线后直接冲到10万条，数组越界、数据写不进去，只能重启加参数。这种"容量不可变"是所有定长结构的通病，而现实业务的数据量几乎不可能提前精确预估。

第二，中间插入和删除太费劲。数组在内存里是连续的一段空间，你想在下标2的位置插入一个新元素，下标2及其后面的所有元素都得往后挪一位；删除同理，后面元素全要往前补位。一次插入的时间复杂度是O(n)，如果插入频繁，整体性能肉眼可见地往下掉。

第三，数组本身不携带"当前有多少个有效元素"这个语义。你定义了一个int[100]，但真实数据可能只有37个，你得自己维护一个size变量，每次增删都手动更新，漏一次程序就崩。这个错误非常隐蔽，查起来又非常耗时。

所以数组是一种"最底层的存储工具"，但离"业务可用的数据结构"还差一层封装。顺序表就是在这层封装上长出来的东西。

1.2 顺序表的定义：逻辑相邻和物理相邻的统一

顺序表是线性表的一种存储结构。线性表强调"元素之间是一对一的线性关系"，有且仅有一个头元素和一个尾元素，除了头尾，每个元素都有唯一的前驱和后继。顺序表在物理存储上也保持这种相邻关系：用一段地址连续的存储单元，依次存放线性表中的数据元素。

用大白话说，顺序表 = 数组 + 当前长度。数组负责底层存储，一个size变量负责记录有效元素个数。两者结合，就同时解决了"容量固定"的一部分问题（通过扩容）和"不知道有多少元素"的语义问题。

在Java的集合框架里，ArrayList就是顺序表的标准实现。你平时用的list.add(e)、list.get(i)，本质都是在操作一个会自动扩容的数组。理解了顺序表，你就能理解ArrayList一半以上的源码逻辑。

1.3 线性表的分类账：顺序表与链表的分工

学习这块内容时，最忌讳的一件事就是只记结论不记场景。顺序表和链表是线性表的两种实现路线，我见过太多人纠结"哪个更好"，实际上它们是分工关系，不是替代关系。

顺序表的优势是随机访问：get(i)直接通过首地址加偏移量算出位置，时间复杂度O(1)。链表的优势是插入删除：只要找到节点，修改指针就行，时间复杂度O(1)。但如果只看"插入"这个操作在真实代码里的表现，链表不一定更快，因为查找节点本身是O(n)，如果你用LinkedList在中间插入，找位置的时间就吞掉了指针修改的收益。

Java里还有一个很反直觉的点：LinkedList的节点内存不连续，每个节点还要额外存储前后指针，内存开销远大于ArrayList；而ArrayList虽然扩容时会浪费一部分容量，但在遍历时对CPU缓存更友好。所以在绝大多数实际业务里，ArrayList的表现反而比LinkedList好。后面我会专门用一节讲顺序表和链表的对比，这里先记住：默认选顺序表，除非你有非常明确的频繁头插需求。

2. 从ArrayList源码看顺序表的底层设计与扩容博弈

2.1 字段与构造：空数组与懒加载

打开Java 8的ArrayList源码，核心字段只有两个：

java复制transient Object[] elementData;
private int size;

elementData是真正存数据的数组，size是有效元素个数。构造方法里有个很有意思的细节：你调用new ArrayList<>()时，它并没有直接创建一个容量为10的数组，而是把elementData指向一个空的DEFAULTCAPACITY_EMPTY_ELEMENTDATA：

java复制public ArrayList() {
    this.elementData = DEFAULTCAPACITY_EMPTY_ELEMENTDATA;
}

这就是"懒加载"。只有第一次add元素时，容量才会真正扩大到10。这么做的原因很朴素：很多ArrayList对象创建后根本不存数据，没必要提前占内存。

提示：如果你已经明确知道大概会有多少条数据，直接写new ArrayList<>(expectedSize)可以省去后续多次扩容的复制开销。这个优化在数据量大时非常明显。

2.2 add方法的完整链路与扩容时机

看一下add方法的核心路径：

java复制public boolean add(E e) {
    ensureCapacityInternal(size + 1);
    elementData[size++] = e;
    return true;
}

关键在于ensureCapacityInternal，它判断size + 1是否超过当前数组长度，如果超过就触发grow。grow方法长这样：

java复制private void grow(int minCapacity) {
    int oldCapacity = elementData.length;
    int newCapacity = oldCapacity + (oldCapacity >> 1);
    if (newCapacity - minCapacity < 0)
        newCapacity = minCapacity;
    if (newCapacity - MAX_ARRAY_SIZE > 0)
        newCapacity = hugeCapacity(minCapacity);
    elementData = Arrays.copyOf(elementData, newCapacity);
}

oldCapacity >> 1是右移一位，相当于除以2。所以新容量 = 旧容量 + 旧容量/2，也就是原来容量的1.5倍。然后Arrays.copyOf会创建一个新数组，把旧数组的所有元素搬过去，再让elementData指向新数组。

这段逻辑里有个容易忽略的点：如果当前容量是0（比如空数组第一次add），oldCapacity + (oldCapacity >> 1)算出来还是0，所以代码里有个兜底判断newCapacity - minCapacity < 0。第一次add的minCapacity是10（由ensureCapacityInternal里的逻辑补足），最终扩容结果就是10。

2.3 为什么扩容要选1.5倍而不是2倍

这是面试里被问烂了的问题，但很多人只记住了"1.5倍"这个结论，说不清背后的动机。

先说结论：1.5倍是"空间利用率"和"扩容频率"之间的折中。

如果把容量从1每次加1，插入N个元素需要扩容N次，每次都要复制旧数组，总复制次数是1+2+...+N，复杂度O(n²)，不可接受。所以必须采用指数扩容。

如果指数基数是2，比如Java的HashMap，负载因子0.75的情况下容量翻倍。扩容次数少，均摊下来的复制开销低，但缺点是每次扩容后都可能浪费较多空间。假设容量从16扩到32，新增的16个槽位可能只有三四个被使用。

ArrayList选择1.5倍，扩容次数比2倍多一些，但每次扩容后多出来的空间更接近实际需求，内存浪费更小。用等比数列算一下也能发现：以初始容量1、每次扩容1.5倍为例，最终容量为N时，历史复制总次数近似在2N左右，均摊到每次add仍然是个常数。也就是说，尾部追加的均摊时间复杂度是O(1)。

2.4 删除操作：搬移元素与缩容边界

再看remove方法：

java复制public E remove(int index) {
    rangeCheck(index);
    modCount++;
    E oldValue = elementData(index);
    int numMoved = size - index - 1;
    if (numMoved > 0)
        System.arraycopy(elementData, index+1, elementData, index, numMoved);
    elementData[--size] = null;
    return oldValue;
}

删除的代价集中在System.arraycopy上：把index后面的所有元素整体前移一位。如果删的是最后一个元素，numMoved = 0，不需要搬移，所以remove(size-1)是O(1)；删头部元素则是最坏情况O(n)。

还有一个很多人不知道的点：ArrayList删除元素后并不会自动缩容。比如你一次性add了100万个元素再清空，底层数组依然占用着100万个对象引用的空间。如果想释放内存，需要手动调用trimToSize()。这一点在内存敏感的场景里非常关键。

3. 手写一个可用的顺序表MyArrayList

3.1 类骨架与字段定义

看再多元码不如自己写一遍。我从头手写一个简化版顺序表，不求覆盖ArrayList全部功能，但核心的增删改查、扩容、缩容、迭代器都包含。先定义骨架：

java复制public class MyArrayList<E> {
    private Object[] data;
    private int size;
    private static final int DEFAULT_CAPACITY = 10;

    public MyArrayList() {
        data = new Object[DEFAULT_CAPACITY];
    }

    public MyArrayList(int initialCapacity) {
        if (initialCapacity < 0) {
            throw new IllegalArgumentException("Illegal Capacity: " + initialCapacity);
        }
        data = new Object[initialCapacity];
    }
}

用Object数组存储，是因为泛型在运行时会被擦除，不能直接new E[]。这跟ArrayList源码里用Object[] elementData是同一个原因。对外暴露方法时再做强转。

3.2 增删改查与边界检查

核心的四个方法，我建议你背下来，它们几乎覆盖了顺序表的所有本质操作：

java复制public boolean add(E item) {
    ensureCapacity(size + 1);
    data[size++] = item;
    return true;
}

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

public E get(int index) {
    checkIndex(index);
    return (E) data[index];
}

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

checkIndex和checkIndexForAdd的差别在于：add方法允许index == size（相当于尾部追加），remove和get不允许。边界判断是顺序表最容易出错的地方，比如remove(size)和add(size+1, item)都必须抛异常。这个细节在面试手写代码时非常加分。

System.arraycopy是native方法，底层是内存块拷贝，比for循环逐元素复制快很多。学习阶段建议手写for循环理解逻辑，项目代码里直接用System.arraycopy。

3.3 动态扩容与缩容实现

扩容逻辑我按照ArrayList的1.5倍思路来实现：

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

缩容也实现一个方法，等真正有需要时再调用：

java复制public void trimToSize() {
    if (size < data.length) {
        data = Arrays.copyOf(data, size);
    }
}

这里有两点值得说。第一，扩容是"当需要的容量超过当前容量时"才触发，而不是每次add都触发，否则性能会完全不可用。第二，Arrays.copyOf一次调用完成创建新数组和复制两个动作，代码简洁，性能也不差。

如果你想要更精确地控制容量，还可以实现一个ensureCapacity(int minCapacity)的public版本，让外部在批量插入前主动扩容。这个习惯能显著减少自动扩容次数。

3.4 泛型与迭代器改造

泛型版本的MyArrayList已经能存任意类型对象了，但还不能用for-each遍历。我给这个类加一个简单的迭代器：

java复制public Iterator<E> iterator() {
    return new Itr();
}

private class Itr implements Iterator<E> {
    private int cursor = 0;
    private int expectedModCount = modCount;

    @Override
    public boolean hasNext() {
        return cursor < size;
    }

    @Override
    public E next() {
        checkForComodification();
        if (cursor >= size) {
            throw new NoSuchElementException();
        }
        return (E) data[cursor++];
    }
}

这里引入了modCount。它的作用是记录结构修改次数，add、remove都会让modCount自增。迭代器在自己的expectedModCount上做快照，只要发现modCount != expectedModCount，就抛ConcurrentModificationException，防止在迭代过程中出现不一致。

这就是Java集合框架里著名的fail-fast机制。很多线上bug的根源就是一边遍历一边删除，迭代器察觉到变化后直接报错。理解了modCount，你再看那些"ConcurrentModificationException"的报错，就不会慌了。

4. 实测对比与生产环境踩过的坑

4.1 顺序表vs链表：一份直观的基准测试

我写代码时有个习惯：不迷信理论结论，直接跑数据。用同样10万条数据，分别测试尾部追加、按下标访问、头部插入这三个操作，结果非常直观：

尾部追加时LinkedList为什么不如ArrayList？因为LinkedList每次addLast虽然只改指针，但每个新节点都要new一个Node对象，频繁创建小对象有开销；ArrayList的数组在扩容复制时虽然要搬移，但均摊后很便宜。

按下标访问的差距就离谱了。ArrayList的get(i)直接算地址，LinkedList要从头遍历到i位置，访问复杂度O(n)。这个性能差距在真实业务里是数量级的。

只有头部插入或者中部插入时，LinkedList才体现出理论优势。所以"顺序表和链表哪个好"这个问题，正确答案永远是：看场景、看数据、看实测。

4.2 遍历时删除元素：一个经典的失误

这段代码我见过无数人写过，包括当年我自己：

java复制// 错误示范
for (int i = 0; i < list.size(); i++) {
    if (list.get(i) % 2 == 0) {
        list.remove(i);
    }
}

问题出在哪？假设list为[1, 2, 3, 4]，i=1时删掉2，数组变成[1, 3, 4]，此时i自增为2，直接跳过了3。连续偶数元素时会漏删。

正确做法有三种：

java复制// 方式一：倒序遍历
for (int i = list.size() - 1; i >= 0; i--) {
    if (list.get(i) % 2 == 0) {
        list.remove(i);
    }
}

// 方式二：迭代器删除
Iterator<Integer> it = list.iterator();
while (it.hasNext()) {
    if (it.next() % 2 == 0) {
        it.remove();
    }
}

// 方式三:Java 8
list.removeIf(x -> x % 2 == 0);

倒序遍历的思路很巧妙：删除后面的元素不会影响前面元素的下标，所以可以从尾部往前删。迭代器方式则是通过它内部的remove方法，先把游标回退一步再删，避免了索引错位。实测下来，数据量大时removeIf最简洁，性能也是最优的。

4.3 批量插入与缩容陷阱

批量插入时如果不预判容量，ArrayList会多次扩容，每次扩容都复制一次全量数据。假设要插入100万条数据，默认从10开始，1.5倍扩容，最终要扩容几十次，复制总量接近最终容量的几倍。

解决方案是在插入前调ensureCapacity：

java复制List<Integer> bigList = new ArrayList<>(1000000);
// 或者
ArrayList<Integer> list = new ArrayList<>();
list.ensureCapacity(1000000);
for (int i = 0; i < 1000000; i++) {
    list.add(i);
}

缩容陷阱则相反：有些人图省事，用list = new ArrayList<>(existingList)来"清理"原列表，但如果原列表后续还会复用，这种写法等于把引用都换掉了，极易引起共享状态bug。正确的清理方式是list.clear()，它会把数组里的引用全部置为null，size归零，但底层数组保留，下次add不会立刻扩容。

4.4 subList相关的隐蔽问题

另一个我线上遇到过的坑是subList。很多人以为subList返回的是一个独立的新List，其实它返回的是原List的一个视图：

java复制List<Integer> list = new ArrayList<>(Arrays.asList(1, 2, 3, 4, 5));
List<Integer> sub = list.subList(1, 3);
sub.add(99);
System.out.println(list); // [1, 2, 3, 99, 4, 5]，原列表被改了

如果subList创建后，原list发生了结构修改（add或remove），再操作subList会抛ConcurrentModificationException。这正是modCount机制的延伸。所以subList适合只读场景，如果你想得到独立副本，老老实实复制一份new ArrayList<>(list.subList(1, 3))。

5. 顺序表的经典应用场景：从洗牌算法到LRU缓存雏形

5.1 什么场景优先选顺序表

判断标准其实很简单，我总结成五条：

• 你主要按下标访问元素，读多写少
• 数据追加发生在尾部，偶尔删除尾部
• 数据规模大致可预估，或增长比较平稳
• 你需要频繁遍历整个集合，对CPU缓存局部性有要求
• 你对内存占用敏感，希望省掉链表节点的指针开销

反之，如果有大量中间插入删除、元素节点本身很庞大、数据结构是典型的生产者消费者队列，那就不要硬用顺序表，LinkedList或队列实现更合适。

5.2 案例一：基于顺序表的洗牌与抽奖逻辑

抽奖系统里经常要洗牌。最经典的算法是Fisher-Yates，从后往前遍历数组，每次随机选一个位置交换。用我们的MyArrayList实现如下：

java复制public void shuffle() {
    Random random = new Random();
    for (int i = size - 1; i > 0; i--) {
        int j = random.nextInt(i + 1);
        swap(i, j);
    }
}

private void swap(int i, int j) {
    Object tmp = data[i];
    data[i] = data[j];
    data[j] = tmp;
}

这个算法的精妙之处在于：每个元素最终出现在任意位置的概率都是1/n，所有排列等概率。它是顺序表"按下标随机访问O(1)"特性的典型应用。如果用链表写洗牌，每次swap都要先遍历找到节点，性能直接掉一个量级。

5.3 案例二：LRU缓存的一个朴素版本

LRU（最近最少使用）缓存，核心思想是：当缓存满时，淘汰最久没被访问的数据。用顺序表实现一个朴素版本非常直观：

java复制public class LRUCache {
    private final ArrayList<Integer> cache;
    private final int capacity;

    public LRUCache(int capacity) {
        this.capacity = capacity;
        this.cache = new ArrayList<>(capacity);
    }

    public void access(int key) {
        int index = cache.indexOf(key);
        if (index >= 0) {
            cache.remove(index);
        } else if (cache.size() >= capacity) {
            cache.remove(0);
        }
        cache.add(key);
    }
}

每次访问时，把key移动到列表末尾，这样列表头部永远是最久未使用的。满员时删除头部，新数据加到尾部。这个实现的所有操作都是O(n)，数据量小完全够用。

但数据量大了以后就不行了。生产级的LRU应该用HashMap + 双向链表，让查找和删除都变成O(1)。这里用顺序表实现，是为了让你直观理解LRU的语义，而不是真的让你在线上代码里这么写。

5.4 案例三：有序集合合并与去重

假设有两个有序列表，需要合并成一个仍然有序的列表，这是归并排序的merge过程。用顺序表做这个事情非常自然：

java复制public static List<Integer> mergeSortedLists(List<Integer> a, List<Integer> b) {
    ArrayList<Integer> result = new ArrayList<>(a.size() + b.size());
    int i = 0, j = 0;
    while (i < a.size() && j < b.size()) {
        if (a.get(i) <= b.get(j)) {
            result.add(a.get(i++));
        } else {
            result.add(b.get(j++));
        }
    }
    while (i < a.size()) result.add(a.get(i++));
    while (j < b.size()) result.add(b.get(j++));
    return result;
}

在初始化时直接指定容量a.size() + b.size()，全程不会触发扩容。合并完成后如果还有剩余元素，直接批量追加。整个过程时间复杂度O(n+m)，同时利用顺序表随机访问的优势，代码简洁且不易出错。

我在实际做数据同步时，也经常会用类似思路做两个增量集合的合并去重：先排序再合并，最后判断相邻元素是否相等来去重，整个过程用顺序表内存连续的优势，遍历速度非常快。

最后补充一个我踩过的线上细节

写到这里，我想把一次真实的排查经历分享出来。去年我维护一个数据任务，往ArrayList里不断add，客户反馈内存增长异常。一开始怀疑是数据量太大，后来dump内存发现，ArrayList底层数组明明已经被清空了，但容量还占着几百兆。问题根源是业务代码里用了list = new ArrayList<>()来替代clear()，旧数组对象没有被及时回收，而新列表又继续扩容，双份内存叠加。

从那以后，我养成了两个习惯：第一，明确知道列表会长期复用时，用clear()而不是重新new；第二，大规模批量数据入库后，如果短时间内不再写入，手动trimToSize()释放多余容量。这些细节不会写进教科书，但恰恰是生产环境最真实的教训。顺序表不难，难的是把它的底层逻辑吃透，再在合适的场景里选对方案。建议你把源码读一遍、demo写一遍、上面的坑自己复现一遍，这一章才算真正过了。