Java Vector

java.util.Vector<E> is the thread-safe, synchronised version of ArrayList that Java shipped in version 1.0 — long before the Collections Framework, long before generics, and long before the java.util.concurrent package existed. Every method in Vector acquires the same object-level lock before executing. That single design decision is both its historical strength and its modern liability: it was the safest option available in 1996, and it is one of the least efficient options available today.

Understanding Vector is still required for two reasons: it appears constantly in technical interviews as a contrast to ArrayList, and it is widespread in legacy codebases that predate Java 5.

What Is Java Vector?

Vector<E> is a concrete class in java.util that implements List<E>. Internally it is a resizable array — identical to ArrayList in how it stores and accesses elements. The difference is that every public method in Vector is declared synchronized, which means every call acquires the intrinsic lock on the Vector instance before executing.

java.lang.Iterable<E>
    └── java.util.Collection<E>
            └── java.util.List<E>
                    └── java.util.AbstractList<E>
                            ├── java.util.ArrayList<E>   ← NOT synchronised
                            └── java.util.Vector<E>      ← THIS CLASS
                                    └── java.util.Stack<E> ← subclass of Vector

KEY FACTS:
  Package          : java.util
  Since            : Java 1.0  (predates Collections Framework — Java 1.2)
  Implements       : List<E>, RandomAccess, Cloneable, Serializable
  Backing structure: Object[] elementData (same as ArrayList)
  Synchronisation  : YES — every public method is synchronized
  Null elements    : allowed
  Duplicates       : allowed
  Ordering         : insertion order (same as ArrayList)
  Legacy API       : Enumeration<E>, addElement(), elementAt(), removeElement()
  Default capacity : 10 elements (same as ArrayList)
  Capacity growth  : doubles by default (ArrayList grows by 50%)
  Status           : LEGACY — avoid in new code

Basic Overview — The Full Vector API

VECTOR METHOD REFERENCE:

  LIST INTERFACE METHODS (all synchronised in Vector):
    add(element)             addAll(collection)
    add(index, element)      addAll(index, collection)
    get(index)               set(index, element)
    remove(index)            remove(object)
    contains(object)         containsAll(collection)
    size()                   isEmpty()
    indexOf(object)          lastIndexOf(object)
    iterator()               listIterator()
    subList(from, to)        toArray()

  VECTOR-SPECIFIC LEGACY METHODS (pre-Collections Framework):
    addElement(E obj)        ← same as add(obj)
    insertElementAt(E, int)  ← same as add(index, element)
    setElementAt(E, int)     ← same as set(index, element)
    removeElement(Object)    ← same as remove(Object), returns boolean
    removeElementAt(int)     ← same as remove(int index)
    removeAllElements()      ← same as clear()
    elementAt(int index)     ← same as get(index)
    firstElement()           ← same as get(0)
    lastElement()            ← same as get(size()-1)
    elements()               ← returns Enumeration<E> (legacy iterator)
    copyInto(Object[] array) ← same as toArray(array)

  CAPACITY MANAGEMENT (Vector-specific):
    capacity()               ← current allocated array size (not element count)
    ensureCapacity(int min)  ← grow to at least min if needed
    setSize(int newSize)     ← resize logical size (fills with null if growing)
    trimToSize()             ← shrink array to match current element count

GROWTH STRATEGY:
  capacityIncrement > 0  →  grows by capacityIncrement each resize
  capacityIncrement == 0 →  doubles current capacity (default)
  ArrayList always grows by 50% (approximately)

  new Vector<>()             → capacity 10, increment 0 (doubles)
  new Vector<>(20)           → capacity 20, increment 0 (doubles)
  new Vector<>(20, 5)        → capacity 20, increment 5 (adds 5 each time)

When to Use Vector

DO NOT USE Vector IN NEW CODE.

The Java documentation and every major Java style guide recommend
against new Vector usage. Here is why:

PROBLEM 1 — Global lock kills concurrency:
  Every method in Vector acquires the lock on the Vector object.
  This means 100 reader threads calling get() simultaneously
  execute one at a time — 99 wait while 1 reads.
  CopyOnWriteArrayList reads with NO lock at all.

PROBLEM 2 — Synchronisation does not prevent compound races:
  Even with Vector, this code has a race condition:
    if (!vector.isEmpty()) {   // Thread 1 checks here
      E elem = vector.get(0);  // Thread 2 removes here — IndexOutOfBoundsException!
    }
  The two operations are separately atomic but the compound
  check-then-act is NOT atomic. External locking still needed.

PROBLEM 3 — Enumeration is obsolete:
  vector.elements() returns an Enumeration — a pre-Iterator API
  from Java 1.0. Enumeration lacks the remove() operation and is
  verbose compared to Iterator or for-each.

WHEN Vector IS ENCOUNTERED:
  - Maintaining legacy codebases (pre-Java 5)
  - Subclassed by java.util.Stack (which is also legacy)
  - Third-party library APIs that predate Collections Framework

MODERN ALTERNATIVES:
  Single-threaded List         → ArrayList (no lock overhead)
  Read-heavy concurrent List   → CopyOnWriteArrayList (lock-free reads)
  Write-heavy concurrent List  → Collections.synchronizedList(new ArrayList<>())
                                 + explicit synchronized block for iteration
  Thread-safe stack            → ArrayDeque (push/pop without global lock)

How Vector Works Internally

BACKING STRUCTURE — identical to ArrayList:
  protected Object[] elementData;   ← the array holding elements
  protected int elementCount;        ← logical size (number of elements)
  protected int capacityIncrement;   ← growth step (0 = double)

  NOTE: these fields are protected, not private.
  Direct subclassing and field access is possible — another legacy design.

SYNCHRONISATION MECHANISM:
  Every public method has the synchronized keyword:
    public synchronized boolean add(E e) { ... }
    public synchronized E get(int index)  { ... }
    public synchronized E remove(int index) { ... }
    public synchronized void clear()      { ... }

  This means: the intrinsic monitor lock on the Vector INSTANCE
  is acquired before every method call and released after.

  CONSEQUENCE 1: Only one thread can execute any Vector method at a time.
  CONSEQUENCE 2: Reads and writes compete for the same lock — readers
    block other readers (unlike ReadWriteLock where reads are concurrent).
  CONSEQUENCE 3: Compound operations are still NOT atomic:
    if (!vector.isEmpty()) {       // lock acquired, released
        value = vector.get(0);     // lock acquired again — window for race
    }

RESIZE BEHAVIOUR:
  When elementCount == elementData.length and a new element is added:
  if (capacityIncrement > 0)
      newCapacity = oldCapacity + capacityIncrement;  // fixed increment
  else
      newCapacity = oldCapacity * 2;                  // double (default)

  ArrayList grows to: oldCapacity + (oldCapacity >> 1) ≈ 1.5× (50%)
  Vector doubles:     oldCapacity * 2                 = 2× (100%)
  Vector wastes more memory than ArrayList on average.

Core Operations with Examples

Basic Operations — Same as ArrayList, With Lock Overhead

Output:
=== List interface methods (synchronised) ===
Vector  : [Mumbai, Delhi, Bengaluru, Chennai, Hyderabad]
size()  : 5
get(2)  : Bengaluru
contains(Delhi): true
After set(1, Pune): [Mumbai, Pune, Bengaluru, Chennai, Hyderabad]
After remove(Chennai): [Mumbai, Pune, Bengaluru, Hyderabad]

=== Legacy Vector methods ===
After addElement and insertElementAt: [10, 15, 20, 30]
elementAt(0)   : 10
firstElement() : 10
lastElement()  : 30
After removeElement(15): [10, 20, 30]
After removeElementAt(0): [20, 30]

=== Enumeration (legacy iteration) ===
Enumeration: Spring Hibernate Struts JSF
for-each   : Spring Hibernate Struts JSF

Capacity Management — Vector-Specific Behaviour

Output:
=== Default capacity behaviour (doubles) ===
Initial capacity : 10
After 15 adds, capacity : 20
After 15 adds, size     : 15

=== Fixed increment capacity (grows by 3) ===
Initial capacity: 5
At 5 elements, capacity: 5
After 6th element, capacity: 8

=== trimToSize() ===
Before trim — capacity: 50  size: 5
After trim  — capacity: 5   size: 5

=== setSize() ===
Before setSize(5): [Java, Spring, Kafka] size=3
After setSize(5) : [Java, Spring, Kafka, null, null] size=5
After setSize(2) : [Java, Spring] size=2

Vector vs ArrayList — The Lock Overhead in Practice

Output:
=== Single-threaded performance (1,000,000 adds) ===
Vector    add time: 38 ms
ArrayList add time: 12 ms
Vector overhead   : 3.2x slower (lock acquisition per call)

=== Compound operations are still NOT atomic ===
Vector.isEmpty() and Vector.get() are each synchronised
but the CHECK-THEN-ACT compound is NOT atomic.
External locking still required for compound operations.

=== Modern thread-safe alternatives ===
Collections.synchronizedList: global lock, same as Vector
CopyOnWriteArrayList        : lock-free reads, O(n) writes
Recommendation              : neither Vector nor synced wrapper
                              for new code — use COWAL or CHM

Real-World Example — Migrating Legacy Vector Code to Modern Collections

A Java EE application at a legacy enterprise system used Vector throughout for its service layer. Upgrading it to modern equivalents improves throughput by eliminating unnecessary synchronisation in single-threaded paths and replacing global-lock patterns with purpose-built concurrent collections in multi-threaded paths. The migration follows a clear decision tree.

Output:
MIGRATION DECISION GUIDE:
  Single-threaded  → ArrayList
  Read-heavy multi → CopyOnWriteArrayList
  Balanced multi   → synchronizedList(ArrayList)
  Stack semantics  → ArrayDeque (push/pop)

=== Legacy → Modern migration ===
First order: ORD-001
All orders: ORD-001 ORD-002 ORD-003
After clear: size=0

=== Correct iteration on synchronizedList ===
  Processing: order-A
  Processing: order-B

Performance Considerations

Vector's lock overhead in single-threaded code. In a single-threaded context — the majority of service code — every Vector method call acquires and releases a lock that nobody else will ever try to acquire. This adds constant overhead per operation. Benchmarks typically show Vector running 2-4x slower than ArrayList for equivalent single-threaded workloads. The lock acquisition itself is the bottleneck, not the array operation.

Capacity doubling wastes memory. When Vector resizes, it doubles its backing array. ArrayList grows by approximately 50%. A Vector that grew to hold 10,001 elements has a backing array of 16,384 slots. The equivalent ArrayList has a backing array of approximately 15,001 slots. Over time, Vector's growth strategy wastes measurably more memory.

Best Practices

Replace Vector with ArrayList in all new single-threaded code without hesitation. The only reason Vector exists is backward compatibility. The Java documentation itself does not recommend it for new code. Every Vector field in a new class is a synchronisation cost with zero concurrent benefit in single-threaded contexts. IDE refactors make this a one-line change.

When migrating legacy code, map each legacy method to its modern equivalent systematically. addElement() → add(), elementAt() → get(), firstElement() → get(0), lastElement() → get(size()-1), removeAllElements() → clear(), elements() → iterator() or for-each. Work through the class method by method with a find-replace for common patterns. Automated tools like IntelliJ's "Replace Vector with ArrayList" refactoring handle most cases.

For thread-safe list requirements in new code, choose based on read-write ratio. Read-heavy with rare writes: CopyOnWriteArrayList — lock-free reads, O(n) writes, no CME during iteration. Balanced or write-heavy: Collections.synchronizedList(new ArrayList<>()) — global lock, but remember that iteration requires an explicit synchronized block. High concurrency with complex operations: consider a ConcurrentHashMap keyed by index or a purpose-built concurrent data structure.

If Stack semantics are needed (LIFO), use ArrayDeque, not Stack or Vector. java.util.Stack extends Vector, inheriting all its global-lock overhead plus the semantic problems of exposing index-based operations on what should be a pure LIFO structure. ArrayDeque.push(), pop(), and peek() are O(1) amortised, zero synchronisation, and semantically clean.

Common Mistakes

Mistake 1 — Using Vector for Thread Safety Without Understanding Its Limits

Mistake 2 — Using Legacy Enumeration When Iterator or For-Each Is Available

Mistake 3 — Using Vector's capacityIncrement Without Understanding the Impact

Mistake 4 — Declaring New Fields as Vector Instead of List

Interview Questions

Q1. What is Vector in Java and why is it considered legacy?

Vector<E> is a List implementation from Java 1.0 that stores elements in a resizable array — identical in structure to ArrayList. Every public method in Vector is declared synchronized, meaning it acquires the object's intrinsic lock before executing. It is considered legacy for three reasons: its synchronisation prevents concurrent reads, adding overhead even in single-threaded code; per-method synchronisation does not protect compound check-then-act operations; and its legacy API (addElement(), elements(), firstElement()) predates the Collections Framework. ArrayList replaces it for single-threaded use, and CopyOnWriteArrayList or Collections.synchronizedList() replace it for concurrent use.

Q2. What is the difference between Vector and ArrayList?

Both are resizable-array List implementations. Vector synchronises every method with a global lock — all reads and writes serialise through the same mutex. ArrayList has no synchronisation — it is faster in single-threaded code but unsafe if shared between threads. Vector doubles its capacity on resize; ArrayList grows by approximately 50%. Vector provides legacy methods (addElement(), elementAt(), elements()) from before the Collections Framework; ArrayList provides only the standard List interface. Vector has been in Java since 1.0; ArrayList was introduced in Java 1.2. For new code, ArrayList is always preferred over Vector.

Q3. Does using Vector guarantee thread safety for all operations?

No — not completely. Individual method calls on Vector are each atomically synchronised, but compound operations are not. if (!vector.isEmpty()) { value = vector.get(0); } is a race condition: another thread can remove all elements between the isEmpty() and get(0) calls, causing IndexOutOfBoundsException. Thread-safe individual method calls do not make sequences of method calls atomic. For compound operations, external synchronized(vector) blocks are still required — the same requirement as Collections.synchronizedList().

Q4. What is the difference between Vector and Collections.synchronizedList()?

Both provide a globally-locked List. Vector synchronises methods as part of its class definition — every concrete method body has synchronized. Collections.synchronizedList() wraps any existing List with a proxy that synchronises each method call on the wrapper object. The functional behaviour is essentially equivalent. The practical difference: synchronizedList() can wrap any List, including ArrayList with its better growth strategy. Both require external synchronisation for iteration. For new code where thread-safe list is genuinely needed, CopyOnWriteArrayList (read-heavy) or an explicit ReentrantLock with ArrayList (write-heavy) are better choices.

Q5. What is the Enumeration interface and how does it relate to Vector?

Enumeration<E> is a pre-Collections Framework (Java 1.0) iteration API with two methods: hasMoreElements() and nextElement(). Vector.elements() returns an Enumeration<E> over the vector's elements. Enumeration lacks the remove() method that Iterator provides and is more verbose. It is the predecessor to Iterator<E> (introduced in Java 1.2). Modern code uses for-each, Iterator, or Stream for traversal. Enumeration still appears in legacy code and some older Java EE APIs.

Q6. How does Vector's capacity growth differ from ArrayList's?

Vector doubles its backing array by default when a resize is needed: newCapacity = oldCapacity × 2. If a capacityIncrement was specified at construction, it adds that fixed amount instead: newCapacity = oldCapacity + capacityIncrement. ArrayList grows by approximately 50%: newCapacity = oldCapacity + (oldCapacity >>> 1). Doubling wastes more memory on average — a Vector that grew from 8 to 16 has 8 empty slots; ArrayList would have approximately 4. Pre-sizing avoids this for both: new Vector<>(expectedSize) or new ArrayList<>(expectedSize).

FAQs

Should I ever use Vector in new Java code?

No. The Java documentation states that ArrayList should be used in place of Vector for non-synchronised use cases. For concurrent use cases, CopyOnWriteArrayList, Collections.synchronizedList(), or a ConcurrentHashMap-backed structure are the appropriate choices. The only reason to write Vector today is when interacting with an API that specifically requires it — which is exceedingly rare.

Is Vector thread-safe?

Each individual method call is thread-safe — the lock prevents concurrent execution of any two methods. But compound operations (check-then-act sequences) are still subject to race conditions unless protected by external synchronized(vector) blocks. Many developers consider this partial thread safety more dangerous than no thread safety because it creates false confidence.

What is the relationship between Vector and Stack?

java.util.Stack extends Vector. It adds five methods: push(item), pop(), peek(), empty(), and search(item). Because it extends Vector, all index-based List operations are inherited — Stack.get(0) and Stack.add(5, item) are both callable, which violates pure stack semantics. For LIFO semantics in new code, use ArrayDeque with push(), pop(), and peek() — no global lock and no leaked index methods.

Does Vector fail-fast like ArrayList during iteration?

Yes. Vector's Iterator (obtained via iterator() or for-each) is fail-fast — it throws ConcurrentModificationException if the vector is structurally modified during iteration outside of the iterator's own remove() method. However, the synchronisation on each method does not prevent CME: the iterator uses modCount checking independent of the lock. CopyOnWriteArrayList is the correct choice for CME-free iteration under concurrent modification.

Can I convert a Vector to an ArrayList?

Yes, in one line: List<T> list = new ArrayList<>(vector). This creates a new ArrayList containing all elements in the same order. The two collections are independent after creation — changes to one do not affect the other. Collections.list(vector.elements()) also produces an ArrayList from the legacy Enumeration.

What Java version deprecated Vector?

Vector has never been formally deprecated with the @Deprecated annotation in the JDK. It is informally considered legacy — the Javadoc recommends ArrayList as the preferred alternative since Java 1.2. The class remains fully functional for backward compatibility. Removing it would break millions of lines of existing Java code.

Summary

Vector<E> is Java's original synchronised List — a resizable array where every method call acquires a global lock before executing. It was the correct solution in Java 1.0 when no other thread-safe collection existed. Today, it is slower than ArrayList in single-threaded code (due to lock overhead), slower than CopyOnWriteArrayList in read-heavy multi-threaded code (due to serialised reads), and less safe than it appears (compound operations are still subject to race conditions).

For interviews: know that Vector doubles on resize while ArrayList grows by 50%, explain that per-method synchronisation does not make compound operations atomic, name the legacy API methods and their modern equivalents, and know the three migration paths — ArrayList for single-threaded, CopyOnWriteArrayList for read-heavy concurrent, synchronizedList for write-heavy concurrent. Stack extending Vector is another interview topic — ArrayDeque is the correct modern replacement.

What to Read Next