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.

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.