Java Interview Questions

Almost every Java interview opens here. The trick is not to recite definitions — interviewers have heard "encapsulation is hiding data" five hundred times. They want to know if you can recognize these pillars in code.

1. Encapsulation — hide the wires, expose the buttons

Encapsulation means bundling data (fields) and behavior (methods) inside a class, and exposing only what the outside world needs. Private fields, public methods. Think of Sarah's coffee machine — customers push brew(), they don't poke at internalGrinderRPM.

public class CoffeeMachine {
    private int waterMl;          // hidden state
    private int beansGrams;
    private int grinderRpm = 1200;

    public Coffee brew(String type) {
        if (waterMl < 200) throw new IllegalStateException("Refill water");
        // internals hidden — customer just gets a Coffee back
        return new Coffee(type);
    }

    public void refillWater(int ml) { this.waterMl += ml; }
}

2. Inheritance — the family resemblance

Inheritance lets a child class reuse fields and methods from a parent. Sarah's shop sells different drinks, but every drink has a price, a name, and a way to "serve." Instead of repeating those in Coffee, Tea, and Smoothie, we put them in a parent Drink.

abstract class Drink {
    protected String name;
    protected double price;

    public abstract void prepare();   // each child decides how

    public void serve() {                 // shared behavior
        System.out.println("Serving " + name + " for ₹" + price);
    }
}

class Coffee extends Drink {
    public void prepare() { System.out.println("Brewing espresso..."); }
}

class Tea extends Drink {
    public void prepare() { System.out.println("Steeping leaves..."); }
}

3. Polymorphism — one call, many forms

Polymorphism means a single reference can point to different types and call the right method automatically. Sarah's barista holds a list of Drink — they call prepare() on each, and each drink does its own thing. The barista doesn't need a giant if/else chain.

List<Drink> orders = List.of(new Coffee(), new Tea(), new Coffee());

for (Drink d : orders) {
    d.prepare();   // resolves to Coffee.prepare() or Tea.prepare() at RUNTIME
    d.serve();
}

There are two flavors:

• Compile-time (overloading) — same method name, different parameter list. The compiler picks based on arguments. Example: System.out.println(int) vs println(String).
• Runtime (overriding) — child class redefines a parent method. The JVM picks based on the actual object type. This is what gives us "one call, many forms."

4. Abstraction — show what, hide how

Abstraction is the cousin of encapsulation. Encapsulation hides data; abstraction hides implementation details. You write to an interface ("what should happen"), not a concrete class ("how it happens").

interface PaymentGateway {
    PaymentResult pay(double amount);
}

class Razorpay implements PaymentGateway { /* HTTP calls to RP */ }
class Stripe   implements PaymentGateway { /* HTTP calls to Stripe */ }

// Caller doesn't care which gateway:
PaymentGateway gw = pickCheapestGateway();
gw.pay(499.0);

The String Pool — a shared bookshelf

Java keeps a special area of memory called the String Pool (or "string intern table") inside the heap. When you write a literal like "hello", the JVM checks: is this exact text already on the shelf? If yes, hand back the existing reference. If no, place it on the shelf and hand back the new reference.

String a = "hello";             // goes into the pool
String b = "hello";             // reuses the pool reference
String c = new String("hello");  // FORCES a new object on the heap

System.out.println(a == b);          // true  — same pool reference
System.out.println(a == c);          // false — c is a fresh object
System.out.println(a.equals(c));     // true  — same characters
System.out.println(a == c.intern());   // true  — intern() puts c into the pool

Why is String immutable?

Once a String is created, you can't change its characters. s.toUpperCase() returns a new String — the original is untouched. Why did Java's designers pick this?

• Pool safety. If two variables share "hello" from the pool and one could mutate it, the other would see the change. Chaos.
• Thread safety. Immutable objects are inherently safe to share across threads — no locks needed.
• HashMap key safety. A String's hashCode() is computed once and cached. If the contents could change, the map would lose the entry.
• Security. File paths, class names, URLs — all passed as Strings. If they could be mutated after a security check, an attacker could pass "safe.txt", get past the check, then change it to "/etc/passwd".

String vs StringBuilder vs StringBuffer

The contract in plain English

• If a.equals(b) is true, then a.hashCode() == b.hashCode() MUST be true.
• If hash codes are equal, equals may or may not be true (collisions are allowed).
• Both methods must be deterministic — same input, same output, every call.
• equals must be reflexive (a.equals(a)), symmetric (a.equals(b) == b.equals(a)), and transitive (a=b, b=c → a=c).

The right way to implement them

public class Employee {
    private final String id;
    private final String email;

    @Override
    public boolean equals(Object o) {
        if (this == o) return true;            // shortcut
        if (!(o instanceof Employee e)) return false;
        return Objects.equals(id, e.id) &&
               Objects.equals(email, e.email);
    }

    @Override
    public int hashCode() {
        return Objects.hash(id, email);     // must use SAME fields as equals
    }
}

What breaks if you violate the contract?

• HashSet/HashMap fails to find your object. You add it, you can't find it. Memory leak: the set grows forever with "duplicates" that aren't really duplicates.
• Two equal objects in different buckets. Iterating the map shows both — looks like a bug from the outside.
• Caches break silently. Spring's @Cacheable, Guava caches, anything keyed by your object — all return stale or missing data.

This question is so common that interviewers expect a thorough answer with the famous "Integer cache" twist. If you can explain that, you're showing you know the JVM, not just the syntax.

The simple rule

• == compares references for objects (same object in memory?), and values for primitives.
• .equals() compares logical equality based on the class's contract.

The Integer cache

To save memory, the JVM pre-creates Integer objects for the range -128 to 127 and reuses them whenever you call Integer.valueOf(x) (which autoboxing also calls). Outside that range, every call creates a fresh object.

Integer a = 127;
Integer b = 127;
System.out.println(a == b);         // true  — both pulled from cache

Integer c = 128;
Integer d = 128;
System.out.println(c == d);         // false — two new objects
System.out.println(c.equals(d));    // true  — same value

The Collections Framework is huge but organized. Three main interfaces sit at the top: List, Set, and Map. Everything else is a specialization.

The mental map

How to choose, in 30 seconds

• Need order + duplicates + index access? → ArrayList. Default choice.
• Need uniqueness, don't care about order? → HashSet.
• Need uniqueness in insertion order? → LinkedHashSet.
• Need uniqueness in sorted order? → TreeSet.
• Need key→value lookup? → HashMap (single-thread) or ConcurrentHashMap (multi-thread).
• Need sorted keys? → TreeMap.
• Need a stack/queue? → ArrayDeque (faster than Stack/LinkedList).

Big-O cheat sheet

The structure — an array of buckets

Internally, a HashMap is a Node[] (called the "table") where each slot is called a bucket. Default initial size: 16. Each bucket either holds null, a single Node, a linked list of Nodes (when there are collisions), or a red-black tree (when collisions get bad).

static class Node<K, V> {
    final int hash;
    final K key;
    V value;
    Node<K, V> next;   // linked list pointer for collisions
}

Put, step by step

1. Compute key.hashCode().
2. Apply a "spreading" function: hash = h ^ (h >>> 16). This mixes the high bits into the low bits, so even bad hashCodes spread well.
3. Compute bucket index: index = (n - 1) & hash where n is the table size (always a power of 2, so this is equivalent to hash % n but faster).
4. If the bucket is empty → place the new Node.
5. If occupied → walk the chain. If a Node's key .equals() the new key → replace the value. Otherwise → append.
6. If the chain length exceeds 8 AND the table size is ≥ 64 → convert that bucket to a red-black tree (treeification). Lookups in that bucket go from O(n) to O(log n).
7. If size > capacity * loadFactor → resize. Default load factor is 0.75, so a 16-bucket table resizes when it hits 12 entries. The new table is double the size, and every entry is rehashed into it.

Why load factor 0.75?

It's a balance. Lower load factor (e.g., 0.5) → fewer collisions but wasted memory. Higher (e.g., 0.9) → less memory but more collisions, slower lookups. 0.75 is the sweet spot picked from empirical testing.

The treeification fix (Java 8)

Pre-Java 8, a bucket with bad hashCodes (or worse, a malicious attacker) could degrade to O(n) — a denial-of-service vector. Java 8 added the tree conversion at threshold 8 → guarantees O(log n) worst case for any single bucket.

HashMap is NOT thread-safe

Concurrent puts during resize can cause infinite loops (pre-Java 8, due to entry rotation) or lost data. Use ConcurrentHashMap for multi-threaded access — it locks individual bucket segments (Java 8+: per-bucket CAS), so reads are lock-free and writes only block on the same bucket.

Textbooks teach: "Use LinkedList for frequent inserts in the middle." Reality: even then, ArrayList usually wins. Let's see why.

Internally

• ArrayList — backed by a contiguous Object[]. When full, it grows by 50% (Java 8+) and copies into a new array.
• LinkedList — doubly-linked list of Nodes. Each Node holds a value plus two pointers (prev, next).

The real-world performance story

Modern CPUs love contiguous memory. ArrayList is a flat array → CPU cache prefetches the next elements for free. LinkedList is scattered Nodes across the heap → every .next is a potential cache miss, often 100x slower than a cache hit.

When does LinkedList actually win?

Almost never in practice. The textbook answer says "frequent insertions in the middle" — but to insert in the middle, you first need to find the position, which is O(n) for LinkedList anyway (walking the chain). The only true win is when you already hold a Node reference and want O(1) insert/remove there — and that's a rare API need.

Real winning use case: Deque operations from both ends. But even there, ArrayDeque is usually faster.

The hierarchy

Every error inherits from Throwable. Below it are two branches:

• Error — JVM problems you can't recover from (OutOfMemoryError, StackOverflowError). Don't catch these.
• Exception — application problems. Two sub-categories:
  • Checked (everything that extends Exception but NOT RuntimeException) — compiler forces you to catch or declare. Examples: IOException, SQLException.
  • Unchecked (extends RuntimeException) — compiler doesn't force anything. Examples: NullPointerException, IllegalArgumentException.

try-with-resources (Java 7+)

Anything implementing AutoCloseable can go in a try-with-resources block — Java auto-closes it, in reverse order, even if an exception is thrown.

try (BufferedReader r = Files.newBufferedReader(path);
     PreparedStatement ps = conn.prepareStatement(sql)) {

    // use r and ps

}  // ps.close() then r.close() — even if exception thrown

Common mistakes

• Catching Exception or Throwable at the top. Hides bugs. Catch the narrowest type that's actually meaningful.
• Empty catch blocks. "Just don't crash" — and now your team spends 3 hours debugging silent corruption. At minimum log it.
• Wrapping and re-throwing without the cause. throw new RuntimeException("failed") loses the stack trace. Always pass the original: throw new RuntimeException("failed", e).
• Returning from finally. Swallows exceptions silently. Don't.

What is type erasure?

Java generics are a compile-time feature only. The compiler uses <T> to type-check your code and insert casts, but the bytecode that ships to the JVM has no record of T. Wherever you wrote T, the bytecode says Object (or the upper bound, like Number for <T extends Number>).

// What you write:
List<String> names = new ArrayList<>();
names.add("Sarah");
String first = names.get(0);

// What the JVM actually runs (after erasure):
List names = new ArrayList();
names.add("Sarah");
String first = (String) names.get(0);   // compiler-inserted cast

The consequences

• You can't do new T() — at runtime there is no T to instantiate.
• You can't do obj instanceof List<String> — only instanceof List. The runtime can't see the type parameter.
• You can't have arrays of generic types — new T[10] won't compile. (Arrays know their element type at runtime; generics don't.)
• Bridge methods — when a generic class is overridden, the compiler may add invisible methods to keep the JVM's method dispatch happy.

Wildcards — ? extends vs ? super (PECS)

Mnemonic: PECS — Producer Extends, Consumer Super.

• List<? extends Number> — you can read Numbers out (it's a producer), but you can't add anything (compiler can't know if it's a List of Integer or Double).
• List<? super Integer> — you can add Integers (it's a consumer), but reading gives you Object (compiler can't know the upper bound).

What does final mean?

• final variable — value can be assigned once. (For objects, it means the reference can't change — the object's internals can still mutate.)
• final method — cannot be overridden by subclasses.
• final class — cannot be extended. String, Integer, LocalDate are all final.

How to build a truly immutable class

1. Mark the class final (so no one can subclass and add mutability).
2. Mark all fields private final.
3. No setters. Initialize everything in the constructor.
4. If a field is itself a mutable object (e.g., a Date or List), defensive copy on the way in (in the constructor) and on the way out (in the getter).

public final class Order {
    private final String id;
    private final List<String> items;

    public Order(String id, List<String> items) {
        this.id = id;
        this.items = List.copyOf(items);   // defensive copy + immutable
    }

    public List<String> getItems() {
        return items;   // already unmodifiable, safe to return
    }
}

Why immutability matters

• Thread safety for free. No locks needed; the object can never be in an inconsistent state.
• Safe to use as a HashMap key. hashCode never changes mid-lookup.
• Easier to reason about. No "who mutated this?" debugging sessions.
• Cacheable. Compute once, reuse forever — String caches its hashCode.

Thread vs Process

• Process — an independent program with its own memory space. Two processes can't see each other's variables.
• Thread — a unit of work inside a process. All threads in the same process share the heap (objects, static fields), but each has its own stack (local variables).

Three ways to start a thread

// 1. Extend Thread (rarely the right choice)
class Worker extends Thread {
    public void run() { System.out.println("running"); }
}
new Worker().start();

// 2. Implement Runnable (preferred — you can still extend something else)
Runnable task = () -> System.out.println("running");
new Thread(task).start();

// 3. Submit to an Executor (the modern way — see section 13)
ExecutorService pool = Executors.newFixedThreadPool(4);
pool.submit(task);

Thread lifecycle

• NEW — created but not started.
• RUNNABLE — eligible to run (the OS scheduler picks when).
• BLOCKED — waiting for a monitor lock (e.g., entering a synchronized block held by another thread).
• WAITING / TIMED_WAITING — waiting for another thread (Object.wait(), Thread.join(), Thread.sleep()).
• TERMINATED — finished or threw an uncaught exception.

The problem they solve

Modern CPUs have multiple cores, each with its own cache. When thread A on Core 1 writes to a variable, that write may sit in Core 1's cache for a while before reaching main memory. Thread B on Core 2 reading the same variable might see a stale value. Worse, the compiler and CPU can reorder instructions for performance, breaking your assumptions about what runs first. synchronized and volatile are how Java tells the JVM "stop being clever here."

synchronized — mutual exclusion + memory visibility

Wraps a block in a monitor lock. Only one thread can hold the lock at a time; others block. Critically, entering and exiting a synchronized block also flushes the thread's CPU caches to/from main memory.

class Counter {
    private int count = 0;

    // Method-level — locks on `this`
    public synchronized void increment() { count++; }

    // Block-level — lock on a specific object (more flexible)
    private final Object lock = new Object();
    public void incrementSafe() {
        synchronized (lock) {
            count++;
        }
    }
}

volatile — visibility, NOT mutual exclusion

Marks a variable so every read goes to main memory and every write is flushed immediately. No locking. Threads always see the latest value, but multiple threads can still race on it.

class Worker implements Runnable {
    private volatile boolean running = true;

    public void run() {
        while (running) { /* work */ }
    }

    public void stop() { running = false; }   // other thread sees this immediately
}

When to use which

The four common pools

Submit and wait

ExecutorService pool = Executors.newFixedThreadPool(4);

// Submit returns a Future — the task's "claim ticket"
Future<String> future = pool.submit(() -> {
    Thread.sleep(1000);
    return "done";
});

String result = future.get();   // blocks until the task finishes

// Modern: CompletableFuture — chainable, non-blocking
CompletableFuture.supplyAsync(() -> fetchUser(42), pool)
    .thenApply(user -> user.getName())
    .thenAccept(name -> System.out.println(name))
    .exceptionally(ex -> { ex.printStackTrace(); return null; });

pool.shutdown();   // always shutdown — else JVM won't exit

Virtual Threads (Java 21+)

Lightweight threads managed by the JVM, not the OS. Cost: ~few KB. You can spin up millions. Perfect for I/O-bound work where each task spends most of its time waiting on a network call. The "one thread per request" model is back — but cheap.

try (ExecutorService exec = Executors.newVirtualThreadPerTaskExecutor()) {
    for (int i = 0; i < 10_000; i++) {
        exec.submit(() -> callSlowApi());
    }
}   // AutoCloseable — waits for all tasks

ReentrantLock — synchronized with superpowers

synchronized is simple but rigid. ReentrantLock gives you tryLock (non-blocking attempt), interruptible lock, fair ordering, and multiple condition variables.

Lock lock = new ReentrantLock();

// Try to acquire for 500ms — give up if it can't
if (lock.tryLock(500, TimeUnit.MILLISECONDS)) {
    try {
        // critical section
    } finally {
        lock.unlock();   // MUST be in finally — else lock leaks forever
    }
}

ReadWriteLock — many readers, one writer

If your data is read 100x more often than written, full mutual exclusion is wasteful. ReentrantReadWriteLock lets unlimited readers in concurrently, but writers get exclusive access.

Atomics — lock-free counters

AtomicInteger, AtomicLong, AtomicReference use CPU-level CAS (compare-and-swap) instructions. No locks, no blocking — just retry-on-conflict at the hardware level.

AtomicInteger count = new AtomicInteger();
count.incrementAndGet();    // thread-safe ++ without synchronized
count.compareAndSet(5, 10);  // "if value is 5, set to 10" atomically

Concurrent collections

The five memory areas

• Heap — shared by all threads. All objects (everything created with new) live here. Subdivided into Young Gen (Eden + two Survivor spaces) and Old Gen.
• Stack — one per thread. Holds method frames: each frame contains local variables and the return address. Primitives and object references (NOT the objects themselves) live here.
• Metaspace (Java 8+; replaced PermGen) — class metadata, method bytecode, runtime constant pool. Native memory, grows dynamically.
• PC Register — one per thread. Holds the address of the current bytecode instruction.
• Native Method Stack — for JNI / native calls.

Stack vs Heap — a concrete example

void checkOut() {
    int total = 100;                       // primitive — on this thread's STACK
    String name = "Sarah";                  // reference on STACK, "Sarah" String on HEAP (in pool)
    Order order = new Order(42, name);     // reference on STACK, Order object on HEAP
}   // stack frame discarded — heap objects live until GC

Young vs Old generation

The heap has two main zones:

• Young Generation — where new objects are born (specifically in Eden). Most objects die young (the "weak generational hypothesis"). Young GC is fast and frequent.
• Old Generation — objects that survive several Young GC cycles get promoted here. Long-lived objects (caches, singletons). Old GC is slower but rarer.

The GC's job is to find objects no one is using anymore and reclaim their memory. The how and when has evolved dramatically — knowing modern GCs (G1, ZGC, Shenandoah) is a strong signal in interviews.

What does "no one is using" mean?

The GC walks from a set of GC roots (live thread stacks, static fields, JNI references) and marks every object it can reach. Anything not reached is unreachable → garbage → freed.

Generational hypothesis — the key insight

Empirically, most objects die young. A request handler creates 100 short-lived objects, returns, and they're all garbage. Why scan the whole heap when 99% of garbage is in the young area? Modern GCs split the heap into Young + Old and run different algorithms on each.

GC algorithms — the modern lineup

Stop-the-world (STW)

For some GC phases, all application threads must pause. This is "stop-the-world." It's why a 16 GB heap full of long-lived objects can cause noticeable lag spikes. Modern GCs (G1, ZGC) minimize STW pauses by doing most work concurrently with the application.

When you can't be GC'd

Common causes of memory leaks in Java (yes, leaks exist despite GC):

• Static collections that grow forever — a static HashMap that you never evict from.
• Unclosed listeners / callbacks — registered but never deregistered. The framework keeps a strong reference to your object.
• ThreadLocals not removed — a thread in a pool retains its ThreadLocal entry across requests.
• Caches without size limits — use WeakHashMap or a real cache library (Caffeine).

The classic three-tier hierarchy

• Bootstrap ClassLoader — written in C++, part of the JVM itself. Loads the core JDK classes (java.lang.*, java.util.*). Pre-Java 9 these came from rt.jar; post-Java 9 from JRT modules.
• Platform (Extension) ClassLoader — loads JDK extension modules. A child of bootstrap.
• Application (System) ClassLoader — loads classes from your -cp classpath. A child of platform. This is the one that loads your code.

The delegation model

When asked to load class X, a ClassLoader first asks its parent ("can you load X?"). Only if the parent can't does it try locally. This walks all the way up to bootstrap before any child tries.

Why does this matter?

• Class identity = (class name, ClassLoader). Two different ClassLoaders can load the same class name and the JVM treats them as different types. Cast between them → ClassCastException.
• Hot reloading — frameworks like Spring DevTools, Tomcat, and IDEs use multiple ClassLoaders so they can swap class versions without restarting the JVM.
• Plugin systems — each plugin gets its own ClassLoader, isolated from others.

What is a stream?

A Stream is a sequence of elements supporting declarative operations like filter, map, reduce. It's NOT a data structure — it doesn't store anything. It's a pipeline that lazily processes elements from a source.

List<Order> orders = /* ... */;

Map<String, Double> topCustomers = orders.stream()
    .filter(o -> o.getDate().isAfter(LocalDate.now().minusDays(7)))
    .collect(Collectors.groupingBy(Order::getCustomer,
                                Collectors.summingDouble(Order::getAmount)));

Three pieces of every stream

1. Source — collection, array, I/O channel, generator. Where elements come from.
2. Intermediate operations — filter, map, flatMap, sorted, distinct. Lazy — they describe work, don't do it.
3. Terminal operation — collect, forEach, reduce, count. Triggers the actual computation.

Lazy evaluation — the key superpower

Intermediate ops don't run until a terminal op pulls. This means short-circuiting: findFirst() only processes elements until it finds one. limit(10) stops after ten. Streams over infinite sources (Stream.iterate, Stream.generate) work because of laziness.

Parallel streams

Add .parallel() and the JVM splits the work across the common ForkJoinPool. Sounds magical — and is dangerous if abused.

Functional interfaces — the building blocks

Optional was added in Java 8 to express "this might be absent." The community immediately misused it everywhere. Here's how to use it the way Brian Goetz (Java's chief language architect) recommends.

What it's for

Optional exists to make "no value" explicit in return types. A method returning Optional<User> tells the caller, "I might not find one — handle that case."

public Optional<User> findById(String id) {
    return Optional.ofNullable(userMap.get(id));
}

// Caller is forced to handle absence:
String name = findById("u1")
    .map(User::getName)
    .orElse("Unknown");

What it's NOT for

• Fields — don't make Optional<Address> address a field. Use null directly, or split into two classes. Optional doesn't serialize well and adds memory overhead.
• Method parameters — overloads or just allowing null are simpler.
• Collection elements — List<Optional<User>> is silly. An empty list is the absence.
• Direct .get() without isPresent — defeats the entire purpose. If you're going to call .get() blindly, you've replaced NullPointerException with NoSuchElementException for no benefit.

The fundamental difference

HashMap is single-threaded by design. If two threads write to it at the same time, you can corrupt the internal bucket array — pre-Java 8 this could even create a circular linked list during resize, sending one thread into a 100% CPU infinite loop. ConcurrentHashMap is purpose-built for concurrent access — multiple threads can read and write at the same time without locks blocking each other (in most cases).

How ConcurrentHashMap achieves concurrency

It does not slap a single lock around the whole map (that's what Collections.synchronizedMap() does, and it's terrible for throughput). Instead:

• Java 7 (segment-based): the map was split into 16 "segments". Each segment had its own lock. Two threads writing to different segments never blocked each other.
• Java 8+ (bucket-level CAS): the segments were removed. Each bucket can be updated atomically using compare-and-swap (CAS). When buckets collide on a write, only that one bucket synchronizes briefly. Reads are fully lock-free thanks to volatile fields on the Node.

Side-by-side comparison

Why no nulls in ConcurrentHashMap?

With concurrent access, map.get(key) returning null would be ambiguous: did the key not exist, or did someone just put(key, null)? In a single-threaded HashMap you can follow up with containsKey, but in a concurrent map another thread might mutate between the two calls. So Doug Lea (the author) just banned nulls — disambiguation by design.

The "atomic operations" superpower

ConcurrentHashMap exposes operations like putIfAbsent, compute, computeIfAbsent, merge that are atomic — no other thread can sneak in between the read and the write. Always prefer these over a manual get-then-put sequence:

// Two threads can both see "absent" and both put their value
if (!map.containsKey(key)) {
    map.put(key, expensiveCompute());
}

map.computeIfAbsent(key, k -> expensiveCompute());

When to use which

• HashMap — local variables, single-threaded code, request-scoped data, anything that won't escape a thread.
• ConcurrentHashMap — caches, shared registries, counters, anything multiple threads see.
• Collections.synchronizedMap(new HashMap<>()) — almost never. It's a single coarse lock; ConcurrentHashMap beats it on every benchmark.

OOM is not one error — it's six

The full message after the colon tells you which memory area ran out. They have very different causes:

Common root causes for "Java heap space"

• Static collections that grow forever — private static final Map<String, User> CACHE = new HashMap<>(); with no eviction. Classic.
• ThreadLocal leaks — values set on a thread pool thread, never removed. The thread lives forever, the value lives with it.
• Listeners and callbacks not deregistered — every page registers a listener; the page closes; the listener still holds the page in memory.
• Loading too much from the database — userRepo.findAll() returning 5 million rows. JPA hydrates every one into an object.
• Caches without bounds — Guava/Caffeine caches with no maximumSize.
• Inner classes capturing outer-class references — common in Android-style code; less common but possible in Java.

The debugging workflow — what Karan actually does

1. Add JVM flags before the next crash so you have evidence:
   JVM flags every prod app should have

   -XX:+HeapDumpOnOutOfMemoryError
   -XX:HeapDumpPath=/var/log/heapdump.hprof
   -Xlog:gc*:file=/var/log/gc.log:time,uptime,level,tags
   -XX:+ExitOnOutOfMemoryError   // let k8s restart you cleanly

2. Reproduce or wait for the next crash. Now you have a heap dump (a snapshot of every object in memory at the moment of OOM).
3. Open the heap dump in Eclipse MAT (Memory Analyzer Tool) — or VisualVM, or IntelliJ's profiler. MAT is the gold standard.
4. Run "Leak Suspects Report". MAT will rank the biggest retained-size objects and tell you "Object X is keeping 1.4 GB alive via the path Y → Z". This single feature solves 80% of leaks.
5. Look at the dominator tree — the chain of references that holds the suspect object alive. The first non-framework class in that chain is usually your culprit.
6. Cross-check with GC logs. If the Old Gen graph monotonically grows and full GCs reclaim less and less — that's a leak. If it sawtooths normally and just hits the ceiling under load — your heap is just too small.

Live diagnostics (no heap dump needed)

• jcmd <pid> GC.heap_info — current heap usage by region
• jcmd <pid> GC.class_histogram — count and total size of every loaded class's instances. The class with 5 million instances of byte[] is your suspect.
• jstat -gcutil <pid> 1000 — once-per-second GC stats; watch the Old Gen %
• jmap -dump:live,format=b,file=heap.hprof <pid> — manually trigger a heap dump while the app is running

Fixes by category

• Cache leak → put a bounded eviction policy on the cache (Caffeine + .maximumSize() + .expireAfterAccess()).
• ThreadLocal leak → always pair set() with remove() in a finally block, or use a try-with-resources wrapper.
• Loading too much from DB → add pagination, use streaming (JPA Stream<Entity> with @QueryHints), or process in chunks.
• Genuine workload growth → bump -Xmx, but only after you've ruled out a leak.

What "thread-safe" really means

A class is thread-safe if its public behavior remains correct when multiple threads use it concurrently — without callers needing to add their own synchronization. Three things can go wrong without thread-safety:

• Race conditions — two threads see the same "before" state and both apply changes, one update is lost.
• Memory visibility — thread A writes a field, thread B never sees the new value because it's cached in a CPU register.
• Compound operations — "check then act" or "read-modify-write" sequences that are atomic individually but not as a unit.

The buggy starting point

class ProductInventory {
    private final Map<String, Integer> stock = new HashMap<>();

    public boolean tryReserve(String sku, int qty) {
        Integer available = stock.get(sku);   // (1) read
        if (available == null || available < qty) return false;
        stock.put(sku, available - qty);          // (2) write — both threads do this with the same "available"
        return true;
    }
}

Two threads can both pass step (1) seeing available = 1, then both execute step (2) writing 0 — and both tryReserve calls return true. Two phones sold; one phone in inventory. That's the bug.

Five ways to fix it — pick by trade-off

Option 1 — synchronized method (simplest)

public synchronized boolean tryReserve(String sku, int qty) {
    Integer available = stock.get(sku);
    if (available == null || available < qty) return false;
    stock.put(sku, available - qty);
    return true;
}

One lock for the whole object. Reservations on different SKUs serialize unnecessarily — fine for low traffic, painful at Black Friday scale.

Option 2 — Per-key locking (better concurrency)

private final ConcurrentHashMap<String, Integer> stock = new ConcurrentHashMap<>();

public boolean tryReserve(String sku, int qty) {
    return stock.computeIfPresent(sku, (k, current) -> {
        if (current < qty) return current;       // no change → put back same value
        return current - qty;
    }) != null;
    // note: the boolean we want is "did the value actually change" —
    // real code would use AtomicReference to capture that. Sketch shown for clarity.
}

The lambda runs under a per-bucket lock. Two threads on different SKUs proceed in parallel.

Option 3 — Atomic counters (lock-free)

private final ConcurrentHashMap<String, AtomicInteger> stock = new ConcurrentHashMap<>();

public boolean tryReserve(String sku, int qty) {
    AtomicInteger counter = stock.get(sku);
    if (counter == null) return false;
    while (true) {
        int current = counter.get();
        if (current < qty) return false;
        if (counter.compareAndSet(current, current - qty)) return true;
        // CAS failed — another thread changed it; loop and retry
    }
}

Hardware-level CAS, no kernel locks. Beats synchronized for hot single counters under high contention.

Option 4 — Immutability (no locks needed at all)

If ProductInventory is read-mostly (e.g., a config snapshot), make it immutable and replace the whole reference atomically:

private final AtomicReference<Map<String, Integer>> ref =
    new AtomicReference<>(Map.of());

public void replaceAll(Map<String, Integer> next) {
    ref.set(Map.copyOf(next));   // immutable snapshot
}

Option 5 — Use a thread-safe library (Caffeine, Hazelcast, Redis)

For real e-commerce inventory, in-memory state isn't enough — you need persistence + cross-node coordination. Move state to Redis with DECRBY (atomic decrement) or use a distributed lock.

The thread-safety checklist

• Identify shared mutable state — fields read/written by multiple threads.
• Make it immutable if possible — final fields, defensive copies, no setters.
• If it must be mutable, pick the right primitive: synchronized, ReentrantLock, Atomic*, ConcurrentHashMap, volatile (visibility only).
• Identify compound operations ("check-then-act", "read-modify-write") and make each one atomic.
• Avoid leaking this from a constructor — partially-constructed objects can be seen by other threads.
• Document the policy — annotate with @ThreadSafe / @NotThreadSafe (jcip-annotations) so callers know.

The 10-step ritual

Spring follows a strict sequence whenever it brings a bean to life. The same sequence runs for every bean — from your @Service to a third-party library's DataSource:

1. Bean Definition — Spring scans @Component/@Configuration and registers a BeanDefinition (a recipe — class name, scope, dependencies). No object exists yet.
2. Instantiation — When something requests the bean (or eager init kicks in), Spring calls the constructor (or factory method). Now an object exists in memory.
3. Populate Properties — Spring resolves @Autowired dependencies and injects them into fields/setters. (Constructor-injected deps were already supplied in step 2.)
4. Aware interfaces — If the bean implements BeanNameAware, BeanFactoryAware, ApplicationContextAware, Spring calls those setters now.
5. BeanPostProcessor.postProcessBeforeInitialization — every registered BeanPostProcessor gets a crack at the bean. This is where AOP proxies are wrapped, @Autowired validation happens, etc.
6. InitializingBean.afterPropertiesSet() — if the bean implements this interface, Spring calls it. (Generally avoid — couples to Spring.)
7. @PostConstruct / custom init-method — your custom initialization runs. This is the "after wiring is done, do my setup" hook.
8. BeanPostProcessor.postProcessAfterInitialization — second pass for post-processors. This is where Spring AOP wraps the bean in a proxy (e.g., for @Transactional) — that's why injected versions of your bean are CGLib subclasses.
9. Bean is in use — methods get called by the rest of the app.
10. Destruction — On context close: @PreDestroy → DisposableBean.destroy() → custom destroy-method. Singleton beans only — prototype scope is never destroyed by Spring.

Diagram of the flow

BeanDefinition
    ↓
new MyBean(deps)            // constructor
    ↓
setX(...) / @Autowired      // field/setter injection
    ↓
setBeanName / setApplicationContext   // Aware callbacks
    ↓
postProcessBeforeInitialization (every BeanPostProcessor)
    ↓
afterPropertiesSet()        // InitializingBean
    ↓
@PostConstruct method
    ↓
postProcessAfterInitialization   // AOP proxies happen here
    ↓
[ READY — bean is used by the app ]
    ↓
@PreDestroy
    ↓
destroy()                   // DisposableBean

Concrete example

@Service
public class UserService implements InitializingBean, DisposableBean {
    private final UserRepository repo;

    public UserService(UserRepository repo) {       // step 2 + 3: ctor + DI
        this.repo = repo;
    }

    @PostConstruct
    public void init() {                                // step 7
        // warm cache, validate config, etc.
    }

    @Override
    public void afterPropertiesSet() { }                 // step 6

    @PreDestroy
    public void cleanup() {                              // step 10
        // flush queues, close clients
    }

    @Override
    public void destroy() { }                            // also step 10
}

Bean scopes change the rules

• Singleton (default) — one instance per Spring container. Created at startup (eager) unless @Lazy.
• Prototype — new instance every time it's requested. Spring does NOT call destroy callbacks on prototypes — you own the cleanup.
• Request / Session — Spring MVC scopes; one instance per HTTP request or session.

Why the proxy step matters

When a bean has @Transactional, @Async, or @Cacheable, what gets injected elsewhere is not your class — it's a CGLib subclass (or JDK dynamic proxy if you implement an interface). The proxy intercepts every method call to add transaction/cache/async behavior, then delegates to your real instance. This is why calling @Transactional methods from within the same class (this.method()) bypasses the proxy and the transaction never starts.

The core idea — invert the dependency direction

In hand-rolled Java, your UserService says "I need a UserRepository, let me new one up." That couples UserService to the concrete UserRepository class. Dependency injection inverts this: UserService just declares what it needs (in its constructor or a field), and someone else — Spring — supplies the dependency. UserService doesn't know or care which implementation it gets.

The mechanism — three layers

Spring DI rests on three pieces of machinery: the BeanDefinition registry (the catalog of all known beans), the ApplicationContext (the runtime container), and BeanFactory (the lower-level interface that actually builds and wires beans).

Startup walkthrough — what happens in SpringApplication.run()

1. Component Scan. Spring scans the packages under your main class for @Component/@Service/@Repository/@Controller/@Configuration — ASM-based bytecode reading, not actual class loading. For each annotated class, it creates a BeanDefinition: name, class, scope, autowire mode, dependencies.
2. Configuration classes processed. Methods annotated @Bean inside @Configuration classes also produce BeanDefinitions — the method itself becomes the factory.
3. BeanDefinitionRegistryPostProcessor — runs (e.g., to add more bean definitions dynamically — Spring Boot's auto-configuration uses this).
4. BeanFactoryPostProcessor — gets a chance to modify bean definitions (e.g., resolve ${property} placeholders).
5. Eager singleton creation. Spring iterates all singleton bean definitions and instantiates each one. For each:
   • Resolve constructor — pick the one with the most-satisfiable parameters.
   • For each constructor parameter, recursively get-or-create that bean (this is where DI happens).
   • Call new on the constructor with those resolved dependencies.
   • Field/setter inject any remaining @Autowired deps.
   • Run init callbacks, post-processors, AOP wrapping (see the bean lifecycle in section 24).
6. Cache the singleton. Future requests for the same bean return the cached instance — that's why singletons are singletons.

Resolution rules — how Spring picks which bean to inject

Given a @Autowired UserRepository repo, Spring looks at all beans assignable to UserRepository:

1. If exactly one match → inject it.
2. If multiple matches → look for @Primary; if present, use that one.
3. Still ambiguous → look for @Qualifier("name") on the injection point.
4. Still ambiguous → fall back to matching by parameter/field name (e.g., repo tries to match a bean named repo).
5. Still nothing → throw NoUniqueBeanDefinitionException.

Three injection styles

@Service
public class UserService {
    private final UserRepository repo;
    public UserService(UserRepository repo) {   // @Autowired implicit on single ctor (Spring 4.3+)
        this.repo = repo;
    }
}

@Autowired
@Setter
private EmailService email;

@Autowired
private UserRepository repo;   // hides dependencies, not final, hard to test, can't detect circular deps cleanly

Constructor injection is preferred because: (1) the field can be final, (2) the dependency is visible in the type signature, (3) you can construct the class in tests with plain new (no Spring needed), (4) circular dependencies fail at startup instead of silently breaking later.

How does field injection work without setters?

Reflection. Spring uses Field.setAccessible(true) + Field.set(bean, dependency). That's why private final fields cannot be field-injected — final can only be set in the constructor, and reflection-setting it is undefined behavior in modern JVMs.

Circular dependency handling

If A needs B via constructor and B needs A via constructor → unsolvable, startup fails. If at least one side uses setter/field injection, Spring uses a three-level cache to expose a half-constructed reference: the partially-built A is added to the "early singleton" cache so B can grab a reference to it before A's setters have run. It works, but it's a code smell — fix the circular design.

What's @ComponentScan doing under the hood?

It uses Spring's ClassPathScanningCandidateComponentProvider which:

1. Resolves the base package to a filesystem/JAR path.
2. Walks all .class files using ASM to read the bytecode without loading the class.
3. Checks for stereotype annotations (@Component, @Service, etc.).
4. Produces BeanDefinitions for matches.

ASM-based scanning is why component scan is fast — it never invokes the class loader for non-component classes.

The 10,000-foot view

When Spring sees @Transactional on a bean's method, it wraps the bean in a proxy at startup (CGLib subclass, or JDK dynamic proxy if the bean implements an interface). The proxy intercepts every public method call. If the called method is annotated, the proxy:

1. Asks the PlatformTransactionManager to begin a transaction (or join an existing one — see propagation).
2. Invokes your real method.
3. If the method returns normally → commit.
4. If the method throws an unchecked exception (RuntimeException, Error) → rollback.
5. If the method throws a checked exception → by default, COMMIT (yes, really — rule 5 of @Transactional gotchas).

The proxy in action — diagram

caller -> UserService$$EnhancerByCGLIB.transfer()        // the proxy
            ↓
       beginTransaction()
            ↓
       super.transfer()        // real method
            ↓
       commit() | rollback()
            ↓
       return to caller

The four rollback rules everyone gets wrong

Rule 1 — Default rollback is unchecked exceptions only

@Transactional rolls back on RuntimeException and Error. It commits on checked exceptions like IOException. To change this:

@Transactional(rollbackFor = Exception.class)
public void transfer(...) throws IOException { ... }

Rule 2 — Self-invocation bypasses the proxy

public void orderFlow() {
    this.saveOrder();   // direct call — proxy NOT involved → @Transactional ignored!
}

@Transactional
public void saveOrder() { ... }

The proxy intercepts external calls. this.foo() is a direct method call on the underlying object — it never goes through the proxy. Fix: split into two beans, or use AopContext.currentProxy(), or self-inject.

Rule 3 — Catching the exception kills the rollback

@Transactional
public void transfer(...) {
    try {
        debit(from);
        credit(to);
    } catch (RuntimeException e) {
        // swallowed — proxy never sees the exception → COMMIT
        log.error("transfer failed", e);
    }
}

The proxy decides commit/rollback based on whether the method throws. If you catch and swallow, the method "returns normally" and gets committed.

Rule 4 — Only public methods are proxied (CGLib)

@Transactional on private/package-private methods is silently ignored. JDK dynamic proxies require an interface; CGLib subclasses can only override non-final, non-private methods.

Propagation — what happens when @Transactional calls @Transactional

Common use: auditing — @Transactional(propagation = REQUIRES_NEW) on the audit-log save so the audit row commits even if the parent business transaction rolls back.

Isolation level — what reads can you trust?

• READ_UNCOMMITTED — see uncommitted changes from other tx (dirty reads). Almost never used.
• READ_COMMITTED (Postgres default) — only see committed data, but two reads in the same tx can see different values (non-repeatable read).
• REPEATABLE_READ (MySQL default) — same row returns same value within the tx. Phantoms still possible (new rows matching your WHERE).
• SERIALIZABLE — full isolation, as if transactions ran one after another. Safest, slowest.

How does the transaction "follow" the thread?

Spring stores the active Connection + transaction state in a ThreadLocal. JdbcTemplate / Hibernate / JPA query methods inside the transactional method look up the thread-bound connection, so all queries share the same transaction. This is why @Transactional + a new thread (e.g., @Async or CompletableFuture.runAsync) is broken — the thread-local doesn't follow.

The short answer

@Service and @Repository are both meta-annotated with @Component. From Spring's perspective, all three register a bean. The differences are: (1) intent — what role this class plays in the architecture, and (2) one functional difference — @Repository triggers JDBC/JPA exception translation.

Side-by-side

The functional difference — exception translation

JPA throws PersistenceException, JDBC throws SQLException with vendor-specific error codes ("23505" for Postgres unique-violation, "1062" for MySQL). If your service layer catches these directly, your business code becomes coupled to the database product.

When you mark a class @Repository, Spring's PersistenceExceptionTranslationPostProcessor wraps it in a proxy that converts these low-level exceptions into Spring's vendor-neutral DataAccessException hierarchy:

• DuplicateKeyException — for any unique-violation, regardless of DB
• DataIntegrityViolationException — generic constraint violation
• OptimisticLockingFailureException — version mismatch on update
• QueryTimeoutException — DB query timeout

Your service code can now catch (DuplicateKeyException e) portably across MySQL, Postgres, Oracle.

@Service
public class UserService {
    public void register(User u) {
        try {
            userRepo.save(u);
        } catch (DuplicateKeyException e) {     // portable Spring exception
            throw new EmailAlreadyTakenException();
        }
    }
}

Why bother with intent annotations at all?

• Readability — a reader sees @Service and immediately knows "this is business logic, not a controller, not a DAO". Self-documenting layering.
• Tooling — IDEs, static analyzers, and AOP pointcuts can target a layer (execution(* (@Service *).*(..))).
• Future hooks — Spring may add behavior to @Service in future versions. @Repository already has its hook; @Service is reserved for similar purposes.

What about @Configuration?

Also a meta-@Component. The extra behavior: @Bean methods inside an @Configuration class are intercepted by a CGLib proxy so that calling another @Bean method returns the cached singleton instead of running the method twice. Without @Configuration (e.g., with the lighter proxyBeanMethods=false), each call would create a new instance.

The mechanism — @ControllerAdvice + @ExceptionHandler

@ControllerAdvice is a special @Component that Spring MVC consults for every controller in the application. Inside it, methods annotated @ExceptionHandler(SomeException.class) are called whenever a controller throws that exception type, and their return value becomes the HTTP response — same way as a normal controller method.

A complete error-handling setup

@RestControllerAdvice
public class GlobalExceptionHandler {

    @ExceptionHandler(UserNotFoundException.class)
    public ResponseEntity<ApiError> handleNotFound(UserNotFoundException ex) {
        return ResponseEntity.status(404)
            .body(new ApiError("USER_NOT_FOUND", ex.getMessage()));
    }

    @ExceptionHandler(MethodArgumentNotValidException.class)
    public ResponseEntity<ApiError> handleValidation(MethodArgumentNotValidException ex) {
        List<String> errors = ex.getBindingResult().getFieldErrors().stream()
            .map(f -> f.getField() + ": " + f.getDefaultMessage())
            .toList();
        return ResponseEntity.badRequest()
            .body(new ApiError("VALIDATION_FAILED", errors));
    }

    @ExceptionHandler(DataIntegrityViolationException.class)
    public ResponseEntity<ApiError> handleDuplicate(DataIntegrityViolationException ex) {
        return ResponseEntity.status(409)
            .body(new ApiError("DUPLICATE_RESOURCE", "Already exists"));
    }

    @ExceptionHandler(Exception.class)         // catch-all — must be last
    public ResponseEntity<ApiError> handleAll(Exception ex) {
        log.error("unhandled", ex);                     // log full stack server-side
        return ResponseEntity.status(500)
            .body(new ApiError("INTERNAL_ERROR", "Something went wrong"));
    }
}

public record ApiError(String code, Object detail, Instant timestamp) {
    public ApiError(String code, Object detail) {
        this(code, detail, Instant.now());
    }
}

The handler hierarchy — most specific wins

If handleNotFound matches UserNotFoundException and a generic handleAll matches Exception, Spring picks the most specific handler — your specific one. Order doesn't matter; type specificity does.

RFC 7807 — the standard "Problem Details" format

For consistency across services, follow the IETF Problem Details standard:

{
  "type":     "https://api.example.com/errors/user-not-found",
  "title":    "User not found",
  "status":   404,
  "detail":   "No user with id=42",
  "instance": "/api/users/42",
  "timestamp": "2026-05-10T09:23:14Z"
}

Spring 6 / Boot 3 has built-in support — extend ResponseEntityExceptionHandler and Spring will automatically produce ProblemDetail bodies for the standard exceptions.

Validation errors — a special case

@Valid on controller params triggers MethodArgumentNotValidException when validation fails. Catch it in your advice and return field-level error messages so the frontend can highlight which fields are wrong.

What to log vs what to return

• Log server-side — full stack trace, request ID, user ID, request body. This is for your debugging.
• Return to client — error code, human-readable detail, request ID (so users can quote it to support). Never return stack traces or SQL fragments — that's an info leak attack vector.

Errors thrown outside controllers

@ControllerAdvice catches exceptions thrown during request handling. Exceptions in @Async methods, scheduled jobs, or filters are NOT caught — handle those with their own mechanisms (AsyncUncaughtExceptionHandler, custom error filter chain, etc.).

The two strategies

How lazy loading actually works

When you load an Order with a lazy List<OrderItem> items, Hibernate doesn't query the items table. Instead, it puts a PersistentBag proxy in the field. The proxy holds a reference to the session. On the first order.getItems().size() call, the proxy hits the DB to fetch the actual items.

The N+1 problem — what bit Pooja

List<Order> orders = orderRepo.findAll();        // 1 query: SELECT * FROM orders
for (Order o : orders) {
    System.out.println(o.getItems().size());  // N queries: SELECT * FROM items WHERE order_id = ?
}
// Total: 1 + N queries — devastating for N = 1000

Five ways to avoid N+1

Fix 1 — JOIN FETCH in JPQL (most common)

@Query("SELECT o FROM Order o LEFT JOIN FETCH o.items WHERE o.userId = :uid")
List<Order> findOrdersWithItems(@Param("uid") Long uid);

Fix 2 — Entity Graphs

@EntityGraph(attributePaths = {"items", "items.product"})
List<Order> findByUserId(Long userId);

Fix 3 — Batch Size

Annotate the collection: @BatchSize(size = 50). Now Hibernate will fetch 50 orders' items in a single WHERE order_id IN (?, ?, ...) instead of one query per order. Reduces N+1 to N/50 + 1 — a 50x improvement.

Fix 4 — Projections / DTOs

If you only need a few fields, skip the entity entirely. Project directly into a DTO:

@Query("SELECT new com.foo.OrderSummary(o.id, o.total, count(i)) " +
       "FROM Order o LEFT JOIN o.items i GROUP BY o.id")
List<OrderSummary> summaries();

Fix 5 — Second-level cache

For read-heavy reference data (countries, product categories), enable Hibernate's L2 cache so subsequent loads of the same entity hit Redis/Ehcache instead of the DB.

The other extreme — eager-loading horror

Eager @OneToMany sounds tempting ("just load it all once"), but if the parent entity has 5 lazy collections, every parent load fires 5+ queries even when you don't need them. Worse, eager OneToMany forces a JOIN that returns a Cartesian product — loading 100 orders × 10 items each = 1000-row result set, deduped by Hibernate in memory. Default to LAZY everywhere; opt into eager fetching per query.

The "LazyInitializationException" trap

Lazy loading needs an open session. If you fetch an order in the service layer (closes the transaction), then access order.getItems() in the controller layer (no session), Hibernate throws LazyInitializationException. Fixes:

• Initialize what you need inside the transaction (order.getItems().size() forces fetch).
• Use JOIN FETCH in your repository so the data is loaded in one go.
• Avoid OSIV (Open Session In View) — Spring's default. It hides the problem by extending the session through the controller, but encourages N+1 queries during JSON serialization.

How to detect N+1 before production

• Enable SQL logging in tests: spring.jpa.show-sql=true + logging.level.org.hibernate.SQL=DEBUG.
• Use Hypersistence Utils or Datasource Proxy to count queries in tests and fail builds where count > expected.
• Add a load test that exercises list endpoints with realistic dataset sizes.

The lost update — what we're protecting against

Thread A: balance = SELECT balance FROM wallet WHERE id=1;   // reads 500
Thread B: balance = SELECT balance FROM wallet WHERE id=1;   // reads 500
Thread A: UPDATE wallet SET balance = 100 WHERE id=1;        // 500-400=100
Thread B: UPDATE wallet SET balance = 100 WHERE id=1;        // 500-400=100 (B's version of "100")
// Final: 100. Should have been -300 (overdraft) or B's request rejected.

Five strategies, ordered by overhead

Strategy 1 — Atomic single-statement update (best when it fits)

Skip the read entirely. Let the database do the math:

UPDATE wallet
SET balance = balance - 400
WHERE id = 1 AND balance >= 400;
-- check rowsAffected; if 0, insufficient funds

Atomic at the DB level (most engines acquire a row lock for the duration of the UPDATE). No application-level coordination needed. Best for simple counters, balances, stock decrements.

Strategy 2 — Optimistic Locking (version number)

Add a version column. Every update bumps it; updates fail if the version doesn't match what you read. JPA does this automatically with @Version:

@Entity
class Wallet {
    @Id Long id;
    int balance;
    @Version Long version;
}

// Hibernate emits:
UPDATE wallet SET balance=?, version=version+1 WHERE id=? AND version=?;
// rowsAffected = 0 → throw OptimisticLockException → retry the whole transaction

Pros: no locks held; fast under low contention. Cons: you must implement retry logic (typical: retry 3 times with backoff). Good when conflicts are rare (most wallet operations don't collide).

Strategy 3 — Pessimistic Locking (SELECT FOR UPDATE)

Tell the DB "I'm going to update this row — block any other reader/writer until I'm done":

BEGIN;
SELECT balance FROM wallet WHERE id=1 FOR UPDATE;   -- row-level write lock
-- now no one else can read-for-update or write this row until I COMMIT
UPDATE wallet SET balance = balance - 400 WHERE id=1;
COMMIT;

JPA equivalent: @Lock(LockModeType.PESSIMISTIC_WRITE) on the repository method.

Pros: simple to reason about; no retry needed. Cons: serializes access; risk of deadlocks if two transactions lock different rows in different orders; holds a connection longer.

Strategy 4 — Distributed Locks (Redis / ZooKeeper)

When the lock needs to span multiple services or non-DB resources, use a distributed lock manager — Redis with SET NX EX (Redlock), or ZooKeeper ephemeral nodes:

RLock lock = redisson.getLock("wallet:1");
if (lock.tryLock(5, 30, TimeUnit.SECONDS)) {
    try {
        // critical section — across services
    } finally {
        lock.unlock();
    }
}

Strategy 5 — Idempotency keys (request-level)

For payments / API calls: clients include an Idempotency-Key header. The server stores the key + result. If the same key arrives twice (retries, double-clicks), serve the cached result — never apply the operation twice. Doesn't prevent concurrent requests but prevents duplicate effects.

How to choose

Isolation level matters

Even with optimistic locking, READ_COMMITTED (Postgres default) lets the lost update happen if you don't have a version check. REPEATABLE_READ (MySQL InnoDB default) detects the conflict and aborts one transaction. Know your DB's default and pick a strategy that matches.

The four letters

A — Atomicity ("all or nothing")

Either every statement in the transaction succeeds, or none do. A power cut between the debit and the credit must not leave the bank with vanished money.

BEGIN;
UPDATE accounts SET balance = balance - 1000 WHERE id = 'A';   -- step 1
-- 💥 server crashes here
UPDATE accounts SET balance = balance + 1000 WHERE id = 'B';   -- never runs
COMMIT;
-- After recovery: A is back to original balance. The crash rolled back step 1.

How it's achieved: the database writes every change to a write-ahead log (WAL) first. On crash recovery, transactions that didn't reach COMMIT are rolled back from the log.

C — Consistency ("the rules are never broken")

The transaction takes the database from one valid state to another. Constraints (foreign keys, check constraints, unique indexes) are never violated by a committed transaction. In our banking case: the total money in the bank before = total after.

CHECK (balance >= 0)         -- can't go negative
total_money = SUM(balance)   -- invariant: 1000 leaves A, 1000 enters B

How it's achieved: partly the DB (constraints, triggers) and partly your application logic. Consistency is the only ACID property that requires application cooperation.

I — Isolation ("transactions don't see each other's mess")

If Sahil's transfer is running and Anil's balance check reads Account A in the middle, Anil shouldn't see "money has left A but not yet arrived at B." From Anil's perspective, the transfer either hasn't happened or has fully happened.

How it's achieved: row-level locks, multi-version concurrency control (MVCC — each transaction sees a snapshot of the DB at its start time).

D — Durability ("once it's committed, it's permanent")

Once COMMIT returns success, the change must survive crash, power loss, OS reboot. If Anil sees "transfer successful" then yanks the power cord, the money is still moved when the server comes back.

How it's achieved: the WAL is fsync()'d to disk before COMMIT returns. The database may also replicate to a standby before acking the commit (synchronous replication) for stronger durability.

The full transfer in code

@Transactional(isolation = Isolation.REPEATABLE_READ)
public void transfer(String from, String to, BigDecimal amount) {
    int debited = jdbc.update(
        "UPDATE accounts SET balance = balance - ? WHERE id = ? AND balance >= ?",
        amount, from, amount);
    if (debited == 0) throw new InsufficientFundsException();   // C — invariant

    jdbc.update("UPDATE accounts SET balance = balance + ? WHERE id = ?", amount, to);
}
// A — both updates atomic via the surrounding transaction
// I — REPEATABLE_READ ensures consistent view
// D — DB fsyncs WAL before commit returns

How ACID is implemented under the hood

• Write-Ahead Log (WAL). Every change is appended to a sequential log before being applied to the data files. On crash, WAL is replayed to recover.
• Locks + MVCC. Locks for writers; MVCC snapshot for readers — readers never block writers.
• Two-phase commit (2PC). For distributed transactions across multiple databases — phase 1: prepare (everyone vote yes), phase 2: commit. Slow, blocking; modern systems prefer Sagas instead.

The CAP / BASE counterpoint

Not every system needs strict ACID. NoSQL stores like Cassandra or DynamoDB give up isolation/consistency for availability and horizontal scale. They offer BASE — Basically Available, Soft state, Eventual consistency. The trade-off: faster, scalable, but you must handle stale reads and conflicts in your app code.

Step 1 — Run EXPLAIN (or EXPLAIN ANALYZE)

Never optimize blind. Get the query plan first:

EXPLAIN (ANALYZE, BUFFERS)
SELECT o.id, u.name
FROM orders o JOIN users u ON o.user_id = u.id
WHERE o.created_at >= NOW() - INTERVAL '7 days'
ORDER BY o.created_at DESC;

Look for: Seq Scan on a large table (probably needs an index), Nested Loop on big sets (might want a Hash or Merge Join), high actual time on a node, rows estimated vs actual diverging by 10x+ (stale stats — run ANALYZE).

Step 2 — Index the columns in WHERE, JOIN, and ORDER BY

The single most common fix. Indexes turn O(N) sequential scans into O(log N) lookups.

CREATE INDEX idx_orders_created_at ON orders(created_at DESC);
-- DESC matches the ORDER BY direction → no extra sort

• B-tree — default; great for equality, range, and prefix-match LIKE.
• Hash — equality only; rarely worth it.
• GIN — full-text search, JSONB queries, array contains.
• BRIN — block-range; for huge time-series tables where data is naturally ordered.

Step 3 — Composite indexes for multi-column filters

If you query WHERE user_id = ? AND status = 'PAID', a single composite index is far better than two separate indexes:

CREATE INDEX idx_orders_user_status ON orders(user_id, status);
-- Used for: WHERE user_id = ?
-- Used for: WHERE user_id = ? AND status = ?
-- NOT used for: WHERE status = ?    (left column missing)

Order matters: put the most selective column (the one with the most distinct values, used in the most queries) first.

Step 4 — Avoid SELECT *

Selecting only needed columns lets the DB use covering indexes — if all columns the query needs are in the index, it never touches the table:

CREATE INDEX idx_orders_covering ON orders(user_id, status) INCLUDE (total);
-- SELECT total FROM orders WHERE user_id = ? AND status = 'PAID' — never touches the heap

Step 5 — Avoid functions on indexed columns

WHERE LOWER(email) = 'a@b.com';
WHERE DATE(created_at) = '2026-05-10';

CREATE INDEX idx_email_lower ON users(LOWER(email));
-- or rewrite predicate:
WHERE created_at >= '2026-05-10' AND created_at < '2026-05-11';

Step 6 — Pagination — keyset over offset

LIMIT 20 OFFSET 100000 makes the DB scan and discard 100,000 rows. Switch to keyset pagination:

SELECT * FROM orders
WHERE created_at < :lastSeenCreatedAt
ORDER BY created_at DESC
LIMIT 20;

Step 7 — Reduce JOIN cost

• Filter before joining (CTE / subquery) when one side is huge.
• Make sure both sides of a join are indexed on the join key.
• Question the join — do you actually need data from that table, or just an EXISTS check?

Step 8 — Cache the result

If the data changes rarely, cache the query result in Redis with a TTL. A 10ms Redis hit beats a 200ms DB query every time.

Step 9 — Update statistics / rebuild stale indexes

The query planner uses table statistics. If they're stale, plans get bad. Postgres: ANALYZE orders;. MySQL: ANALYZE TABLE orders;. Rebuild bloated indexes occasionally — REINDEX (Postgres) or OPTIMIZE TABLE (MySQL).

Step 10 — Last resort: denormalize / materialized view / read replica

• Materialized view — pre-computed query result, refreshed on a schedule.
• Denormalized columns — store order_count on the user row, updated on insert/delete. Trades write speed for read speed.
• Read replica — offload heavy analytical queries to a follower DB.

The senior-engineer checklist

1. EXPLAIN ANALYZE first — never guess
2. Index the WHERE / JOIN / ORDER BY columns
3. Composite indexes for multi-column predicates (selective column first)
4. Drop SELECT *, prefer covering indexes
5. Avoid functions on indexed columns
6. Keyset pagination, not OFFSET
7. Rewrite N+1 query patterns
8. Cache for read-heavy, slow-changing data
9. Refresh stats; rebuild bloated indexes
10. Denormalize / materialize / replicate when needed

Two pagination styles — pick deliberately

Style 1 — Offset pagination (page + size)

GET /api/products?page=3&size=20&sort=createdAt,desc

// Backend translates to:
SELECT * FROM products ORDER BY created_at DESC LIMIT 20 OFFSET 60;

Pros: users can jump to any page; total page count is easy to compute. Cons: OFFSET 100000 is slow (DB scans 100k rows just to skip them); pages become inconsistent under inserts (if a row is added on page 2 while you're viewing page 3, the next item shifts and you can see duplicates or skip rows).

Style 2 — Keyset / Cursor pagination

GET /api/products?cursor=eyJjcmVhdGVkQXQiOiIyMDI2LTA1LTEwVDA5OjAwOjAwWiIsImlkIjo0Mn0&size=20

// Backend decodes cursor → continues from a specific point
SELECT * FROM products
WHERE (created_at, id) < ('2026-05-10T09:00:00Z', 42)
ORDER BY created_at DESC, id DESC
LIMIT 20;

Pros: always fast (uses index on created_at); stable under inserts. Cons: can't jump to "page 47" — only forward / backward. Cursor must be opaque (base64-encoded JSON) so clients don't depend on its structure.

Why two columns in the cursor? If two rows share created_at (same millisecond), use id as a tiebreaker — otherwise you can skip or duplicate rows at the boundary.

Response shape — include the metadata

{
  "data": [ ... 20 products ... ],
  "pagination": {
    "next_cursor": "eyJ...",
    "prev_cursor": "eyK...",
    "has_more": true
  }
}

{
  "data": [ ... 20 products ... ],
  "page": 3,
  "size": 20,
  "total_elements": 5421,
  "total_pages": 272
}

Sorting — keep it explicit, validate aggressively

Accept a list of sort fields with directions. Whitelist allowed fields — never inject the user's input directly into SQL or JPQL.

private static final Set<String> SORTABLE = Set.of("createdAt", "price", "name");

@GetMapping("/products")
public Page<Product> list(@RequestParam int page,
                          @RequestParam int size,
                          @RequestParam String sort) {
    // "createdAt,desc" → Sort.by(...)
    String[] parts = sort.split(",");
    if (!SORTABLE.contains(parts[0])) throw new BadRequestException();
    return repo.findAll(PageRequest.of(page, size,
        Sort.by(Sort.Direction.fromString(parts[1]), parts[0])));
}

Spring Data Pageable — built-in support

Spring auto-binds a Pageable from query params: ?page=0&size=20&sort=price,desc&sort=name,asc. Your repository method just declares Page<Product> findAll(Pageable p) and you get a paginated result with total count for free.

Default and max sizes

Always cap size. A client requesting size=100000 can DoS your DB. Reasonable defaults: page 0, size 20, max 100. Validate at the controller level.

Filtering — make it composable

Beyond pagination, filters need a contract. Options:

• Per-field query params — simple but limited: ?status=PAID&minPrice=100
• RSQL / Spring Specification — ?filter=status==PAID;price=ge=100
• POST with filter body — for complex queries, accept JSON in request body

Caching pagination responses

Page 1 is often hit hardest. Cache the response keyed by query params + cursor. Invalidate on writes to the entity. For high-cardinality queries (every request unique), don't bother.

What's in a JWT

A JWT is three base64url strings separated by dots: header.payload.signature.

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9                // header  (base64) → {"alg":"HS256","typ":"JWT"}
.eyJzdWIiOiI0MiIsImV4cCI6MTcxNTM0NTk5OX0           // payload (base64) → {"sub":"42","exp":1715345999}
.MEUCIQDxxxxx...                                    // signature — HMAC or RSA over (header + "." + payload)

• Header — algorithm + token type. Don't trust this; pin the algorithm server-side.
• Payload (claims) — user id (sub), expiry (exp), roles, anything you want. Not encrypted — anyone can read it. Don't put secrets here.
• Signature — proof that the server signed it. Anyone who tampers with header or payload invalidates the signature.

The seven-step flow

1. Login. Client POSTs username/password to /auth/login.
2. Server verifies credentials. Looks up user, BCrypt-checks the password.
3. Server signs two tokens.
   • Access token — short-lived (15 min), carries user id + roles, used on every API call.
   • Refresh token — long-lived (7-30 days), used only to get a new access token. Stored in an HttpOnly secure cookie or in a server-side allowlist.
4. Client stores tokens. Web: HttpOnly cookies (XSS-safe) or memory + refresh-via-cookie. Mobile: Keychain (iOS) / EncryptedSharedPreferences (Android).
5. Client sends access token on every request.
   Header

   GET /api/orders
   Authorization: Bearer eyJhbGc...

6. Server validates the token on every request.
   1. Split into header / payload / signature.
   2. Recompute signature using the server's secret (HS256) or public key (RS256). Compare. If mismatch → 401.
   3. Check exp. If past → 401.
   4. Check iss, aud match expected values.
   5. Optionally check a denylist (for revocation — see below).
   6. Extract sub + roles → set Spring Security Authentication → continue to controller.
7. Token expires. Client gets 401, sends refresh token to /auth/refresh, gets a fresh access token. If refresh token also expired → user must log in again.

Spring Security flow — where the code lives

public class JwtAuthFilter extends OncePerRequestFilter {
    @Override
    protected void doFilterInternal(HttpServletRequest req, HttpServletResponse res, FilterChain chain) {
        String header = req.getHeader("Authorization");
        if (header != null && header.startsWith("Bearer ")) {
            String token = header.substring(7);
            try {
                Claims claims = jwtParser.parseClaimsJws(token).getBody();
                Authentication auth = new UsernamePasswordAuthenticationToken(
                    claims.getSubject(), null, rolesFrom(claims));
                SecurityContextHolder.getContext().setAuthentication(auth);
            } catch (JwtException e) { /* 401 */ }
        }
        chain.doFilter(req, res);
    }
}

Algorithm choice — HS256 vs RS256

• HS256 (HMAC-SHA256) — symmetric. The same secret signs and verifies. Simple if all your services share one trusted boundary.
• RS256 (RSA) — asymmetric. Auth server signs with private key, every API server verifies with the public key. Use this when verifiers and issuers are separate teams or services.

The hardest part — revocation

JWTs are stateless, which means once issued, they're valid until exp. If a user logs out or you ban them, you can't really "revoke" a JWT — the signature is still valid. Three approaches:

• Short-lived access tokens (15 min) — accept that revocation takes ≤15 min to propagate.
• Server-side denylist — store revoked token IDs (jti claim) in Redis with TTL = remaining token lifetime. Every request checks the list. Reintroduces the round-trip you were trying to avoid, but only for the denylist.
• Refresh-token rotation — every refresh issues a new refresh token AND invalidates the old one server-side. If a stolen refresh token is used, the attacker and the legitimate user race; one will get logged out, alerting you to the breach.

The dangerous failure modes

• "alg: none" attack — naive libraries trust the header's alg field. If it says none, no signature check is done. Always pin alg server-side.
• HS256 with a public-key secret — leaked, attacker can forge tokens. Rotate your secret regularly.
• JWT in localStorage + XSS — XSS reads the token, attacker has full session. Prefer HttpOnly cookies on web.
• No expiry / very long expiry — stolen token is gold forever. Always set exp.
• Sensitive data in payload — claims are base64, not encrypted. Don't put PII or PAN data in there.

The hierarchy of suspects — fastest to find first

Latency under load is almost always one of these, in this rough order of frequency: (1) database, (2) downstream HTTP call, (3) thread pool / connection pool exhaustion, (4) GC pauses, (5) hot lock contention, (6) actual CPU-bound code.

Step 1 — Look at the metrics dashboard first

Before SSH-ing into pods, check Grafana. Within 60 seconds you should know:

• p50, p95, p99 latency for the slow endpoint — is it tail latency or median?
• Throughput (RPS) — did traffic spike?
• Error rate — are timeouts contributing?
• CPU / memory / GC on the JVM pods
• DB connection pool active vs max — is it pegged?
• Downstream service latency — did a dependency get slow?

Step 2 — Distributed tracing tells you which span is slow

OpenTelemetry / Jaeger / Zipkin / Datadog APM. Pick one slow request, look at the flame chart of spans:

• HTTP handler total: 8s
• JPA query "findOrders": 7.6s ← the smoking gun
• Redis "get user-cache:42": 3ms
• HTTP call to "payment-service": 80ms

The widest span is the bottleneck. No tracing? Add structured logs with timing around suspicious calls.

Step 3 — Database investigation

If the DB is the suspect:

• Slow query log — most DBs log queries above a threshold. Postgres: log_min_duration_statement = 500ms. Find queries that recently got slow.
• EXPLAIN ANALYZE — see section 32 for the full playbook.
• Active queries — Postgres: SELECT * FROM pg_stat_activity WHERE state = 'active' ORDER BY query_start;. Long-running queries blocking the pool?
• Locks — pg_locks for blocked transactions; deadlocks can cascade through a whole connection pool.
• Connection pool saturation — HikariCP active = max means every thread is waiting. Either increase the pool, fix the slow queries holding connections, or shorten transactions.

Step 4 — Thread / connection pool exhaustion

Symptoms: latency suddenly spikes from 50ms to seconds; throughput plateaus despite more load. Causes:

• Tomcat threads (server.tomcat.threads.max default 200) all stuck on a slow downstream → new requests queue.
• HikariCP DB pool size too small for traffic — threads wait for a connection.
• Custom executor with unbounded queue — requests pile up forever, p99 climbs to infinity.

Diagnose: thread dump (jstack <pid> or kill -3). Look at "what are the 200 Tomcat threads doing right now?" — usually they're all parked on the same downstream call.

Step 5 — GC pauses

If p99 has periodic 1-2 second spikes, suspect Stop-The-World GC. Enable GC logs (-Xlog:gc*), graph pause times. Fixes:

• Switch to G1GC or ZGC if you're on Parallel.
• Bump heap if Old Gen is constantly near full.
• Look for memory leaks (section 22) — they cause Full GCs that take seconds.

Step 6 — Lock contention

Symptoms: CPU isn't pegged but throughput plateaus. Cause: synchronized on a hot path. Diagnose with async-profiler in lock mode — produces a flame graph showing where threads spent time blocked. Fix: replace with ConcurrentHashMap, atomic, or finer-grained locks.

Step 7 — CPU profiling (last resort)

If nothing above is the cause, the code itself is slow. Run async-profiler on a live pod for 30s, get a CPU flame graph. The widest tower at the top = the hottest method. Common findings: regex compiled per request, unbounded loop, JSON serialization overhead, log statements in tight loops.

The diagnostic toolkit — every backend engineer should have these handy

Load testing to reproduce

If you can't reproduce in prod, run k6 or JMeter against staging with realistic traffic. Ramp up RPS and watch where latency starts hockey-sticking. That's your saturation point.

The fundamental difference — synchronous vs asynchronous

REST is a synchronous, point-to-point request/response between two services. Caller waits, gets a response, knows the result. Tightly coupled — caller must know the URL of the callee.

Kafka is asynchronous, broker-mediated, pub/sub. Producer writes an event to a topic and moves on. Any number of consumers (now or in the future) can read it. Loosely coupled — producer doesn't know who consumes.

Side-by-side

When REST is right

• You need an immediate answer. "Is this user allowed to log in?" "What's the current price of SKU-42?" The caller can't proceed without the response.
• The operation is a query. Reading data from another service.
• Sync transactional flow. "Reserve seat → confirm payment → email confirmation" — and the user is waiting on the page.
• Simple integrations. One client, one server, low traffic — Kafka would be overkill.

When Kafka is right

• Fan-out. "Order placed" → email service, analytics, fraud detection, inventory, recommendations all need to know. With REST, the order-service makes 5 HTTP calls and is coupled to all 5. With Kafka, it publishes once and doesn't care who listens.
• The producer doesn't need a response. "Track this user click" — fire and forget.
• Decoupled scaling. The producer wants to ingest 100k events/sec; the consumer can only process 10k/sec; let the topic buffer the rest.
• Durability requirement. If the email service is down for 2 hours, you don't want to lose those order events — Kafka holds them safely until consumers catch up.
• Replay / reprocessing. A bug in the analytics consumer? Rewind the offset and re-process the last 24 hours.
• Audit / event-sourcing. The full history of every state change is the source of truth — Kafka topics with retention = forever.

Vivek's order → email decision

Email is fan-out (other services also care about "order placed"), the user isn't waiting for the email to arrive, and email-service downtime shouldn't fail order placement. Kafka wins.

But the order placement itself? "User clicks Place Order → API returns success" — the API needs an immediate response, the order must be confirmed before the page shows "Thank you". REST/synchronous DB write wins for the placement.

The hybrid pattern — outbox

The classic problem: how do you atomically (a) save the order to the DB and (b) publish to Kafka? If the publish fails after the DB commit, you've lost the event. If the DB rolls back after publishing, you've published a phantom event.

The Transactional Outbox pattern: in the same DB transaction, write the order AND write an "event row" to an outbox table. A separate background worker (or Debezium) reads the outbox and publishes to Kafka, then deletes/marks the row. Atomic by virtue of the DB transaction.

What Kafka costs you

• Eventual consistency. Producer commits at T=0, consumer processes at T=200ms. The world is briefly inconsistent. Embrace this or pick REST.
• Operational complexity. Kafka cluster, ZooKeeper / KRaft, monitoring, partitions, consumer-group lag — vs a single HTTP call.
• Schema evolution headaches. If a producer changes the event format, every consumer breaks. Use Avro/Protobuf with a Schema Registry to enforce backward compatibility.
• Idempotency on consumers. Kafka delivers at-least-once by default. Same event might arrive twice. Consumers must be idempotent (e.g., check "already processed?" before applying).

The naive Dockerfile (works, but bad)

FROM openjdk:17
COPY target/app.jar /app.jar
ENTRYPOINT ["java", "-jar", "/app.jar"]

Problems: (1) the base image is the full OpenJDK distribution (~600MB). (2) Every code change invalidates the cache and re-uploads the entire fat JAR. (3) The container runs as root — security risk.

Production Dockerfile — multi-stage, layered, non-root

# --- Stage 1: build with full JDK ---
FROM eclipse-temurin:17-jdk-alpine AS builder
WORKDIR /build
COPY pom.xml .
RUN mvn dependency:go-offline -B    # cached unless pom.xml changes
COPY src src
RUN mvn package -DskipTests -B

# Extract Spring Boot's layered jar (layers change at different rates)
RUN java -Djarmode=layertools -jar target/app.jar extract --destination extracted

# --- Stage 2: runtime image — JRE only ---
FROM eclipse-temurin:17-jre-alpine
WORKDIR /app

# Run as non-root user
RUN addgroup -S spring && adduser -S spring -G spring
USER spring:spring

# Copy each layer separately — Docker caches layers individually
COPY --from=builder /build/extracted/dependencies/ ./
COPY --from=builder /build/extracted/spring-boot-loader/ ./
COPY --from=builder /build/extracted/snapshot-dependencies/ ./
COPY --from=builder /build/extracted/application/ ./       # your code — changes most

EXPOSE 8080
ENTRYPOINT ["java", "org.springframework.boot.loader.JarLauncher"]

Why multi-stage matters

The build stage has Maven, the JDK, source code, test fixtures — gigabytes of stuff you don't need at runtime. The final runtime image only has the JRE + your compiled JAR layers. Final image: 200MB instead of 1GB+.

Why layered JARs matter (Spring Boot 2.3+)

A fat JAR rebuilt for a one-line code change re-uploads 60MB. With layered JARs, only the application layer (your BOOT-INF/classes) changes — typically 1MB. Pull/push of new images becomes nearly instant.

Three runtime essentials

1. Run as non-root

If your container is exploited, the attacker shouldn't have root inside it. Add USER spring:spring.

2. Tune the JVM for containers

Java 11+ honors container CPU/memory limits automatically (UseContainerSupport on by default). But explicitly set max heap as a percentage of container memory:

ENV JAVA_OPTS="-XX:MaxRAMPercentage=75 -XX:+UseG1GC -XX:+ExitOnOutOfMemoryError"
ENTRYPOINT ["sh", "-c", "java $JAVA_OPTS org.springframework.boot.loader.JarLauncher"]

Why 75%? Reserves 25% for direct buffers, metaspace, thread stacks — the heap is not the only memory the JVM uses.

3. Health checks

Add Spring Boot Actuator. Then in Docker / Kubernetes:

livenessProbe:  { httpGet: { path: /actuator/health/liveness,  port: 8080 } }
readinessProbe: { httpGet: { path: /actuator/health/readiness, port: 8080 } }

The .dockerignore — don't ship junk

target/
.idea/
.git/
*.iml
.vscode/
node_modules/
.env

Even simpler — Buildpacks

Spring Boot ships built-in support: ./mvnw spring-boot:build-image uses Cloud Native Buildpacks to produce an optimized image — no Dockerfile to maintain, layered automatically, secure base image, sensible JVM defaults. Great for teams that don't want to babysit Dockerfiles.

Configuration via environment variables

Spring Boot maps env vars to properties: SPRING_DATASOURCE_URL → spring.datasource.url. Bake nothing environment-specific into the image. Same image runs in dev/staging/prod, configured by env.

Image security checklist

• Use a specific base-image tag (eclipse-temurin:17.0.10_7-jre-alpine) — never latest.
• Scan with Trivy / Snyk in CI; fail builds on Critical CVEs.
• Run as non-root.
• Minimize layers — fewer surface area, smaller images.
• Don't bake secrets into the image. Inject at runtime via env or a secrets manager.

The patterns, in the order you should reach for them

1. Timeouts — the absolute baseline

Every outbound call MUST have a timeout. The default in many HTTP clients is "infinite" — that's how you get the cascade Aditya saw.

WebClient.builder()
    .clientConnector(new ReactorClientHttpConnector(
        HttpClient.create().responseTimeout(Duration.ofSeconds(2))))
    .build();

Pick timeouts based on the dependency's p99 + headroom. Payment service p99 of 500ms? Set 1s timeout, not 30s.

2. Retries — for transient failures only

Network blips, brief 503s, momentary timeouts — retry once or twice with exponential backoff. Never retry non-idempotent calls without an idempotency key — you'll double-charge customers.

@Retry(name = "paymentService", fallbackMethod = "fallback")
public PaymentResult charge(Order o) { ... }

# application.yml
resilience4j.retry.instances.paymentService:
  maxAttempts: 3
  waitDuration: 200ms
  exponentialBackoffMultiplier: 2
  retryExceptions: [java.io.IOException, org.springframework.web.client.HttpServerErrorException]

3. Circuit Breaker — stop calling a sick service

If payment-service is failing 50% of calls in the last 30 seconds, calling it more just makes things worse. Circuit breakers track recent failure rate; once it crosses a threshold, the breaker "opens" and calls fail fast (without even trying) for a cool-down period. After cool-down, it allows a few "half-open" trial calls; if they succeed, it closes back to normal.

@CircuitBreaker(name = "paymentService", fallbackMethod = "fallback")
public PaymentResult charge(Order o) { ... }

public PaymentResult fallback(Order o, Throwable t) {
    return PaymentResult.queuedForRetry(o);
}

Three states: CLOSED (normal) → OPEN (fail fast) → HALF_OPEN (trial) → CLOSED.

4. Bulkhead — isolate resource pools

Picture a ship: if one compartment floods, watertight bulkheads stop it from sinking the whole vessel. Same principle: dedicate a thread pool / connection pool per downstream so one slow dependency can't starve the others. Resilience4j's @Bulkhead caps concurrent calls per backend.

5. Fallback — graceful degradation

When the call fails, return something useful instead of an error:

• Cached previous response.
• Default / safe value ("you have 0 unread notifications" instead of a spinner forever).
• Queue the request for later processing ("we'll email you when it's done").

6. Idempotency — make retries safe

If a call might be retried (by you, by the load balancer, by a queue), the receiver must handle duplicate requests safely. Pattern: client sends an Idempotency-Key header; receiver stores key + result; on duplicate, returns the cached result. Used by Stripe, PayPal, every serious payment API.

7. Async messaging — the strongest decoupling

If the call doesn't need an immediate response, switch from REST to Kafka. The producer publishes; the consumer processes when it can. The producer never blocks on consumer health. See section 36 for when this is the right move.

The cascade-prevention checklist

Service-mesh alternatives (Istio, Linkerd)

Modern infra moves these patterns out of code into a sidecar proxy. The mesh adds timeouts, retries, circuit breakers, mTLS at the network layer — your app stays focused on business logic. Trade-off: more infra to operate.

Don't forget the outbound side too

If you're a service being called, advertise your contract: documented SLOs, idempotency support, rate limits. Make it easy for callers to be resilient against you.

Observability is non-negotiable

None of these patterns are useful without metrics. You need to see: circuit-breaker state per dependency, retry counts, fallback invocations, downstream latencies. Wire Resilience4j to Micrometer → Prometheus → Grafana.

These are the questions where interviewers smile when you nail them — they reveal whether you've actually shipped Java in production or just memorized a textbook.

1. finally runs even after return

int tricky() {
    try {
        return 1;
    } finally {
        System.out.println("finally");   // PRINTS "finally"
        // return 2;  // BAD — would override return 1
    }
}
// Output: "finally", returns 1.

2. Autoboxing in collections

list.remove(2) on a List<Integer> — does it remove the element at index 2 or the element with value 2?

Index 2! Because List has both remove(int index) and remove(Object o), and the primitive int matches the index version. To remove by value: list.remove(Integer.valueOf(2)).

3. Static method "overriding"

Static methods cannot be overridden — only hidden. A child class declaring static foo() doesn't override the parent's static foo(); it shadows it. Calls resolve at compile time based on the reference type, not the runtime object.

4. String.intern() moves a string into the pool

Useful for deduplication when reading millions of strings from a file. But: don't intern user input — the pool is a permanent area (well, GC'd in modern JVMs but expensive), and an attacker filling it with garbage = denial of service.

5. The diamond problem with default methods

Java 8 allowed interfaces to have default methods. What if a class implements two interfaces with the same default method? You MUST override and pick: InterfaceA.super.method();

6. Constructor of an inner class secretly captures the outer

A non-static inner class holds an implicit reference to its enclosing instance. If the inner is long-lived (e.g., stored in a static map or sent to an executor), the outer can't be GC'd → memory leak. Solution: use a static nested class when no enclosing reference is needed.

7. HashMap iteration order is not insertion order

Insertion order is not preserved in HashMap. If you need it, use LinkedHashMap. If you need sorted order, use TreeMap.

8. SimpleDateFormat is NOT thread-safe

The classic 2009-era bug. Sharing a SimpleDateFormat across threads silently corrupts dates. Use DateTimeFormatter (Java 8+) — it's immutable and thread-safe.

9. equals on arrays compares references, not contents

arr1.equals(arr2) is arr1 == arr2. Use Arrays.equals(arr1, arr2) for element-wise comparison, Arrays.deepEquals for nested arrays.

10. Integer i = null; int x = i; throws NullPointerException

Auto-unboxing a null wrapper throws NPE — a classic source of "where did this NPE come from?" debugging. Always null-check wrappers before auto-unboxing.