Stack with Java: Modern Best Practices & Implementation Guide 2026

Warning: If you’re starting a new Java project today and still reaching for java.util.Stack, stop. Oracle has explicitly discouraged its use for over two decades. While the class is still present in the JDK, relying on it for new development is an anti-pattern that invites performance issues and maintenance headaches. This guide corrects that misconception and shows you the modern, high-performance way to implement a stack with Java.

A stack is one of the most fundamental data structures in computer science, governed by the LIFO (Last In, First Out) principle. Think of it like a stack of plates in a cafeteria: you can only add a new plate to the top, and you can only remove the plate currently at the top. If you need the bottom plate, you must first remove all the ones above it.

In Java, while the concept is simple, the implementation choices have evolved significantly. Many developers search for "how to use a stack with Java" expecting to find Stack<T>, but the reality is more nuanced. In this article, I’ll walk you through why the legacy Stack class is obsolete, how to properly use the modern Deque/ArrayDeque approach, and how to build your own custom implementations from arrays and linked lists. Whether you’re preparing for technical interviews or cleaning up legacy code, this guide will set you straight.

Understanding the Java Stack: Legacy vs. Modern Approaches

Why java.util.Stack is Considered Deprecated

The java.util.Stack class is a classic example of "legacy code that never dies." It was introduced in Java 1.0 as part of the original Collections Framework, but by the time Java 2 arrived in 1998, its design flaws were glaringly obvious.

The core issue lies in its inheritance hierarchy. Stack extends Vector, which means it inherits all of Vector’s methods, including those completely irrelevant to stack operations. You can call set(), insertElementAt(), or removeElementAt() on a Stack—methods that violate the fundamental LIFO contract. This isn’t just poor API design; it’s a minefield for accidental misuse.

Personal experience: Early in my career, I inherited a codebase where a developer had used Stack but was freely calling get() to access arbitrary elements mid-stack. It was a ticking time bomb. We spent weeks refactoring it because the logic was silently broken whenever the stack depth changed.

Beyond API leakage, Stack suffers from synchronization overhead. Every method in Vector is synchronized by default, providing thread safety out of the box. But in practice, most applications don’t need a synchronized stack—they need a fast stack. The synchronization adds unnecessary lock contention, making Stack significantly slower than modern alternatives even in single-threaded scenarios.

There’s also the matter of potential memory leak patterns in older implementations, though this is more relevant to custom subclasses that don’t properly clean up references. Importantly, the class isn’t "removed"—it’s marked with @Deprecated to signal that Oracle recommends against using it for new code.

From the Oracle JDK Documentation, the recommendation is clear: "This class is obsolete. Use Deque instead."

The Modern Standard: Using Deque and ArrayDeque

So what should you use instead? The answer is the Deque interface, specifically implemented by ArrayDeque.

Deque (double-ended queue) is a cleaner, more flexible interface that supports stack operations without the baggage of Vector. It explicitly defines push(), pop(), and peek() methods, making your intent clear. Unlike Stack, it doesn’t leak irrelevant methods into your API.

Here’s why ArrayDeque is the gold standard:

1. Performance: ArrayDeque uses a resizable array under the hood, similar to ArrayList. This means contiguous memory allocation, excellent cache locality, and minimal garbage collection pressure. In contrast, LinkedList (another Deque implementation) creates a new node object for every element, generating significant GC overhead.
2. No synchronization bloat: Unless you specifically need thread safety, ArrayDeque is unsynchronized and fast.
3. Null handling: ArrayDeque doesn’t permit null elements, which prevents subtle bugs. If you need null support, you’d need a different approach.

Let’s look at the basic syntax:

// Modern stack implementation using ArrayDeque
Deque<String> stack = new ArrayDeque<>();

// Push an element
stack.push("item1");
stack.push("item2");

// Peek at the top without removing
String top = stack.peek(); // Returns "item2"

// Pop the top element
String removed = stack.pop(); // Returns "item2"

// Check if empty
boolean isEmpty = stack.isEmpty();

Notice how intuitive the API is. push() adds to the head, and pop() removes from the head—exactly what you want for LIFO behavior.

Performance note: In benchmark tests comparing 1 million push/pop operations, ArrayDeque consistently outperforms Stack by 2-3x in single-threaded scenarios. The difference becomes even more pronounced under concurrency when you swap ArrayDeque for ConcurrentLinkedDeque.

How to Implement Stack with Java: From Arrays to Linked Lists

While ArrayDeque handles most production needs, understanding how to build a stack from scratch is essential for interviews and for situations where you need custom behavior. Let’s explore both array-based and linked-list-based implementations.

Implementing Stack Using an Array

The array-based approach is straightforward but comes with a trade-off: fixed size or dynamic resizing logic. For a basic implementation, we’ll use a fixed-size array with overflow/underflow checks.

public class ArrayStack<T> {
    private T[] data;
    private int top;
    private int capacity;

    @SuppressWarnings("unchecked")
    public ArrayStack(int capacity) {
        this.capacity = capacity;
        this.data = (T[]) new Object[capacity];
        this.top = -1;
    }

    public void push(T item) {
        if (top >= capacity - 1) {
            throw new IllegalStateException("Stack overflow");
        }
        data[++top] = item;
    }

    public T pop() {
        if (top < 0) {
            throw new IllegalStateException("Stack underflow");
        }
        return data[top--];
    }

    public T peek() {
        if (top < 0) {
            throw new IllegalStateException("Stack is empty");
        }
        return data[top];
    }

    public boolean isEmpty() {
        return top < 0;
    }

    public int size() {
        return top + 1;
    }
}

The pros are clear: memory efficiency (no node objects), simplicity, and predictable performance. The cons? Fixed size unless you add complex resizing logic. In practice, you’d typically start with a reasonable capacity and double it when full—but that adds code complexity.

Building a Custom Stack Using Linked List

Linked lists offer dynamic sizing with no upfront capacity guess. Each node contains a value and a reference to the next node. For a stack, we always insert and remove at the head (not the tail) to maintain O(1) operations.

public class LinkedStack<T> {
    private Node<T> head;
    private int size;

    private static class Node<T> {
        T data;
        Node<T> next;

        Node(T data) {
            this.data = data;
            this.next = null;
        }
    }

    public LinkedStack() {
        this.head = null;
        this.size = 0;
    }

    public void push(T item) {
        Node<T> newNode = new Node<>(item);
        newNode.next = head;
        head = newNode;
        size++;
    }

    public T pop() {
        if (isEmpty()) {
            throw new IllegalStateException("Stack is empty");
        }
        T popped = head.data;
        head = head.next;
        size--;
        return popped;
    }

    public T peek() {
        if (isEmpty()) {
            throw new IllegalStateException("Stack is empty");
        }
        return head.data;
    }

    public boolean isEmpty() {
        return head == null;
    }

    public int size() {
        return size;
    }
}

Key points about this implementation:

• Head insertion ensures O(1) push/pop. Tail insertion would require traversing the list every time.
• Static nested class for Node avoids the hidden reference to the outer class, saving memory (about 8 bytes per node on 64-bit JVMs).
• Generic type <T> provides type safety without runtime casting.

After implementing this in my own projects for educational purposes, I found that the linked list version is genuinely useful when you need to implement undo/redo functionality or expression evaluation, where the stack might grow unpredictably.

Common Java Stack Interview Questions and Coding Tasks

Stack problems are interview staples. They test your understanding of LIFO behavior, recursion, and problem decomposition. Here are the top three you should master.

Top 3 Practical Stack Problems

1. Reverse a String Using a Stack

This is the "Hello World" of stack problems. Push each character onto the stack, then pop them off. The reverse order gives you the reversed string.

public static String reverseString(String input) {
    Deque<Character> stack = new ArrayDeque<>();
    for (char c : input.toCharArray()) {
        stack.push(c);
    }
    
    StringBuilder result = new StringBuilder();
    while (!stack.isEmpty()) {
        result.append(stack.pop());
    }
    return result.toString();
}

Why is this asked? It’s a simple, concrete way to verify that a candidate understands LIFO behavior without getting bogged down in complex logic.

2. Check for Balanced Parentheses

This is arguably the most common stack interview question. Given a string with various bracket types ()[]{}, determine if they’re properly nested and closed.

public static boolean isBalanced(String expression) {
    Deque<Character> stack = new ArrayDeque<>();
    
    for (char ch : expression.toCharArray()) {
        if (ch == '(' || ch == '{' || ch == '[') {
            stack.push(ch);
        } else if (ch == ')' || ch == '}' || ch == ']') {
            if (stack.isEmpty()) return false;
            
            char top = stack.pop();
            if (ch == ')' && top != '(') return false;
            if (ch == '}' && top != '{') return false;
            if (ch == ']' && top != '[') return false;
        }
    }
    
    return stack.isEmpty();
}

This problem tests multiple skills: stack manipulation, conditional logic, and edge-case handling. It’s also directly applicable to real-world parsing tasks.

3. Expression Evaluation Basics

Converting infix notation to postfix (RPN) or evaluating postfix expressions requires a stack. While full expression evaluators are complex, the core logic revolves around stack operations.

These problems appear in interviews at companies like Google, Amazon, and Microsoft because they reveal how candidates think about data flow and state management.

Handling Stack Overflow Errors

Before we move on, let’s address a common point of confusion: the difference between a data structure stack and a StackOverflowError.

A StackOverflowError occurs when your program’s call stack (the runtime mechanism that tracks method invocations) exceeds its allocated memory. This is almost always caused by uncontrolled recursion without a proper base case.

// Dangerous: infinite recursion leads to StackOverflowError
public static int factorial(int n) {
    return n * factorial(n - 1); // No base case!
}

// Safe: iterative approach avoids call stack explosion
public static int factorialIterative(int n) {
    int result = 1;
    for (int i = 2; i <= n; i++) {
        result *= i;
    }
    return result;
}

I’ve encountered this error countless times during code reviews. The fix is usually one of two approaches:

1. Refactor to iteration: Convert recursive algorithms to loops, as shown above.
2. Increase stack size: Pass -Xss to the JVM (e.g., -Xss4m for 4MB stack). However, this is a band-aid, not a solution. Deep recursion often indicates a design flaw.

For tree traversals and graph algorithms, iterative solutions with an explicit stack data structure are sometimes more memory-efficient than recursion anyway, since the heap (where your explicit stack lives) is typically larger than the thread stack.

Performance Comparison: Stack vs. Deque vs. LinkedList

Understanding performance trade-offs is crucial for making informed decisions. Let’s compare the three main approaches.

Time and Space Complexity Analysis

Memory overhead: This is where the biggest differences lie. ArrayDeque stores elements in a compact array with minimal overhead. LinkedList and custom linked stacks create a Node object for each element, adding roughly 24-32 bytes per item (object header + reference fields). For a stack of 1 million integers, this difference can be megabytes.

Thread safety: Stack is inherently synchronized, but so is Vector, which includes unnecessary methods. For concurrent stacks, prefer ConcurrentLinkedDeque (from java.util.concurrent) or use Collections.synchronizedDeque(new ArrayDeque<>()) if you need a synchronized wrapper.

In my experience benchmarking these, ArrayDeque consistently wins for general-purpose use. It’s fast, memory-efficient, and has a clean API. The only time I reach for a custom linked-list stack is when I need to implement something like a command pattern with undo functionality, where the node-based structure simplifies traversal and manipulation.

---

FAQ

Is java.util.Stack deprecated? Yes, in practice. While it’s not removed from the JDK, Oracle recommends using Deque (specifically ArrayDeque) instead due to better performance and lack of legacy synchronization overhead. The class carries @Deprecated to warn developers against new usage.

What is the difference between Stack and Deque in Java? Stack is a concrete class extending Vector with synchronized methods and a bloated API. Deque is an interface that represents a double-ended queue, offering cleaner stack operations (push, pop, peek) without unrelated methods. ArrayDeque is the recommended implementation of Deque for stack usage.

How do I create a custom stack in Java? You have two main options: use generics with a linked list for dynamic sizing (as shown above), or use an array for simplicity and memory efficiency. For most production needs, new ArrayDeque<>() is sufficient and requires no custom implementation.

How to fix StackOverflowError in Java? This error relates to the runtime call stack, not your data structure. Fix it by refactoring recursive algorithms to iterative ones, or by increasing the thread stack size via the -Xss JVM flag (e.g., -Xss4m). The iterative approach is preferred for production code.

Conclusion

Working with a stack with java doesn’t have to mean reaching for the deprecated Stack class. The modern best practice is to use ArrayDeque as your Deque implementation—it’s faster, more memory-efficient, and has a cleaner API than the legacy Stack.

That said, understanding how to manually implement a stack using arrays or linked lists remains crucial, especially for technical interviews. These exercises deepen your understanding of LIFO principles, memory management, and the trade-offs between fixed-size and dynamic data structures.

Remember: use ArrayDeque in production code, but be ready to write a custom stack from scratch in an interview. The performance benefits of Deque over Vector-based Stack are well-documented, and avoiding legacy patterns is a hallmark of mature Java development.

---

Ready to deepen your Java data structures knowledge? Download our free cheat sheet for Java Data Structures or check out our deeper dive into Recursion and Call Stacks.