在Java浩如烟海的集合类库中，Vector算得上是一位资历颇深的“老将”。Ru果你翻开JDK 1.0的源码，会发现它早Yi屹立在那里。然而随着现代Java开发的演进，这位老将似乎逐渐淡出了主流视野，取而代之的是ArrayList和CopyOnWriteArrayList等后起之秀。但不可否认的是Vector在处理多线程并发访问时依然有其独特的教科书般的意义。今天我们就抛开那些枯燥的定义，像拆解一台老式收音机一样，深入剖析Vector究竟是如何实现List的并发访问的，以及为什么它在如今的高并发场景下显得有些“力不从心”。

一、 Vector的“基因”：从定义kan本质

我们要理解Vector的并发机制， 得kan清它的“真面目”。从类的定义上来kan，Vector继承自AbstractList，同时实现了ListRandomAccessCloneable以及java.io.Serializable接口。这kan起来和ArrayList简直像是一个模子里刻出来的，对吧？确实它们在底层数据结构上有着惊人的相似度。

Ru果你点开Vector的源码，Zui引人注目的莫过于那几个核心成员变量：

protected Object elementData;
protected int elementCount;
protected int capacityIncrement;

这里的elementData就是一个对象数组，用来存放真正的数据；elementCount记录了当前数组里实际有多少个元素。这和ArrayList的套路如出一辙。但是请注意那个capacityIncrement，这是Vector特有的一个“私房钱”，它决定了当数组不够用时Vector该扩容多少。不过这并不是我们今天讨论的重点，我们今天的焦点在于——并发。

二、 粗暴而有效的“synchronized”大锁

说到并发，hen多新手程序员可Neng会觉得云里雾里又是CAS又是AQS的。但在Vector那个年代，解决方案简单而直接：synchronized关键字。这就是Vector实现线程安全的全部秘密——没有花哨的技巧，就是一把大锁。

我们Ke以随便翻kan几个Vector的核心方法，比如addremove或者get。你会发现，几乎每一个涉及数据修改或查询的方法，dou无一例外地加上了synchronized修饰符。

让我们来kankanadd方法的源码片段：

public synchronized boolean add {
    modCount++;
    ensureCapacityHelper;
    elementData = e;
    return true;
}

kan到了吗？那个synchronized关键字就像一个尽职尽责的保安，站在方法门口。这意味着什么呢？这意味着在任何时刻，只有一个线程Neng够执行这个add方法。当线程A抢到了锁，它开始往数组里塞数据，此时线程B、C、D只Neng在门外排队等候，直到线程A执行完毕，释放了锁，下一个线程才Neng进来。

同样的逻辑也适用于remove方法：

public synchronized E remove {
    modCount++;
    if 
        throw new ArrayIndexOutOfBoundsException;
    E oldValue = elementData;
    int numMoved = elementCount - index - 1;
    if 
        System.arraycopy(elementData, index+1, elementData, index,
                         numMoved);
    elementData = null; // Let gc do its work
    return oldValue;
}

这种机制被称为“粗粒度锁”。为什么叫粗粒度？因为它锁住了整个方法体，而不是方法中的某一小段代码。这就好比你要上厕所，不管你是进去洗手还是上厕所，只要门锁了别人就进不去。这种Zuo法虽然简单粗暴，容易理解，但也带来了显而易见的性Neng问题。在并发量不高的情况下这当然没问题；可一旦有几十上百个线程同时争抢这把锁，那场面简直就是“堵车”现场，性Neng会呈指数级下降。

三、 迭代器中的“小心机”

除了增删改查，我们在实际开发中经常需要遍历List。这时候，Vector又是如何保证安全的呢？这就不得不提它的iterator方法了。

在Vector中，迭代器的实现稍微有点意思。虽然iterator方法本身也是synchronized的，但它返回的Itr内部类在执行next等操作时也Zuo了一些特殊的处理。

public synchronized Iterator iterator {
    return new Itr;
}

我们再深入kankanItr内部的next方法：

public E next {
    synchronized  {
        checkForComodification;
        int i = cursor;
        if 
            throw new NoSuchElementException;
        cursor = i + 1;
        return elementData;
    }
}

注意到了吗？这里有一个synchronized 代码块。这意味着，即使你拿到的是迭代器，当你调用next去取下一个元素时它依然会去尝试获取Vector实例的对象锁。这种设计确保了在遍历的过程中，Ru果有其他线程试图修改Vector的结构，它们会被挡在门外从而保证了当前遍历操作的数据一致性。

不过这里有个坑。虽然Vector的方法dou加了锁，Ke以防止多线程同时修改导致的数据错乱，但它并不Neng完全杜绝ConcurrentModificationException。为什么？因为虽然Vector保证了操作的原子性，但Ru果你在一个线程中用迭代器遍历，而在另一个线程中直接调用Vector的remove方法，虽然数据不会坏，但迭代器内部的modCount校验机制依然可Neng会抛出异常。这就像是你虽然买了票进了电影院，但Ru果你不按座位坐，管理员还是会赶你走一样。

四、 扩容机制的“自动挡”与“手动挡”

既然聊到了Vector，我们不妨多花点时间聊聊它的扩容，这虽然不属于并发范畴，但却直接影响并发性Neng。前面提到了capacityIncrement这个变量。

当Vector觉得数组满了它就会调用grow方法进行扩容。这时候，capacityIncrement就发挥作用了：

Ru果你在构造函数里指定了capacityIncrement大于0，那么每次扩容，新数组的大小就是 旧容量 + capacityIncrement。这就像手动挡汽车，你想加多少档位你自己说了算。

Ru果你没指定，或者设为0，那Vector就会默认变成“自动挡”，容量直接翻倍。

扩容是一个耗时操作，涉及到Arrays.copyOf或者System.arraycopy，需要把老数组的数据一个个搬到新数组里。在并发环境下Ru果频繁触发扩容，那把大锁锁住的时间就会变长，其他线程等待的时间也就越久。所以Ru果你非要用Vector，Zui好在初始化的时候就给它一个足够大的初始容量，减少扩容带来的性Neng抖动。

五、 为什么Vector成了“时代的眼泪”？

kan到这里你可Neng会问：Vector这么安全，这么简单，为什么现在大家dou不爱用了呢？甚至hen多大厂的规范里直接禁止使用Vector。

原因就在于那个synchronized。

在现代互联网应用中，并发量动辄成千上万。Ru果所有线程dou要排队过这一座独木桥，系统的吞吐量怎么可Neng上得去？这就好比早高峰的地铁站，Ru果只开一个安检口，那队伍Neng排到二环去。这就是所谓的“锁竞争”问题。

为了解决这个问题，Java后续引入了java.util.concurrent包，里面提供了geng高级的并发容器，比如CopyOnWriteArrayList。

CopyOnWriteArrayList的思路就完全不同了。它写操作的时候，会先复制一份整个数组，在副本上修改，修改完之后再替换掉原来的数组引用。在这个过程中，读操作是不需要加锁的，Ke以直接读旧数组。这就实现了读写分离，极大地提高了读多写少场景下的性Neng。相比之下Vector不管你是读还是写，统统dou要加锁，效率自然就低下了。

此外Vector还有一个让人诟病的地方：它不仅锁住了当前线程，还可Neng因为代码逻辑的不当，导致死锁的风险。虽然Vector本身的方法是同步的，但Ru果你在业务代码中混合使用了Vector和其他同步块，锁的层级一旦复杂起来维护起来简直就是噩梦。

六、 ：Vector的启示

回过头来我们再kanVector。它是一个失败的产物吗？也不尽然。或者在一些对性Neng要求不高的遗留系统中，Vector提供了一种开箱即用的线程安全方案，极大地降低了开发者的心智负担。你不需要懂什么volatile，也不需要懂什么CAS，只要用Vector，数据就不会乱。

但是技术是不断进步的。Vector用一种极其保守的方式实现了并发安全，牺牲了性Neng换取了安全。而在今天我们有geng多、geng优雅的工具来平衡性Neng与安全，比如ConcurrentHashMapCopyOnWriteArrayList等等。

所以理解Vector如何实现并发访问，不仅仅是为了去维护那些老旧的代码，geng是为了理解Java并发编程的演变史。它告诉我们，synchronized虽然好用，但不可滥用；在追求线程安全的道路上，锁的粒度、读写分离的策略dou是我们需要深思熟虑的问题。

下次当你再kan到Vector的时候，不妨对这位老将多一份敬意，但在写新代码时还是请把它留在记忆的博物馆里吧。毕竟谁会愿意在高铁时代还去坐蒸汽火车呢？除非，你真的只是为了欣赏沿途的风景。

---