Ever wondered why ArrayList is fast… until it suddenly isn’t? Most of us use ArrayList daily in Java. But very few actually think about what’s happening internally. Let’s break it down in a simple way. ➤ What is ArrayList internally? ArrayList is backed by a dynamic array. That means: • It uses a normal array under the hood • But it can grow automatically when needed ➤ Why is ArrayList so fast? When you do: list.get(index); It directly accesses the element using index. 👉 No looping 👉 No searching That’s why read operation = O(1) (very fast) ➤ Then where is the catch? The problem starts when the array gets full. Let’s say: Current capacity = 10 You try to add 11th element Now Java does something expensive: 1. Creates a new bigger array 2. Copies all old elements 3. Adds the new element 👉 This is called resizing ➤ How much does it grow? It doesn’t just add 1 more space. New capacity = old capacity + (old capacity / 2) 👉 ~1.5x growth This helps reduce frequent resizing, but still… ⚠️ Resizing = costly operation ➤ Why adding in middle is slow? If you do: list.add(0, element); All elements shift one position to the right. 👉 Time complexity = O(n) ➤ Real-world analogy Think of ArrayList like a row of fixed seats: • Sitting in an empty seat → fast • All seats full → need a bigger row (move everyone) • Inserting in middle → everyone shifts ➤ Pro Developer Tip If you already know the size: new ArrayList<>(1000); 👉 Avoids multiple resizes 👉 Improves performance significantly ➤ Key Takeaway ArrayList is fast because of: • Direct index access But it becomes slow when: • Resizing happens • Frequent insertions in middle #Java #ArrayList #CoreJava #DataStructures #Performance #SoftwareEngineering
That moment when ArrayList goes from O(1) to “hold on, let me rearrange everything real quick” 😄
The initial capacity tip is underrated in production code. If you're processing 10K records in a batch job and using default ArrayList — you're triggering multiple resizes silently. One line fix saves significant overhead. Another thing worth knowing — System.arraycopy() used internally during resize is native and optimised, but it's still O(n). At scale those hidden costs add up fast.