Java Interview Questions
and answers with code.

JVM is the Java Virtual Machine that executes bytecode. JRE is the JVM plus the standard libraries needed to run Java programs. JDK is the JRE plus the compiler (javac) and development tools like javadoc and jdb.

• You need the JDK to write and compile Java.
• You need only the JRE to run a compiled Java program.
• The JVM is what makes Java platform-independent — the same bytecode runs on any OS that has a JVM.

Java source is compiled to bytecode (a platform-neutral intermediate format), not to native machine code. Any system with a JVM can run that bytecode. This is the "write once, run anywhere" idea.

The signature is:

public static void main(String[] args)

It is static because the JVM must call it without creating an instance of the class. It is public so the JVM can access it from outside the class. It returns void because nothing is expected back. String[] args holds any command-line arguments.

Java has eight primitive types:

Autoboxing is the automatic conversion of a primitive to its wrapper class (for example int to Integer). Unboxing is the reverse — a wrapper object converted back to its primitive type.

Integer a = 100;      // autoboxing: int → Integer
int b = a;            // unboxing: Integer → int
System.out.println(b + 1);  // 101

101

String is immutable — every change creates a new object. StringBuilder is mutable and not thread-safe, used inside a single thread. StringBuffer is mutable and thread-safe (methods are synchronized), used when the same builder is shared across threads.

String immutability gives Java three practical benefits:

• Security — a String used as a file path, class name or database URL cannot be changed after validation.
• Caching — the string pool can safely share identical string literals between parts of the program.
• Thread safety — immutable objects can be shared freely across threads without synchronization.

The string pool is a special area of the heap where Java stores string literals. When you write "hello" twice, both references point to the same pooled object. Strings created with new String(...) are not pooled unless you call .intern().

String a = "java";
String b = "java";
String c = new String("java");

System.out.println(a == b);           // true  (same pooled object)
System.out.println(a == c);           // false (new object on heap)
System.out.println(a.equals(c));     // true  (same characters)

true
false
true

== compares references (for objects) or values (for primitives). .equals() compares the logical content of two objects, as defined by the class.

String s1 = "hello";
String s2 = new String("hello");
System.out.println(s1 == s2);         // false
System.out.println(s1.equals(s2));   // true

false
true

The contract says: if two objects are equal according to equals(), they must return the same hashCode(). The reverse is not required — unequal objects can still share a hash code (that is a collision).

If you break this contract by overriding only equals(), then putting such objects into a HashMap or HashSet leads to duplicate keys or lost lookups.

Encapsulation, inheritance, polymorphism and abstraction.

• Encapsulation — bundling data and methods, hiding internals behind access modifiers.
• Inheritance — a subclass extends a superclass and inherits its members.
• Polymorphism — the same method name behaves differently depending on the object (compile-time via overloading, runtime via overriding).
• Abstraction — exposing only what the caller needs, hiding implementation detail behind interfaces or abstract classes.

Overloading is compile-time polymorphism — the same method name with different parameter lists, in the same class or across a hierarchy. Overriding is runtime polymorphism — a subclass provides its own implementation of a method it inherits.

An abstract class can hold state (fields), constructors and any mix of abstract and concrete methods. An interface defines a contract — since Java 8 it can also contain default and static methods, and since Java 9 private helper methods.

final is a keyword that prevents change — a final variable cannot be reassigned, a final method cannot be overridden, a final class cannot be extended.

finally is a block that runs after a try-catch regardless of whether an exception was thrown. Used to release resources.

finalize() was a method the garbage collector called before reclaiming an object. It is deprecated — use try-with-resources or Cleaner instead.

static means the member belongs to the class, not to any instance. A static variable is shared by all instances. A static method can be called without creating an object. A static block runs once when the class is first loaded.

class Counter {
    static int count = 0;
    Counter() { count++; }
}

public class Demo {
    public static void main(String[] args) {
        new Counter();
        new Counter();
        System.out.println(Counter.count);  // 2
    }
}

2

Java has four access levels, from most to least restrictive:

Constructor chaining is calling one constructor from another, either within the same class using this(...) or from the superclass using super(...). It removes duplication when several constructors share initialisation logic.

class Student {
    String name;
    int age;

    Student() {
        this("Unknown", 0);   // calls the 2-arg constructor
    }
    Student(String name, int age) {
        this.name = name;
        this.age = age;
    }
}

Checked exceptions extend Exception but not RuntimeException. The compiler forces you to either catch them or declare them with throws. Examples: IOException, SQLException.

Unchecked exceptions extend RuntimeException. They are usually programming errors — NullPointerException, ArrayIndexOutOfBoundsException, IllegalArgumentException. The compiler does not force you to handle them.

Throwable
 ├── Error
 └── Exception
      ├── RuntimeException      // unchecked
      └── IOException, SQLException, ...  // checked

try-with-resources automatically closes any resource that implements AutoCloseable at the end of the block, even if an exception is thrown. It replaces the old finally { close(); } pattern and removes a common source of bugs.

try (BufferedReader br = new BufferedReader(new FileReader("data.txt"))) {
    System.out.println(br.readLine());
} catch (IOException e) {
    e.printStackTrace();
}   // br.close() is called automatically

ArrayList is backed by a resizable array — fast random access, slow inserts or deletions in the middle because elements must shift. LinkedList is a doubly-linked list — fast inserts and deletions at the ends, slow random access because it must walk the list.

A HashMap stores entries in an array of buckets. When you put(key, value), Java computes key.hashCode(), spreads the bits (XOR with >>> 16), and maps the result to a bucket index using (n - 1) & hash.

• If the bucket is empty, the entry is stored directly.
• If the bucket already has entries, they are compared with equals(). Equal keys overwrite the value; unequal keys are stored in the same bucket.
• When a bucket exceeds 8 entries and the table is at least 64 slots, the chain converts to a red-black tree, giving O(log n) lookup instead of O(n).
• When the map exceeds 75% of the array size (load factor 0.75), it doubles the array and rehashes all entries.

HashMap is not thread-safe, allows one null key and multiple null values, and is faster. Hashtable (legacy, still present) is synchronized — every method is synchronized — does not allow nulls, and is slower. For new code, prefer ConcurrentHashMap over Hashtable when you need thread safety.

ConcurrentHashMap is a thread-safe map designed for concurrent reads and writes. In modern Java it uses per-bin locking with CAS operations rather than locking the whole map, so reads are non-blocking and writes only lock the affected bucket.

• No null keys or values (throws NPE).
• Reads scale well; writes have minimal contention.
• Preferred over Collections.synchronizedMap() for high-traffic caches.

All three implement Map, but they order keys differently:

A fail-fast iterator throws ConcurrentModificationException if the collection is modified structurally while iterating. Iterators from ArrayList, HashMap and HashSet are fail-fast.

A fail-safe iterator iterates over a snapshot or a concurrent view and does not throw. Iterators from ConcurrentHashMap and CopyOnWriteArrayList are fail-safe, but they may not reflect updates made after iteration started.

Generics let you write classes, interfaces and methods that work on a type provided at use-time, with compile-time type safety. Before generics, you had to cast and could get a ClassCastException at runtime.

// Without generics — runtime risk
List list = new ArrayList();
list.add("hello");
Integer i = (Integer) list.get(0);   // ClassCastException at runtime

// With generics — compile-time check
List<String> names = new ArrayList<>();
names.add("hello");
// names.add(1); // compile error — safer

A functional interface has exactly one abstract method. It can also contain any number of default and static methods. The @FunctionalInterface annotation tells the compiler to enforce this.

Common examples:

• Runnable — void run()
• Callable<V> — V call()
• Comparator<T> — int compare(T, T)
• Function<T,R>, Predicate<T>, Supplier<T>, Consumer<T> — from java.util.function

A lambda is a compact way to implement a functional interface. Instead of writing an anonymous class, you write parameters, an arrow ->, and the body.

// Anonymous class
Runnable r1 = new Runnable() {
    public void run() { System.out.println("run"); }
};

// Lambda
Runnable r2 = () -> System.out.println("run");
r2.run();

run

The Stream API lets you process collections declaratively — filter, map, sort, reduce and collect — often in a single chained expression. Streams do not modify the source collection; they return new results.

List<String> names = List.of("Ravi", "Anita", "Sam", "Priya");

List<String> result = names.stream()
        .filter(n -> n.length() > 3)
        .map(String::toUpperCase)
        .sorted()
        .collect(Collectors.toList());

System.out.println(result);

[ANITA, PRIYA, RAVI]

Intermediate operations (filter, map, sorted, distinct, limit) return a new stream and are lazy — nothing runs until a terminal operation is called. Terminal operations (collect, forEach, reduce, count, anyMatch) end the stream and produce a result.

Optional<T> is a container that may or may not hold a value. It makes the possibility of absence explicit in a method signature, replacing the habit of returning null and hoping the caller checks.

Optional<String> name = Optional.ofNullable(findName());
System.out.println(name.orElse("Guest"));
System.out.println(name.map(String::toUpperCase).orElse("NONE"));

A method reference is shorthand for a lambda that only calls an existing method. The syntax is ClassName::methodName. There are four kinds:

• Static — Integer::parseInt
• Instance of a particular object — System.out::println
• Instance of an arbitrary object — String::toUpperCase
• Constructor — ArrayList::new

The java.time package replaced the old Date and Calendar classes. The main types are:

• LocalDate — a date without time or zone.
• LocalTime — a time without date or zone.
• LocalDateTime — date and time, no zone.
• ZonedDateTime — date and time with a time zone.
• Instant — a point on the timeline, used for timestamps.
• Duration and Period — amounts of time.

All of these are immutable and thread-safe, unlike the old classes.

A process is an independent program with its own memory space. A thread is a lighter unit of execution inside a process — threads in the same process share the heap but have their own stack and program counter.

Because threads share memory, communicating between them is fast, but it also means you need synchronization to avoid race conditions.

Thread is a class; Runnable is an interface. Extending Thread uses your one inheritance slot, so you cannot extend any other class. Implementing Runnable keeps the class free to extend something else and separates the task from the thread that runs it.

Runnable task = () -> System.out.println("running");
Thread t = new Thread(task);
t.start();

running

synchronized ensures that only one thread at a time can execute the marked block or method for a given lock (usually the object instance or the class). It gives both mutual exclusion and a memory barrier, so changes made inside the block are visible to other threads that later acquire the same lock.

For heavy concurrent workloads, prefer java.util.concurrent classes such as ReentrantLock, AtomicInteger or ConcurrentHashMap over manual synchronized blocks.

synchronized provides both mutual exclusion and visibility. volatile provides only visibility — it guarantees that reads and writes go straight to main memory and are seen by other threads, but it does not prevent multiple threads from interleaving.

Use volatile for a simple flag or a single reference that is written by one thread and read by many. Use synchronized when you need atomic compound operations.

ExecutorService is a higher-level replacement for spawning threads manually. You submit tasks and it manages a pool of worker threads, a queue, and lifecycle.

ExecutorService pool = Executors.newFixedThreadPool(3);
Future<Integer> f = pool.submit(() -> 2 + 3);
System.out.println(f.get());   // 5
pool.shutdown();

5

Deadlock happens when two or more threads wait on locks that each other hold, so none can proceed. It requires four conditions at once: mutual exclusion, hold-and-wait, no preemption, circular wait.

Practical ways to avoid deadlock:

• Always acquire locks in a fixed global order.
• Use tryLock() with a timeout instead of blocking forever.
• Keep lock scope small — do not call out to other services while holding a lock.
• Prefer concurrent collections and atomic classes over multiple manual locks.

Serialization converts an object into a byte stream so it can be saved to a file or sent over a network. The reverse is deserialization. A class must implement java.io.Serializable (a marker interface with no methods).

• Use the transient keyword to skip a field (for example, a password).
• Fields declared static are not serialized (they belong to the class, not the instance).
• Declare a private static final long serialVersionUID to control version compatibility.

The Java Memory Model defines how threads interact through memory and what guarantees exist for visibility and ordering of operations.

The JVM divides memory into these areas:

• Heap — objects and their instance variables, shared across threads. Split into young generation (Eden + Survivor) and old generation.
• Stack — one per thread. Holds local variables, method call frames and partial results.
• Metaspace — class metadata (replaced PermGen from Java 8).
• PC Register — per-thread, holds the address of the current instruction.
• Native Method Stack — for native (non-Java) method calls.

Garbage collection frees heap memory occupied by objects that are no longer reachable from any live reference. Reachability is traced from GC roots — thread stacks, static fields, JNI references.

Common collectors in modern JVMs:

• G1 — the default from Java 9 onward. Divides the heap into regions and prioritises regions with the most garbage.
• ZGC and Shenandoah — low-pause collectors designed for very large heaps.
• Parallel — high-throughput; used historically for batch workloads.

You can tune heap size with -Xms and -Xmx, and choose a collector with -XX:+UseG1GC, -XX:+UseZGC and similar flags.

A shallow copy copies the object's fields, but reference fields still point to the same nested objects as the original. A deep copy recursively copies nested objects, so the copy is fully independent.

• Shallow copy: Object.clone() by default, or Arrays.copyOf for primitive arrays.
• Deep copy: manual copy constructors, serialization round-trip, or third-party libraries such as ModelMapper.

Comparable defines the "natural ordering" of a class via compareTo() — one sort order for the class. Comparator is an external comparison strategy, so you can define many orders without changing the class.

List<Employee> staff = new ArrayList<>();

// Natural order (Comparable) — by name
Collections.sort(staff);

// Custom order (Comparator) — by salary descending
staff.sort(Comparator.comparingDouble(Employee::getSalary).reversed());

A record (Java 16, standard) is a compact declaration for immutable data carriers. The compiler generates the constructor, accessors, equals(), hashCode() and toString().

public record Point(int x, int y) { }

Point p = new Point(3, 4);
System.out.println(p.x() + "," + p.y());   // 3,4

3,4

Use records for DTOs, API responses, value objects and small immutable groupings. Do not use them where you need mutable fields, inheritance or a lot of custom behaviour.

var (Java 10) lets the compiler infer the type of a local variable from its initialiser. It is still statically typed — no dynamic typing is involved.

var list = new ArrayList<String>();
var count = 100;
// var x; // compile error — no initialiser

Use var when the right-hand side makes the type obvious. Avoid it when the type is unclear, and never use it for method parameters or return types.

A sealed class or interface (Java 17, standard) can only be extended or implemented by a fixed, declared set of classes. This gives you controlled inheritance and better exhaustiveness checks with pattern matching.

public sealed interface Shape
        permits Circle, Square { }

public record Circle(double radius) implements Shape { }
public record Square(double side)   implements Shape { }

ClassNotFoundException is a checked exception raised at runtime when you explicitly try to load a class by name (for example Class.forName()) and it is not on the classpath. The application can catch and recover.

NoClassDefFoundError is a JVM error raised when the class was present at compile time but is missing or failed to initialise at runtime. It usually indicates a broken deployment or a failed static initialiser.

In Java, a + b on strings is compiled to StringBuilder.append() for that single expression. Inside a loop, however, string concatenation with += creates a new StringBuilder each iteration and copies characters, so it becomes O(n²). Using one StringBuilder across the loop is O(n).

String s = "";
for (int i = 0; i < 10000; i++) {
    s += i;                      // creates a new builder each time
}

// Better
StringBuilder sb = new StringBuilder();
for (int i = 0; i < 10000; i++) {
    sb.append(i);
}
String result = sb.toString();

An inner class (non-static nested) holds an implicit reference to the enclosing instance, so it can access its members directly. A static nested class does not hold that reference and behaves like a top-level class scoped inside another class.

Because the inner class keeps the enclosing instance alive, it can cause memory leaks if instances of the inner class outlive the outer. Prefer static nested classes unless you truly need access to the outer instance.

A Java memory leak happens when objects are no longer needed but are still strongly reachable, so the garbage collector cannot free them. Over time the heap fills, GC runs constantly, and the JVM eventually throws OutOfMemoryError.

Common causes:

• Static collections that keep growing.
• Listeners or callbacks registered but never removed.
• Long-lived caches without eviction.
• Inner class instances holding the outer reference.

Detect leaks with heap dumps and tools like Eclipse MAT, VisualVM or JProfiler. Look for the class with the most retained bytes and trace back to its GC root.

JDBC (Java Database Connectivity) is the standard API for connecting Java to relational databases. The main steps are:

1. Load the driver (in modern JDBC 4+, this is automatic if the driver is on the classpath).
2. Open a Connection using a URL, username and password.
3. Create a PreparedStatement and bind parameters (never concatenate strings — that invites SQL injection).
4. Execute and read the ResultSet.
5. Close everything in a try-with-resources block, or use a connection pool such as HikariCP.

String sql = "SELECT id, name FROM users WHERE age > ?";
try (Connection conn = dataSource.getConnection();
     PreparedStatement ps = conn.prepareStatement(sql)) {
    ps.setInt(1, 18);
    try (ResultSet rs = ps.executeQuery()) {
        while (rs.next()) {
            System.out.println(rs.getInt("id") + " " + rs.getString("name"));
        }
    }
}

Statement executes a plain SQL string — convenient but not safe for user input. PreparedStatement pre-compiles SQL and lets you bind parameters — safer and faster when executed many times. CallableStatement calls stored procedures and functions on the database.

Strong — the default. An object with a strong reference is not collected until that reference goes away. Soft — collected only when memory is low; useful for caches. Weak — collected on the next GC cycle if nothing else holds a strong reference; used by WeakHashMap and listener registries.

Five rules to make a class immutable:

1. Declare the class final so it cannot be subclassed.
2. Make all fields private final.
3. Do not provide setters.
4. Initialise fields only in the constructor.
5. For mutable fields (like a List or Date), return defensive copies on get, and copy incoming values on set.

Records give you most of this for free when fields are simple, but you still need defensive copies for mutable field types.

Step 1 — Confirm it is CPU and not I/O wait. Check top or the container metrics for CPU vs load average.

Step 2 — Take a thread dump with jstack <pid> or jcmd <pid> Thread.print. Look for threads in RUNNABLE state that appear repeatedly.

Step 3 — If the same method shows up across many thread dumps, that is your hot path. Profile it with Java Flight Recorder or async-profiler to see whether it is your code, a library, or GC.

Step 4 — Check GC logs. High CPU can come from constant young-gen collections when allocation is high. The fix may be to reduce allocation, not to add CPUs.

Step 5 — Check for a retry storm or thread pool exhaustion calling downstream services. Bulkheads and timeouts often resolve a "high CPU" that is really a back-pressure problem.

Step 1 — Enable heap dumps on OOM with -XX:+HeapDumpOnOutOfMemoryError and -XX:HeapDumpPath. The next occurrence gives you evidence.

Step 2 — Open the dump in Eclipse MAT or VisualVM. Sort by retained size, then look at the dominator tree.

Step 3 — If the biggest consumer is a growing HashMap or ArrayList held by a static field or a long-lived cache, you have a leak. Either add eviction or clear the reference.

Step 4 — If no single object dominates, allocation is just too high. Reduce object creation, stream large results instead of loading them, and consider off-heap storage.

Step 1 — Take a thread dump. The JVM often prints "Found one Java-level deadlock" and lists the threads with their waiting locks and held locks.

Step 2 — Identify the two locks and the order in which each thread acquired them. Deadlock almost always comes from inconsistent lock ordering.

Step 3 — Fix by enforcing a global lock order, or replace the two locks with a single coarser lock, or use tryLock() with a timeout so one thread backs off.

Step 4 — Add a test that spawns the same workload and asserts no deadlock in CI, so the fix does not regress.

Step 1 — Suspect shared mutable state. Look for fields in a @Service or @Controller that are not thread-safe — a HashMap field, an unsynchronized counter, a shared SimpleDateFormat.

Step 2 — Check whether the service is a singleton (the Spring default) and whether the field is truly read-only. If not, it must be a local variable or a thread-safe structure.

Step 3 — Look for missing transactions. Two threads reading and writing the same row without isolation can produce impossible numbers.

Step 4 — Reproduce with a load test (JMeter, Gatling or k6) and a fixed seed. Consistency bugs must be reproduced before they can be fixed confidently.

Step 1 — Read the GC logs. You want the pause duration, frequency and how much is being collected.

Step 2 — If young-gen collections are frequent and short, the problem is allocation rate. Reduce object creation in hot paths — avoid unnecessary boxing, string concatenation and collection copies.

Step 3 — If full GCs are happening often, you may have a leak. Take a heap dump and investigate.

Step 4 — If the heap is large and pauses matter more than throughput, switch to a low-pause collector like ZGC or Shenandoah, and tune heap size and pause goals.

Step 1 — Add timing logs around the top-level call and around each sub-step. Find which step accounts for the 20 seconds. Do not guess — measure.

Step 2 — If the slow step is a database query, run it directly with EXPLAIN and check indexes, row counts and whether N+1 queries have crept in.

Step 3 — If the slow step is a remote call, check the timeout, retry policy and whether it is inside a loop. Batching, caching and parallelising independent calls are common fixes.

Step 4 — If the slow step is CPU-bound Java code, attach a profiler. Look for repeated work that can be hoisted out of loops, unnecessary sorting, or string building inside a loop.

Step 1 — Check statistics and indexes. Developers often have more indexes locally, or fresher statistics, than production.

Step 2 — Check the query plan in both environments. The same SQL can produce different plans on different data distributions.

Step 3 — Check for competing load. The query may be fine in isolation but starved by other long-running queries or lock contention.

Step 4 — Check bind variable types and implicit conversions. A varchar column compared to a number can disable an index and scan the whole table.

Use a parallel stream when you can live with the default ForkJoinPool and the task is CPU-bound — the results of map preserve order when collected with toList().

For I/O-bound work, do not use parallel streams. Use an ExecutorService and submit tasks in order, collect the Future objects in a list, and call get() in the original order. That preserves order while still running the work in parallel.

ExecutorService pool = Executors.newFixedThreadPool(8);
List<Future<String>> futures = new ArrayList<>();
for (String input : inputs) {
    futures.add(pool.submit(() -> process(input)));
}
List<String> ordered = new ArrayList<>();
for (Future<String> f : futures) ordered.add(f.get());
pool.shutdown();

The cleanest thread-safe singleton is an enum — the JVM guarantees a single instance and it is safe against reflection and serialization attacks.

public enum AppConfig {
    INSTANCE;

    private final Map<String, String> settings = new HashMap<>();

    public void put(String k, String v) { settings.put(k, v); }
    public String get(String k) { return settings.get(k); }
}

If you must use a class (for inheritance reasons), use the holder pattern — lazy, thread-safe and no synchronization cost:

public class AppConfig {
    private AppConfig() { }

    private static class Holder {
        private static final AppConfig INSTANCE = new AppConfig();
    }
    public static AppConfig getInstance() { return Holder.INSTANCE; }
}

IoC means the framework, not your code, controls object creation and lifecycle. DI is how IoC is implemented — the framework supplies the dependencies a class needs, instead of the class constructing them itself.

This reduces coupling: your service depends on an interface, and Spring injects whichever implementation is configured.

It is a convenience annotation that combines three others:

• @Configuration — the class can define beans.
• @EnableAutoConfiguration — Spring Boot auto-configures beans based on the dependencies on the classpath.
• @ComponentScan — scans the package of the annotated class and its sub-packages for components.

All four register a class as a Spring bean. The difference is semantic — they help the reader understand the role of each class, and in two cases they add behaviour.

@Autowired can be applied to a field, setter or constructor. Field injection is simple but makes testing harder and hides the real dependencies of a class.

Constructor injection makes dependencies explicit, allows final fields, and makes the class trivially testable without a Spring context. Modern Spring code prefers constructor injection. If there is only one constructor, @Autowired is optional on it.

@Controller marks a class as a web controller and typically returns a view name. @RestController is @Controller plus @ResponseBody — the return value of each method is serialized directly as the HTTP response body (usually JSON via Jackson).

@RestController
@RequestMapping("/api/users")
public class UserController {

    private final UserService service;
    public UserController(UserService service) { this.service = service; }

    @GetMapping("/{id}")
    public User getUser(@PathVariable Long id) {
        return service.findById(id);
    }
}

Profiles let you define different bean configurations and properties for different environments — dev, test, staging, prod. You activate a profile with spring.profiles.active=dev in application.properties, as a command-line argument, or as an environment variable.

@Configuration
@Profile("dev")
public class DevDataSourceConfig { /* in-memory DB */ }

@Configuration
@Profile("prod")
public class ProdDataSourceConfig { /* real DB */ }

Annotate the class with @RestController and map methods with @GetMapping, @PostMapping and so on. Path variables come from @PathVariable, query parameters from @RequestParam, and request bodies from @RequestBody.

@RestController
@RequestMapping("/api/products")
public class ProductController {

    @GetMapping
    public List<Product> list(@RequestParam(defaultValue = "0") int page) {
        return productService.findAll(page);
    }

    @PostMapping
    public Product create(@RequestBody Product product) {
        return productService.save(product);
    }
}

Use @ControllerAdvice with @ExceptionHandler methods. The handler runs whenever the mapped exception is thrown anywhere in your controllers, so you keep error handling out of individual endpoints.

@RestControllerAdvice
public class GlobalExceptionHandler {

    @ExceptionHandler(ResourceNotFoundException.class)
    public ResponseEntity<ErrorResponse> handleNotFound(ResourceNotFoundException ex) {
        return ResponseEntity.status(HttpStatus.NOT_FOUND)
                .body(new ErrorResponse(ex.getMessage()));
    }

    @ExceptionHandler(Exception.class)
    public ResponseEntity<ErrorResponse> handleAll(Exception ex) {
        return ResponseEntity.status(HttpStatus.INTERNAL_SERVER_ERROR)
                .body(new ErrorResponse("Unexpected error"));
    }
}