Core Java — Senior Engineer Study Guide

📝 Quiz · 🃏 Flashcards

Companion to INTERVIEW_PREP.md §1. This guide is the teaching layer: concepts explained from first principles, code examples, gotchas, and anchor examples (a legacy MQ microservice, cross-team schema standardization, JAXB migration, ArgoCD rollouts).

Scope: Core Java language + JVM internals + modern features up through Java 25 LTS. Concurrency is intentionally a refresher here (JMM / volatile / synchronized / ThreadLocal basics) — full depth lives in a future CONCURRENCY.md.

How to use: Skim the coverage matrix (§Q-Map) to jump to the section answering a specific INTERVIEW_PREP question. For open study, walk §1 → §22 in order. Morning-of-interview: §21 Rapid-Fire.

---

Table of Contents

1. Java Platform & Language Basics
2. Object-Oriented Java
3. Strings & Text
4. Immutability
5. Exception Handling
6. Generics
7. Collections Framework
8. Functional Java — Lambdas, Streams, Optional
9. Modern Java Features (Java 11 → 25)
10. JVM Internals & Memory
11. Garbage Collection
12. Concurrency Refresher
13. I/O & NIO
14. Reflection & Annotations
15. Serialization
16. Java Modules (JPMS)
17. Null Safety
18. Common Gotchas & Tricky Outputs
19. Build & Ecosystem
20. Connect to Your Experience
21. Rapid-Fire Review
22. Practice Exercises

---

Interview-Question Coverage Matrix

Maps each INTERVIEW_PREP.md §1 question (1–30) to the section(s) in this guide that answer it.

Q#	Topic	Section
1	== vs .equals()	§1
2	hashCode/equals contract	§1
3	ArrayList/LinkedList/Vector	§7
4	HashMap/LinkedHashMap/TreeMap/ConcurrentHashMap	§7
5	HashMap internals (Java 8+)	§7
6	Checked vs unchecked exceptions	§5
7	try-with-resources / AutoCloseable	§5
8	Immutability recipe	§4
9	String vs StringBuilder vs StringBuffer	§3
10	String pool / new String("abc") vs "abc"	§3
11	Type erasure	§6
12	Covariance / contravariance / PECS	§6
13	Optional — when NOT to use it	§8
14	Streams — intermediate vs terminal, lazy eval	§8
15	map vs flatMap	§8
16	parallelStream() pitfalls	§8
17	Functional interfaces	§8
18	Records	§4, §9
19	Sealed classes	§9
20	Pattern matching (instanceof / switch)	§9
21	Text blocks	§3, §9
22	Virtual threads & pinning	§9, §12
23	JVM memory model — heap/stack/metaspace/gens	§10
24	StackOverflowError vs OutOfMemoryError	§10
25	G1 vs ZGC vs Shenandoah	§11
26	Memory leak analysis in a running JVM	§10, §11
27	final vs finally vs finalize	§1, §5
28	Serializable — why dangerous	§15
29	Java Modules (JPMS)	§16
30	Null safety without Optional-everywhere	§17

---

1. Java Platform & Language Basics

JDK vs JRE vs JVM

• JVM — the spec + runtime that executes .class bytecode. Multiple implementations (HotSpot, OpenJ9, GraalVM). Platform-specific.
• JRE — JVM + core class libraries. Run-only. (Bundled into the JDK since Java 11; no separate download.)
• JDK — JRE + developer tools (javac, jar, javadoc, jlink, jpackage, jcmd).

Write-once-run-anywhere = javac produces portable bytecode; a platform-specific JVM executes it. Cross-platform native code (via JNI / Panama) breaks this guarantee.

Primitives vs wrappers

Java has 8 primitives: byte, short, int, long, float, double, char, boolean. Each has a wrapper (Integer, Long, etc.) for use in generics / collections / nullable fields.

Autoboxing (primitive → wrapper) and unboxing (wrapper → primitive) happen implicitly:

Integer boxed = 42;       // autoboxing: Integer.valueOf(42)
int unboxed = boxed;      // unboxing: boxed.intValue()

Integer cache gotcha (–128 to 127): Integer.valueOf(int) caches boxed values in that range. So:

Integer a = 127, b = 127;
Integer c = 128, d = 128;
System.out.println(a == b); // true  (same cached instance)
System.out.println(c == d); // false (two different Integer objects)

Always use .equals() on boxed types. The cache is an optimization, not a contract you should rely on.

Null-unbox NPE:

Integer x = null;
int y = x; // NullPointerException — unboxing null

This is insidious in ternaries: boolean flag ? 1 : null compiles but unboxes the null.

Pass-by-value — always

Java is always pass-by-value. For object arguments, the "value" is the reference. So a method can mutate the object the reference points to, but cannot reassign the caller's reference.

void reassign(List<String> l) { l = new ArrayList<>(); } // caller's list unchanged
void mutate(List<String> l)   { l.add("x"); }            // caller's list gets "x"

== vs .equals()

• == — reference identity for objects; value equality for primitives.
• .equals() — logical equality. Default Object.equals is ==. Override it for value-like classes.

String a = new String("hi"), b = new String("hi");
a == b;         // false — two distinct heap objects
a.equals(b);    // true  — logical equality

equals / hashCode contract

Five rules for equals:

1. Reflexive — x.equals(x) is true.
2. Symmetric — x.equals(y) ⇔ y.equals(x).
3. Transitive — if x.equals(y) and y.equals(z), then x.equals(z).
4. Consistent — repeated calls return the same result so long as objects don't change.
5. Null-safe — x.equals(null) is false.

The hashCode contract: if a.equals(b), then a.hashCode() == b.hashCode(). The reverse is not required.

What breaks if you violate it?

• Override equals without hashCode → objects that are "equal" land in different buckets of a HashMap / HashSet. map.put(key, v) then map.get(equalKey) returns null. Duplicates appear in HashSet.
• Mutate a field used in hashCode after the object is a map key → the object is effectively "lost" — it's in a bucket it shouldn't be in anymore, and lookup goes to the new bucket, where it isn't.

Canonical implementation:

@Override
public boolean equals(Object o) {
    if (this == o) return true;
    if (!(o instanceof User u)) return false;  // pattern matching (Java 16+)
    return Objects.equals(id, u.id);
}

@Override
public int hashCode() { return Objects.hash(id); }

Better yet: use record (§4), which generates both correctly.

final, finally, finalize

Three unrelated concepts despite the name overlap:

Keyword	What it does
final	Prevents reassignment (final var), overriding (final method), or subclassing (final class).
finally	Block after try that always executes (except JVM death / killed thread).
finalize()	Legacy Object method called by GC before reclamation. Deprecated in Java 9, removal underway. Use AutoCloseable + try-with-resources or Cleaner.

static

• Belongs to the class, not an instance.
• Static fields are initialized once when the class is loaded (see §10 Class Loading).
• Static init blocks run top-to-bottom in source order:

class Config {
    static int a = 1;
    static { System.out.println(a); a = 2; }
    static int b = a; // b = 2
}

• Static methods can't be overridden (they're hidden). Don't call static methods through an instance reference — confuses readers.

Interview Qs covered

§1 addresses INTERVIEW_PREP Qs: 1 (==/equals), 2 (hashCode contract), 27 (final/finally/finalize).

---

2. Object-Oriented Java

The four pillars — Java-specific

Pillar	Java mechanism
Encapsulation	Private fields + public methods. Lombok shortens this.
Inheritance	Single-class inheritance (extends) + multi-interface implementation (implements). No multiple class inheritance; diamond problem is avoided at the type level but returns with default interface methods (see below).
Polymorphism	Runtime dispatch on overridden methods. Compile-time via overloading.
Abstraction	Abstract classes + interfaces.

Abstract class vs interface

	Abstract class	Interface
Instance state	Fields + constructors allowed	Only static final constants
Multiple inheritance	One per class	Multi-implement
Method bodies	Yes (any access)	default + static + private (Java 8 / 9)
Use case	Partial implementation with state	Pure contract / capability

Rule of thumb: reach for interfaces unless you need shared instance state.

Default / static / private interface methods

• Java 8: default (instance default body) + static (namespace-scoped helper).
• Java 9: private (share logic among default methods without leaking it to implementers).

Diamond with defaults: if a class inherits conflicting default methods from two interfaces, the class must override and explicitly pick:

interface A { default String greet() { return "A"; } }
interface B { default String greet() { return "B"; } }
class C implements A, B {
    @Override public String greet() { return A.super.greet(); }
}

Access modifiers

Modifier	Same class	Same pkg	Subclass (diff pkg)	Anywhere
private	✓
(package-private)	✓	✓
protected	✓	✓	✓
public	✓	✓	✓	✓

Package-private (no keyword) is underused — great for internal helpers you want unit-testable but not part of the public API.

Overloading vs overriding

• Overloading — same name, different parameter list, resolved at compile time. add(int) vs add(String).
• Overriding — subclass re-implements an inherited instance method with the same signature. Resolved at runtime (virtual dispatch). Always use @Override; the compiler catches signature drift.

Covariant return types (Java 5+): an override can return a subtype of the superclass's return type.

class Animal { Animal clone() { return new Animal(); } }
class Dog extends Animal { @Override Dog clone() { return new Dog(); } }

Nested classes

Kind	Holds outer this?	Use
Static nested	No	Helper class logically grouped with outer (e.g., Map.Entry)
Inner (non-static)	Yes — implicit Outer.this	Rarely needed; enables tight coupling to outer state
Local	Yes (effectively final captures)	One-off inside a method
Anonymous	Yes (same)	Pre-Java 8, for SAM impls. Now largely replaced by lambdas.

Memory leak warning: non-static inner and anonymous classes hold a reference to the enclosing instance. If the inner outlives the outer (event listener, cached callback), you pin the outer. Prefer static nested when possible.

Composition > inheritance

Inheritance creates a strong compile-time coupling and is easy to misuse. Prefer composition (+ delegation) for reuse; prefer interfaces for polymorphism. Mark classes final unless you've designed them for extension — see Effective Java Item 19 ("Design and document for inheritance or else prohibit it").

---

3. Strings & Text

Immutability and why it matters

String is immutable (backed by a final byte[] since Java 9 — compact strings). Reasons:

• Security — strings are used as file paths, URLs, SQL. If mutable, a checker-then-user race could change the validated string.
• Thread-safety — no synchronization needed to share a String across threads.
• Hashing — String.hashCode() is cached (Java can do this because the bytes never change), making maps keyed by strings fast.
• Interning — allows the string pool.

The String pool

Located in the heap (since Java 7; it was in PermGen before). String literals are interned: the same literal always resolves to the same object.

String a = "hi";
String b = "hi";
a == b; // true — same interned instance

String c = new String("hi");
a == c; // false — c is a new heap allocation
c.intern() == a; // true — intern returns the pool entry

Gotcha: new String("hi") creates two objects — one in the pool (from the literal) and one on the heap (from new). Don't use new String unless you specifically need a separate instance.

String vs StringBuilder vs StringBuffer

Class	Mutable	Thread-safe	Perf
String	No	Inherently	Concat = new object each time
StringBuilder	Yes	No	~4x faster than StringBuffer
StringBuffer	Yes	Yes (synchronized)	Legacy; almost never needed

Rule: use StringBuilder for loops that concat. The compiler may convert + in loops to StringBuilder, but it sometimes can't see through method boundaries — don't rely on it.

Since Java 9, simple concat (a + b) uses invokedynamic (StringConcatFactory) and is usually faster than hand-rolled StringBuilder for a small number of parts.

Text blocks (Java 15)

String sql = """
    SELECT id, name
    FROM users
    WHERE active = true
    """;

String json = """
    {"habit":"run","done":true}
    """;

• Indentation is normalized: the compiler strips the common leading whitespace.
• Use \ at the end of a line to suppress the newline, \s for trailing space.
• Great for embedded JSON/SQL/XML. Hugely improves readability in tests.

Formatting

• String.format("Hello %s, age %d", name, age)
• "Hello %s".formatted(name) (Java 15+) — fluent.
• printf for stdout.
• Always specify a Locale for user-facing number/date formatting — the default Locale bites on machines where , vs . flips.

Unicode & equality caveats

• "a".equalsIgnoreCase("A") — true.
• But some Unicode characters have no uppercase equivalent or have multi-char folding. For user-facing comparison, normalize with Normalizer.normalize(s, Form.NFC) first.

Interview Qs covered

§3 addresses Qs: 9 (String/Builder/Buffer), 10 (string pool), 21 (text blocks).

---

4. Immutability

The recipe

To make a class truly immutable:

1. Declare the class final (or use a sealed hierarchy — §9).
2. All fields private final.
3. No setters, no mutators.
4. Defensive-copy mutable constructor arguments on the way in and on the way out.
5. Don't leak this during construction (no this::method registration before the constructor finishes).

public final class Event {
    private final String id;
    private final Instant timestamp;
    private final List<String> tags;

    public Event(String id, Instant timestamp, List<String> tags) {
        this.id = Objects.requireNonNull(id);
        this.timestamp = Objects.requireNonNull(timestamp);
        this.tags = List.copyOf(tags); // defensive copy + unmodifiable
    }

    public List<String> getTags() {
        return tags; // already unmodifiable; no need to recopy
    }
}

Why immutable types are inherently thread-safe: no state change means no race. They also safely cache hashCode.

Records (Java 14+)

A record is a concise syntax for immutable data carriers. The compiler generates:

• A canonical constructor with all components.
• Final private fields.
• Accessors named after the components (no get prefix).
• equals, hashCode, toString based on all components.

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

Point p = new Point(1, 2);
p.x();             // 1
p.equals(new Point(1, 2)); // true

Compact constructor for validation / normalization — runs before field assignment:

public record Rate(int value) {
    public Rate {                              // compact: no parameter list
        if (value < 0) throw new IllegalArgumentException();
    }
}

Canonical constructor (full form) lets you customize field assignment:

public record Name(String first, String last) {
    public Name(String first, String last) {
        this.first = first == null ? "" : first.strip();
        this.last  = last  == null ? "" : last.strip();
    }
}

When NOT to use records:

• You need mutable state.
• You need to extend another class (records implicitly extend java.lang.Record).
• A framework demands a no-arg constructor + setters (old Hibernate, older Jackson without Parameter Names module).
• You care about hiding fields — records expose them by accessor.

Records can implement interfaces and hold static methods/fields. They cannot declare instance fields beyond the components.

Immutable collections

• List.of(...), Set.of(...), Map.of(...) / Map.ofEntries(...) — Java 9+. Truly immutable; throw on mutation attempts; reject nulls.
• List.copyOf(other) — Java 10+. Returns other if already immutable; otherwise copies.
• Collections.unmodifiableList(x) — a view, not a copy. If you keep a reference to x and mutate it, the "unmodifiable" view reflects the mutation. Trap.

Interview Qs covered

§4 addresses Qs: 8 (immutability), 18 (records).

---

5. Exception Handling

Hierarchy

Throwable
├── Error                    ← serious JVM issues; don't catch
│   └── OutOfMemoryError, StackOverflowError, …
└── Exception                ← CHECKED (except RuntimeException)
    ├── IOException, SQLException, …   ← checked
    └── RuntimeException                ← UNCHECKED
        └── NullPointerException, IllegalArgumentException, …

Checked vs unchecked

• Checked (extends Exception, not RuntimeException) — compiler forces you to catch or declare (throws).
• Unchecked (extends RuntimeException or Error) — no compile-time mandate.

Philosophy:

• Checked was intended for recoverable conditions; unchecked for programmer errors. In practice this split didn't age well.
• Modern frameworks lean unchecked. Spring translates JDBC's SQLException (checked) to its own unchecked DataAccessException hierarchy so your repository methods aren't noise.
• Checked exceptions don't compose with lambdas (most java.util.function types don't declare throws), which makes them awkward in streams.

try / catch / finally

try {
    riskyOp();
} catch (IOException | SQLException e) {      // multi-catch (Java 7+)
    log.error("op failed", e);
    throw new AppException("op failed", e);   // exception chaining
} finally {
    cleanup();
}

• Multi-catch — combine handlers when the logic is identical. The caught variable is effectively final inside the block.
• Chaining — pass cause to new Exception(msg, cause). Preserves root cause in stack traces.

try-with-resources & AutoCloseable

try (var in = Files.newBufferedReader(path);
     var out = Files.newBufferedWriter(other)) {
    in.transferTo(out);
}

• Resources are closed in reverse order of declaration, even if an exception is thrown.
• The resource must implement AutoCloseable (or Closeable, which extends it and restricts to IOException).
• If both the try body and close() throw, the close() exception becomes a suppressed exception on the primary. Retrievable via e.getSuppressed().

Rethrow patterns

• Wrap and rethrow with cause — standard.
• Catch-log-rethrow (both log and throw) — makes logs noisy (one error, two stack traces). Log OR throw, not both. Let the top-level handler log.
• Swallow-and-continue — occasionally right (best-effort cleanup), usually wrong. Add a comment.

finally subtleties

• Runs even when you return from try. finally can override the return:

int f() {
    try { return 1; }
    finally { return 2; } // returns 2; don't do this
}

• Does not run if JVM exits (System.exit), the thread is killed, or the process is SIGKILLed.

Interview Qs covered

§5 addresses Qs: 6 (checked vs unchecked), 7 (try-with-resources / AutoCloseable), 27 (finally).

---

6. Generics

Why generics

Compile-time type safety + removal of casts. Before Java 5:

List names = new ArrayList();
names.add("Alice");
String n = (String) names.get(0); // cast + hope

With generics, the cast is inserted by the compiler and type errors are caught at compile time.

Type erasure

At compile time, the compiler checks types. At runtime, the <T> is erased to its bound (Object by default, or the upper bound if declared). Consequences:

• You cannot do new T(). At runtime, T doesn't exist.
  • Workaround: pass Class<T> and call clazz.getDeclaredConstructor().newInstance().
• You cannot new T[10]. Generic array creation is banned.
  • Workaround: @SuppressWarnings("unchecked") T[] a = (T[]) new Object[10]; — but arrays are covariant and generics are invariant, so this is fragile.
• instanceof T fails (except with wildcards: x instanceof List<?>).
• Bridge methods are synthesized to preserve polymorphism in the erased signatures — usually invisible, sometimes show in stack traces.
• List<String> and List<Integer> are the same Class at runtime (List.class).

Bounded types

<T extends Number> double sumOf(List<T> xs) { ... }      // upper bound
<T extends Number & Comparable<T>> T max(List<T> xs) { } // multiple bounds (class first)

Wildcards — ?, ? extends T, ? super T

• List<?> — a list of unknown type. You can read Object; you cannot add (except null).
• List<? extends Number> — a list of Number or any subtype. You can read as Number; you cannot add (since the exact subtype is unknown).
• List<? super Integer> — a list of Integer or any supertype. You can add Integer (or subtype); reading yields Object.

PECS — Producer Extends, Consumer Super

If the collection produces values for you to read → ? extends T. If the collection consumes values you write → ? super T.

Copy example from Collections:

public static <T> void copy(List<? super T> dest, List<? extends T> src) {
    for (T t : src) dest.add(t);
}

• src produces Ts (read) → extends.
• dest consumes Ts (write) → super.

Reifiable vs non-reifiable

• Reifiable — runtime carries full type info (primitives, raw types, unbounded wildcards, arrays of reifiable types).
• Non-reifiable — parameterized types like List<String>. Hence no instanceof List<String>, no generic arrays, heap pollution warnings.

Interview Qs covered

§6 addresses Qs: 11 (type erasure, no new T()), 12 (covariance / contravariance / PECS).

---

7. Collections Framework

Hierarchy

Iterable
└── Collection
    ├── List       (ordered, indexed, allows duplicates)
    ├── Set        (no duplicates)
    └── Queue/Deque (FIFO / LIFO)
Map                (not a Collection — keyed access)

List

Impl	Backing	Random access	Insert at end	Insert in middle	Thread-safe
ArrayList	Resizable array	O(1)	amortized O(1)	O(n)	No
LinkedList	Doubly-linked nodes	O(n)	O(1)	O(1) if you have node ref, O(n) to find	No
Vector	Resizable array	O(1)	O(1)	O(n)	Yes (every method synchronized) — legacy
CopyOnWriteArrayList	Array, copy on write	O(1)	O(n) (full copy)	O(n)	Yes — reads lock-free

Practical advice:

• Default to ArrayList.
• LinkedList sounds attractive for "inserts in the middle" but almost never wins in practice — cache misses on each pointer chase dominate. Benchmark before reaching for it.
• Vector — don't, ever. If you need thread-safety wrap with Collections.synchronizedList or use CopyOnWriteArrayList (read-heavy).
• CopyOnWriteArrayList — perfect for listener lists: infrequent writes, frequent iteration without sync.

Set

• HashSet — hash-based, O(1) ops, no order.
• LinkedHashSet — insertion-order.
• TreeSet — sorted (by Comparable or Comparator), O(log n); NavigableSet methods (floor, ceiling, etc.).
• EnumSet — bitwise-packed, extremely efficient for enum keys.

Map

• HashMap — hash bucket array; no order; O(1) average.
• LinkedHashMap — insertion or access order; constructor flag accessOrder=true enables LRU behavior (see §22).
• TreeMap — red-black tree; sorted keys; NavigableMap.
• WeakHashMap — keys are weak references; entries auto-removed when key is GCed. Great for caches tied to object lifecycle.
• IdentityHashMap — uses == not equals; for graph-traversal algorithms.
• EnumMap — array-backed; very fast for enum keys.
• Hashtable — legacy synchronized; don't use.
• ConcurrentHashMap — modern concurrent; see below.

HashMap internals (Java 8+)

• Backed by Node<K,V>[] table — power-of-two size, default capacity 16, load factor 0.75.
• Hash spread: (h = key.hashCode()) ^ (h >>> 16) — mixes high bits into low bits so poor hashers (e.g., integer IDs) distribute better.
• Bucket index: hash & (table.length - 1).
• On collision: chain as a singly-linked list. Once a bucket reaches 8 nodes (TREEIFY_THRESHOLD), it's converted to a red-black tree — provided table.length >= 64; otherwise the table is resized first. Tree lookup degrades to O(log n) worst-case instead of O(n) for adversarial / poor-hashing keys.
• Untreeify threshold 6 — during removal, tree shrinks back to a list at 6 nodes.
• Resize — doubles capacity when size > loadFactor * capacity. Each entry is rehashed. Expensive; size your map if you know the target.
• null key allowed (goes in bucket 0); null values allowed.

ConcurrentHashMap internals (Java 8+)

• Same bucket layout as HashMap.
• Pre-Java-8 used "segments" (16 by default). Java 8 replaced that with:
  • Lock-free reads via volatile semantics on the node array.
  • CAS on empty-bucket insertions.
  • synchronized on the head node of a non-empty bucket for inserts/updates. Fine-grained: different buckets contend only when hashing to the same slot.
• No null keys, no null values — avoids ambiguity with "key not present" in concurrent reads.
• Atomic compound ops: computeIfAbsent, merge, putIfAbsent.
• size() is an approximation under contention; use mappingCount() for a long.

Hashtable vs synchronizedMap vs ConcurrentHashMap

• Hashtable — entire map synchronized; single lock; legacy.
• Collections.synchronizedMap(hashMap) — also single lock, wrapped; iteration still needs manual synchronized(map) { for (...) }.
• ConcurrentHashMap — per-bucket fine-grained locking, weakly-consistent iterators (no ConcurrentModificationException). Use this.

Queue & Deque

• ArrayDeque — default stack + deque. Beats Stack (legacy, synchronized).
• PriorityQueue — min-heap by default; provide a Comparator for max-heap or custom order.
• BlockingQueue family: ArrayBlockingQueue, LinkedBlockingQueue, SynchronousQueue, PriorityBlockingQueue, DelayQueue, LinkedTransferQueue. Producer-consumer foundation (see §12).

Comparable vs Comparator

• Comparable<T> — "natural order" (String, Integer). One per type.
• Comparator<T> — external ordering strategy. Multiple orders per type possible.

users.sort(Comparator.comparing(User::lastName)
                      .thenComparing(User::firstName)
                      .reversed());

Fail-fast vs fail-safe iterators

• Fail-fast (ArrayList, HashMap): detect structural modification during iteration and throw ConcurrentModificationException. Best-effort, not guaranteed.
• Fail-safe (CopyOnWriteArrayList, ConcurrentHashMap): iterate over a snapshot / weakly-consistent view; never throw CME. Iterators may not see concurrent updates.

Interview Qs covered

§7 addresses Qs: 3 (ArrayList/LinkedList/Vector), 4 (Map impls), 5 (HashMap internals).

---

8. Functional Java — Lambdas, Streams, Optional

Functional interfaces

A functional interface has exactly one abstract method (SAM). @FunctionalInterface documents intent and lets the compiler enforce it.

Core types in java.util.function:

Interface	Method	Shape
Function<T,R>	R apply(T)	T → R
BiFunction<T,U,R>	R apply(T,U)	T,U → R
Predicate<T>	boolean test(T)	T → bool
Consumer<T>	void accept(T)	T → ()
Supplier<T>	T get()	() → T
UnaryOperator<T>	T apply(T)	T → T
BinaryOperator<T>	T apply(T,T)	T,T → T

Primitive specializations avoid boxing: IntFunction, ToIntFunction, IntPredicate, IntStream, etc.

Lambdas and captures

Lambdas capture variables that are effectively final — the variable isn't reassigned after capture. (Not required to be declared final, just not reassigned.)

int base = 10;
Function<Integer, Integer> add = x -> x + base; // base is effectively final
// base = 20; // would break the above — compile error

Captured instance fields are not subject to this (they're accessed through this), but mutating them from a lambda on another thread is still a data race.

Method references

Form	Example
Static method	Integer::parseInt
Instance method of a specific object	sb::append
Instance method of an arbitrary object of a given type	String::length
Constructor	ArrayList::new

Streams

A stream is a pipeline of operations over a data source. Three stages:

1. Source — collection, array, I/O channel, Stream.of(...), Stream.generate(...).
2. Intermediate ops — lazy, return another stream (filter, map, flatMap, sorted, distinct, peek, limit, skip).
3. Terminal op — triggers execution (collect, forEach, reduce, count, findFirst, toList, toArray, min, max, anyMatch, allMatch, noneMatch).

Lazy evaluation: intermediate ops don't run until a terminal op is invoked. The terminal op drives the pipeline element-by-element (short-circuiting where possible).

list.stream()
    .filter(this::isActive)   // lazy
    .map(User::email)         // lazy
    .findFirst();              // terminal — pull starts here, short-circuits

map vs flatMap

• map(fn) — Stream<T> → Stream<R>. One-to-one.
• flatMap(fn) — Stream<T> → Stream<R> where fn: T → Stream<R>. One-to-many, flattened.

List<List<String>> tagLists = ...;
List<String> allTags = tagLists.stream()
                                .flatMap(List::stream)
                                .toList();

Collectors — the common ones

• toList() / toUnmodifiableList() / toSet()
• toMap(keyFn, valueFn, mergeFn) — always supply a merge function if duplicate keys are possible; otherwise you get IllegalStateException.
• groupingBy(fn) — returns Map<K, List<V>>.
• groupingBy(fn, counting()) / groupingBy(fn, mapping(extractor, toList())) — downstream collectors.
• partitioningBy(pred) — Map<Boolean, List<V>>.
• joining(", ", "[", "]") — strings.
• summarizingInt(fn) — IntSummaryStatistics (count, sum, min, max, avg in one pass).

parallelStream() — when it helps and when it hurts

Runs on the ForkJoin common pool. Pitfalls:

• Shared mutable state across pipeline → data race.
• Tasks that do blocking I/O monopolize the common pool — affects every parallel stream in the JVM. Use a custom pool or don't go parallel.
• Ordering — preserved by default for ordered sources but at a sync cost. Use .unordered() to drop the guarantee.
• Small N — overhead swamps gains. Rule of thumb: worth considering above ~10k elements of non-trivial work.
• With virtual threads, blocking pipelines still misbehave — virtual threads help with blocking in the task-per-thread model, not in the ForkJoin common pool.

Default: use sequential streams. Reach for parallel only with data you own, CPU-bound work, and benchmarks.

Optional

• Return type only. Don't use as:
  • Instance field — use null (with @Nullable) or default value.
  • Method parameter — forces callers to wrap.
  • Collection element — Optional<T> in a List<Optional<T>> is almost always wrong.
• Use ifPresent, orElse, orElseThrow, map, flatMap.
• Don't optional.get() without isPresent() — defeats the point.
• Don't wrap when it could be null: use Optional.ofNullable(x) not Optional.of(x).

// Good
repo.findById(id).map(User::email).orElseThrow(() -> new NotFound(id));

// Bad
Optional<Optional<String>> nope = ...;

Interview Qs covered

§8 addresses Qs: 13 (Optional), 14 (streams lazy eval), 15 (map vs flatMap), 16 (parallelStream), 17 (functional interfaces).

---

9. Modern Java Features (Java 11 → 25)

Release timeline (LTS in bold)

Version	Released	Highlights
8	2014	Lambdas, streams, Optional, default methods
11 (LTS)	2018	var (10), HTTP client, String enhancements
14	2020	Records (preview), helpful NPEs, switch expressions standard
15	2020	Text blocks standard, sealed classes (preview)
16	2021	Records standard, pattern matching for instanceof standard
17 (LTS)	2021	Sealed classes standard
21 (LTS)	2023	Virtual threads, pattern matching for switch, record patterns, sequenced collections
23	2024	Unnamed classes / instance main (preview)
25 (LTS)	2025-09	Flexible constructor bodies, compact object headers, scoped values, module imports, primitive patterns (preview)

var (local variable type inference, Java 10)

var users = new ArrayList<User>();   // inferred ArrayList<User>
var stream = list.stream();

Rules:

• Only for local variables with an initializer (or for-loop variables).
• Not for fields, method parameters, return types.
• Not with null initializer, not with a lambda (no target type to infer).
• Prefer when the RHS makes the type obvious. Don't use it to hide complex types.

Records (Java 14, standard 16) — see §4.

Sealed classes/interfaces (Java 17)

Restrict who can extend/implement:

public sealed interface Shape permits Circle, Square, Triangle {}
public record Circle(double r) implements Shape {}
public record Square(double side) implements Shape {}
public record Triangle(double a, double b, double c) implements Shape {}

Subclasses must be final, sealed, or non-sealed. Enables exhaustive switches:

double area(Shape s) {
    return switch (s) {
        case Circle c     -> Math.PI * c.r() * c.r();
        case Square sq    -> sq.side() * sq.side();
        case Triangle t   -> heron(t);
        // no default — compiler verifies exhaustiveness
    };
}

Pattern matching for instanceof (Java 16)

if (obj instanceof User u) {     // binding variable 'u'
    send(u.email());
}

Cleaner than cast-after-check. The binding is flow-scoped — in the negative branch (if (!(obj instanceof User u))), u would be available after an early return.

Pattern matching for switch (Java 21)

String describe(Object o) {
    return switch (o) {
        case Integer i when i < 0 -> "negative int";
        case Integer i            -> "non-negative int";
        case String s             -> "string: " + s;
        case null                 -> "null";
        default                   -> "other";
    };
}

Switch expressions also give you:

• Arrow syntax — no fallthrough.
• yield — return a value from a block branch.
• Exhaustiveness — on sealed types / enums, no default needed.

Record patterns (Java 21)

Destructure records in patterns:

String formatShape(Shape s) {
    return switch (s) {
        case Circle(double r)            -> "circle r=" + r;
        case Square(double side)         -> "square " + side;
        case Triangle(double a, double b, double c) -> "tri " + a + "," + b + "," + c;
    };
}

Nested record patterns let you pull out sub-fields in one expression.

Text blocks — see §3.

Virtual threads (Java 21) — quick intro (full depth in CONCURRENCY.md)

• What they are: lightweight threads scheduled by the JVM on top of a small pool of carrier platform threads. You can create millions. Thread.ofVirtual().start(r) or Executors.newVirtualThreadPerTaskExecutor().
• When they help: blocking I/O at scale — thread-per-request servers without the cost. A virtual thread blocked on read() unmounts from its carrier, freeing it for another virtual thread.
• Pinning: if a virtual thread enters a synchronized block or a native frame (JNI), it's pinned to its carrier and cannot unmount. Before Java 24 this pinned the carrier for the duration; Java 24+ largely lifts this for synchronized. Still: prefer ReentrantLock for long-held locks.
• When they don't help: CPU-bound work — you still need roughly one thread per core. ForkJoinPool or a sized executor is better.

Structured concurrency (Java 25 incubator / preview depending on final status)

Treats a group of tasks as a single unit so that cancellation propagates and errors fail fast:

try (var scope = StructuredTaskScope.open()) {
    var userTask  = scope.fork(() -> userService.load(id));
    var orderTask = scope.fork(() -> orderService.load(id));
    scope.join();           // wait for all
    return new View(userTask.get(), orderTask.get());
}   // auto-closed: any outstanding task is cancelled

Scoped values (Java 25)

Immutable per-thread context that plays well with virtual threads (where ThreadLocal has pain around millions of threads, pinning on synchronized ops, and leaks):

static final ScopedValue<User> CURRENT = ScopedValue.newInstance();

ScopedValue.where(CURRENT, user).run(this::handleRequest);
// inside handleRequest: CURRENT.get()

Sequenced collections (Java 21)

SequencedCollection, SequencedSet, SequencedMap give you first/last access uniformly across implementations:

list.getFirst(); list.getLast(); list.reversed();
linkedHashMap.firstEntry(); linkedHashMap.lastEntry();

Flexible constructor bodies (Java 25)

Code before the super(...) / this(...) call is now allowed, provided it doesn't reference this:

public class Employee extends Person {
    public Employee(String name, double salary) {
        if (salary < 0) throw new IllegalArgumentException();  // before super()
        super(name);
        this.salary = salary;
    }
}

Compact object headers (Java 25)

JEP that reduces the object header from 96 to 64 bits on 64-bit VMs, cutting heap footprint 10–20% for object-heavy workloads. Opt-in via -XX:+UseCompactObjectHeaders.

Unnamed variables and patterns (Java 21)

Use _ for values you don't care about:

for (var _ : list) count++;             // loop without binding
switch (obj) {
    case Point(int x, int _) -> ...;    // destructure but ignore y
}

Simpler void main and implicit classes (Java 25)

A program without explicit class declaration and with a simple void main():

void main() {
    println("Hello");
}

Useful for scripts/tutorials. Production code still uses full class form.

Interview Qs covered

§9 addresses Qs: 18 (records), 19 (sealed), 20 (pattern matching), 21 (text blocks), 22 (virtual threads).

---

10. JVM Internals & Memory

Architecture

┌─────────────────────────────────────────────────┐
│ Classloader Subsystem                           │
│   Bootstrap → Platform → Application [→ custom] │
└─────────────────────────────────────────────────┘
                    │
                    ▼
┌─────────────────────────────────────────────────┐
│ Runtime Data Areas                              │
│   ┌────────┐ ┌──────────┐ ┌──────────────┐     │
│   │ Heap   │ │Metaspace │ │ Stacks (1/thread) │
│   └────────┘ └──────────┘ └──────────────┘     │
│   ┌────────┐ ┌──────────────────┐              │
│   │PC reg  │ │Native Method Stack│              │
│   └────────┘ └──────────────────┘              │
└─────────────────────────────────────────────────┘
                    │
                    ▼
┌─────────────────────────────────────────────────┐
│ Execution Engine                                │
│   Interpreter + JIT (C1/C2) + GC                │
└─────────────────────────────────────────────────┘

Runtime data areas

Area	Shared?	Contents
Heap	All threads	Objects, arrays, class data
Metaspace	All threads	Class metadata (method bytecode, constant pool, field/method info). Replaced PermGen in Java 8. Uses native memory, not heap.
Stack	Per thread	Method frames: local vars, operand stack, return address
PC register	Per thread	Currently executing instruction address
Native method stack	Per thread	For JNI calls

Heap subdivisions (generational GCs):

Young Generation
├── Eden      ← new objects
├── Survivor 0
└── Survivor 1
Old Generation ← promoted after N young collections

• New allocations go to Eden.
• Minor GC copies survivors Eden → S0, flips on next cycle. Objects surviving N cycles are tenured to the old gen.
• Major / full GC compacts old gen.
• ZGC / Shenandoah use different layouts (region-based, no fixed gen split for ZGC generational mode in newer JDKs).

Class loading

Three phases, each split further:

1. Loading — the classloader reads the .class file and creates a Class<?> object in metaspace. Requested via Class.forName or implicit (first new X, first static access).
2. Linking
   • Verify — bytecode safety checks (stack maps, types).
   • Prepare — allocate memory for static fields, set to default values (0 / null).
   • Resolve — symbolic references → direct references (lazy by default).
3. Initialization — static initializers + static field assignments run.

Classloader hierarchy:

Bootstrap (native) — loads java.base etc.
    │ parent of
Platform (formerly "Extension") — java.xml, java.sql, ...
    │ parent of
Application (classpath) — your code
    │ parent of
Custom (OSGi, web app, Spring Boot fat jar)

Parent-delegation model: a classloader first asks its parent to find the class; only if the parent fails does it try itself. This prevents your code from shadowing java.lang.String with a malicious one.

Static vs instance initialization order

For new Subclass():

1. Static blocks/fields of Subclass (if not already initialized — once per classloader).
2. Static blocks/fields of Superclass — actually run first, since the superclass must be initialized before its subclass.
3. Instance init of Superclass (fields + init blocks + constructor body).
4. Instance init of Subclass.

String pool location

• Pre-Java 7: PermGen.
• Java 7+: heap. Hence OOM from too many interned strings now manifests as regular heap OOM, and the pool is subject to GC.

StackOverflowError vs OutOfMemoryError

Error	Cause	Where	Fix
StackOverflowError	Deep / infinite recursion	Per-thread stack (default ~512KB–1MB)	Refactor to iteration, or -Xss2m
OutOfMemoryError: Java heap space	Heap full	Heap	Find leak (see below); raise -Xmx; tune GC
OutOfMemoryError: Metaspace	Loaded too many classes	Metaspace	Leaking classloaders (hot-reload app servers); -XX:MaxMetaspaceSize
OutOfMemoryError: Direct buffer memory	Off-heap NIO buffers	Native	Netty/NIO leak; -XX:MaxDirectMemorySize
OutOfMemoryError: GC overhead limit exceeded	>98% time in GC, <2% heap recovered	Heap pressure	Fix leak or raise heap

Top memory-leak sources

1. ThreadLocal in a thread pool — threads are pooled, never die, their ThreadLocalMap keeps growing. Always threadLocal.remove() at the end of the request / task.
2. Static caches without eviction — static Map<K,V> grows forever. Use Caffeine with size/time-based eviction.
3. Listener / callback registries — register but never unregister. Use WeakReference or explicit dispose hooks.
4. Inner / anonymous classes holding outer this — worst when the inner is stored in a long-lived collection. Prefer static nested.
5. Classloader leaks — app servers / hot-reload environments. A single reference from an old classloader's static field to a long-lived object pins the whole classloader, preventing metaspace reclamation.
6. Unclosed resources — streams, PreparedStatement, DB connections. try-with-resources fixes this.
7. Growing log context / MDC without cleanup on pooled threads.

Heap dump workflow

1. Trigger:
   • Auto: -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/tmp/heap.hprof.
   • Manual: jcmd <pid> GC.heap_dump /tmp/heap.hprof (preferred) or jmap -dump:live,format=b,file=/tmp/heap.hprof <pid>.
2. Transfer off the pod (if K8s: kubectl cp).
3. Open in Eclipse MAT or VisualVM / JFR (for newer flight-recorder-based analysis).
4. In MAT: look at Dominator Tree (who retains the most memory) and Leak Suspects report. Cross-ref by class to narrow.
5. Find the GC root path: why can't this object be collected?

Also useful: jcmd <pid> GC.class_histogram, jcmd <pid> Thread.print.

Interview Qs covered

§10 addresses Qs: 23 (JVM memory), 24 (SOE vs OOM), 26 (leak analysis).

---

11. Garbage Collection

Generational hypothesis

Most objects die young.

GCs exploit this by keeping new allocations in a small, fast-collected young region. Survivors promote to the old gen, which is collected less often.

Algorithm families

• Mark-Sweep — mark reachable, sweep garbage. Fragmentation.
• Mark-Sweep-Compact — + compaction. Moves live objects, reduces fragmentation at cost of pause time.
• Copying — split region into two halves; move live to the other half. Used in young gen.

The collectors

GC	STW pauses	Heap size sweet spot	Use case
Serial	Long	<100MB	Tiny single-core apps, containers with 1 CPU
Parallel (default pre-9)	Medium	Up to GB	Throughput-focused batch / ETL
CMS	Short young + concurrent old	GB	Removed in Java 14; replaced by G1/ZGC
G1 (default since 9)	~10–200ms	4 GB – 64 GB	Balanced general-purpose
ZGC	Sub-ms, mostly concurrent	GB to TB	Low-latency services; large heaps
Shenandoah	Sub-ms	GB to TB	Same goals as ZGC; OpenJDK / RedHat origin

When to pick

• G1 — default. Good starting point for most services. -XX:MaxGCPauseMillis=200 tunes young region size.
• ZGC — when you need consistent sub-millisecond pauses, or you have a huge heap (>32GB). As of Java 21, ZGC is generational — the tradeoff vs G1 narrowed. -XX:+UseZGC.
• Shenandoah — similar to ZGC; pick based on distro support. -XX:+UseShenandoahGC.
• Parallel — max throughput batch jobs where pauses don't matter.
• Serial — container with 1 CPU, <100MB heap.

Key flags (cheat sheet)

-Xms4g -Xmx4g                        # heap (set equal in prod to avoid resize pauses)
-XX:+UseG1GC                         # pick collector
-XX:MaxGCPauseMillis=100             # G1 soft target
-Xlog:gc*:file=/var/log/gc.log:time  # unified GC logging (Java 9+)
-XX:+HeapDumpOnOutOfMemoryError      # auto dump on OOM
-XX:MaxDirectMemorySize=256m         # cap off-heap
-XX:+UseContainerSupport             # on by default 10+; honor cgroups
-XX:MaxRAMPercentage=75.0            # % of container RAM for heap
-XX:+UseCompactObjectHeaders         # Java 25+: smaller headers

Stop-the-world vs concurrent

• STW — all application threads paused during a GC phase.
• Concurrent — GC work runs alongside the app.

G1 has short STW pauses for young collection + mixed collections, with some concurrent phases (marking). ZGC and Shenandoah aim for almost all concurrent with only tiny STW phases (< 1ms).

Reference types

Type	Reachability	Collected when	Use case
Strong	Normal reference	Never until unreachable	Default
Soft (SoftReference<T>)	Softly reachable	Under memory pressure	Large optional caches
Weak (WeakReference<T>)	Weakly reachable	Next GC cycle	WeakHashMap, canonicalizing maps, cached metadata
Phantom (PhantomReference<T>)	After finalization	Never .get()s the referent; enqueued when cleared	Cleanup callbacks via Cleaner (Java 9+)

System.gc()

• A hint. JVMs may ignore or honor.
• Under G1/ZGC usually triggers a full GC — disruptive.
• Don't call in production unless you really know why. -XX:+DisableExplicitGC is common in prod.

Interview Qs covered

§11 addresses Qs: 25 (G1 vs ZGC vs Shenandoah), 26 (leak analysis).

---

12. Concurrency Refresher

This section is a light touch. For ExecutorService, Locks, CompletableFuture, ForkJoinPool, virtual-thread deep dive, BlockingQueue patterns, and the full JMM formal model — see the planned CONCURRENCY.md.

The Java Memory Model — what you need for Core Java

The JMM defines when one thread's writes become visible to another and what reorderings the compiler / CPU may perform.

Happens-before is the central relation. If action A happens-before action B, A's effects are visible to B. The JMM establishes happens-before via:

• Program order within a single thread.
• Monitor lock — an unlock happens-before every subsequent lock on the same monitor (so synchronized publishes writes).
• Volatile — a write to a volatile field happens-before every subsequent read of that field.
• Thread start/join — Thread.start() happens-before the new thread's first action; a thread's actions happen-before another thread's return from join().
• final field freezes — a correctly published final field is safely visible after the constructor finishes.

volatile

• Guarantees: visibility (all threads see the latest write) + prevents certain reorderings.
• Does NOT guarantee atomicity of compound ops. volatile int counter; counter++; is still a race.
• Use: flags (volatile boolean running), "publish" of an immutable snapshot pointer, double-checked locking (requires volatile to work correctly).

synchronized

• Monitor lock per object (or per class for static synchronized).
• Reentrant (same thread can re-enter a block it already holds).
• On entry: acquire lock → memory barriers make prior unlock's writes visible. On exit: release + flush.
• Prefer synchronize on a private final object, not on this, to avoid external code contending on your lock.

private final Object lock = new Object();
void tx() { synchronized (lock) { … } }

Atomic* classes

AtomicInteger, AtomicLong, AtomicReference, AtomicBoolean, LongAdder, etc. Backed by CAS (Compare-And-Swap). Give you atomic compound ops:

AtomicInteger n = new AtomicInteger();
n.incrementAndGet();
n.compareAndSet(5, 6);
n.updateAndGet(x -> x + 1);

LongAdder trades exact count for lower contention by keeping per-thread counters. Great for hot counters; read with .sum().

ThreadLocal

Each thread sees its own value. Classic uses: per-request context (user, trace ID), date formatters (pre-Java-8; now use DateTimeFormatter which is thread-safe).

Leak risk in pools: the thread outlives the request. If you don't remove(), values accumulate in the pool's threads — unbounded leak. Framework filters (Spring's RequestContextFilter, Logback's MDC) call remove() in a finally; if you create your own, do the same.

Virtual threads: each VT has its own locals, which is great except ThreadLocal.remove() hygiene matters even more when you might create millions. Prefer ScopedValue (§9) for new code on Java 25.

Covers

Minimal overlap with INTERVIEW_PREP §3 (Concurrency). The rest belongs in CONCURRENCY.md.

---

13. I/O & NIO

Classic IO — java.io

• Byte streams: InputStream / OutputStream. Decorator pattern: BufferedInputStream(new FileInputStream(...)), DataInputStream for typed reads, ObjectInputStream (→ §15 Serialization, avoid).
• Character streams: Reader / Writer. Always wrap with BufferedReader / BufferedWriter.
• Always specify charset — new InputStreamReader(in, StandardCharsets.UTF_8). Default charset depends on JVM / locale and has burned everyone.
• Use try-with-resources.

NIO — java.nio

• Channels (FileChannel, SocketChannel, DatagramChannel) — bidirectional, non-blocking capable.
• Buffers (ByteBuffer, CharBuffer, …) — fixed-size arrays with position/limit/capacity semantics. Direct buffers are off-heap, faster for I/O at the cost of non-GC'd memory.
• Selectors — monitor multiple channels for readiness (readable/writable) in one thread. Foundation of reactive servers (Netty). Virtual threads let you revert to simpler blocking code in many cases.

NIO.2 — java.nio.file

Modern filesystem API. Prefer over java.io.File.

Path path = Path.of("/tmp/data.json");
String text = Files.readString(path, StandardCharsets.UTF_8);
Files.writeString(path, text, StandardOpenOption.CREATE_NEW);
try (var stream = Files.list(dir)) { stream.forEach(System.out::println); }

• Files.walk, Files.find — recursive traversal; close the stream (try-with-resources).
• WatchService — native filesystem change notifications.
• FileSystems.newFileSystem(zipPath, env) — treat a zip like a filesystem.

Performance tips

• Buffer. Never read one byte at a time from a raw FileInputStream.
• For large files: Files.newBufferedReader, transferTo (channel → channel), memory-mapped files (FileChannel.map).
• Always close. Always specify charset.

---

14. Reflection & Annotations

Reflection

APIs in java.lang.reflect: Class, Method, Field, Constructor, Modifier, Parameter.

Class<?> c = Class.forName("com.example.User");
Object obj = c.getDeclaredConstructor().newInstance();
Field f = c.getDeclaredField("email");
f.setAccessible(true);
f.set(obj, "a@b.com");

• Powers Spring DI, JPA, Jackson, JUnit.
• Costs: slower than direct calls (JIT handles most cases now, but cold), bypasses compile-time checks, and triggers JPMS warnings / errors (--add-opens).
• MethodHandles / VarHandles — modern alternatives with better JIT inlining.

Annotations

Built-in:

• @Override — catches signature drift.
• @Deprecated(since, forRemoval) — mark obsolete APIs.
• @SuppressWarnings("unchecked") — opt out of specific warnings.
• @FunctionalInterface — enforce single abstract method.
• @SafeVarargs — assert heap-pollution-free varargs use.

Meta-annotations (on your custom annotations):

• @Retention(RUNTIME | CLASS | SOURCE) — how long it's kept. RUNTIME required for reflection-driven frameworks.
• @Target — where it can be placed (TYPE, METHOD, FIELD, PARAMETER, ANNOTATION_TYPE, …).
• @Documented — included in Javadoc.
• @Inherited — subclasses inherit the annotation (class-level only).
• @Repeatable — multiple instances on one element.

Custom annotations

@Retention(RUNTIME)
@Target(METHOD)
public @interface Timed {
    String value() default "";
}

Processed at runtime (reflection) or compile time (annotation processor — javax.annotation.processing.Processor, how Lombok works — though Lombok hooks deeper).

How frameworks use them

• Spring — @Component, @Autowired, @Transactional, @RequestMapping. Runtime reflection + proxies (JDK dynamic or CGLIB).
• JPA / Hibernate — @Entity, @Id, @OneToMany. Runtime; may generate bytecode for lazy proxies.
• Jackson — @JsonProperty, @JsonIgnore. Runtime reflection.
• Lombok — @Data, @Builder. Compile-time bytecode weaving; annotations vanish after compile.

---

15. Serialization

Java built-in serialization — Serializable

public class Event implements Serializable {
    private static final long serialVersionUID = 1L;
    private String id;
    private transient Secret s;  // not serialized
}

• serialVersionUID — explicit version key for the serialized shape. Always declare it; otherwise the compiler computes one from the class structure, and minor changes (adding a method!) can break deserialization.
• transient — skip this field.
• Hooks: private void writeObject(ObjectOutputStream) and readObject(ObjectInputStream) for custom logic; readResolve() to canonicalize (singletons).

Why Serializable is dangerous

Deserialization invokes constructors / methods based on the input stream. An attacker-controlled stream can instantiate classes available on your classpath with attacker-chosen state. Combined with "gadget chains" (classes that trigger useful side effects in readObject / finalize / etc.), this enables remote code execution.

Famous incidents: the Apache Commons Collections gadget chain (2015) enabled RCE in WebLogic, JBoss, Jenkins, and many others simply by deserializing untrusted input.

Mitigations (in order of preference):

1. Don't deserialize untrusted input with Java serialization. Use JSON/Protobuf/Avro.
2. If forced, use ObjectInputFilter (Java 9+, JEP 290) to allowlist classes:

   ObjectInputFilter filter = ObjectInputFilter.Config.createFilter("com.myapp.*;!*");
   in.setObjectInputFilter(filter);

3. Audit dependencies for known gadgets (OWASP Dependency Check).

Modern alternatives

• Jackson (JSON) — default for REST APIs. Text-based; verbose but debuggable.
• Avro — compact binary, schema-registry integrated, great for Kafka. Worth discussing in interviews: schema evolution, backward/forward compatibility, naming strategies.
• Protobuf — Google-origin, strong schema, gRPC's wire format. Similar properties to Avro; less Kafka-friendly by default.
• Kryo — high-perf Java-only; not cross-language.

Interview Qs covered

§15 addresses Q 28 (Serializable dangers).

---

16. Java Modules (JPMS)

module-info.java

module com.example.habits {
    requires spring.boot;
    requires transitive com.example.common;  // consumers also see this

    exports com.example.habits.api;          // public to all
    exports com.example.habits.internal      // public to specific module only
        to com.example.admin;

    opens com.example.habits.domain          // deep reflection access (JPA, Jackson)
        to org.hibernate.orm.core, com.fasterxml.jackson.databind;

    provides com.example.spi.Plugin
        with com.example.habits.impl.MyPlugin;

    uses com.example.spi.AuthProvider;
}

Terms:

• requires — compile- and run-time dependency.
• requires transitive — propagates to my consumers (implied readability).
• exports — public API (. paths, not classes). Optional to clause for targeted exports.
• opens — allows deep (setAccessible) reflection. Frameworks need this.
• provides/uses — ServiceLoader SPI.

Module kinds

• Named module — has module-info.java.
• Automatic module — a plain jar placed on the module path. Name derived from Automatic-Module-Name manifest entry or the jar filename. Implicitly requires everything, opens everything. The bridge during migration.
• Unnamed module — jars on the classpath (not module path). Reads everything, exports everything. Legacy.

The practical pain

Spring Boot fat jars predate strong encapsulation and rely heavily on reflection. Common flags:

--add-opens java.base/java.lang=ALL-UNNAMED
--add-exports java.base/sun.nio.ch=ALL-UNNAMED

JDK 16+ deny setAccessible on JDK internals by default. Expect friction when upgrading.

When JPMS actually shines:

• Library authors who want to prevent consumers from using internal packages.
• Building custom runtime images with jlink.
• Strong encapsulation of plugin SPIs.

Most app developers touch JPMS only via --add-opens flags.

Interview Qs covered

§16 addresses Q 29 (JPMS).

---

17. Null Safety

The default stance

null is a value for every reference type. NullPointerException is the single most common bug in enterprise Java. Your job: minimize the surface where null can sneak in or out.

Validate at boundaries

Objects.requireNonNull — fail fast with a clear message at constructor / method entry:

public Event(String id, Instant ts) {
    this.id = Objects.requireNonNull(id, "id");
    this.ts = Objects.requireNonNull(ts, "ts");
}

requireNonNullElse(x, fallback) — supply a default.

Annotations

Several ecosystems; none universal:

• JSR-305 — @Nullable, @Nonnull. Widely used but JSR itself was abandoned.
• JetBrains — org.jetbrains.annotations.Nullable / NotNull. IntelliJ picks these up for nullability warnings.
• Spring Framework — @Nullable, @NonNull in org.springframework.lang.
• Checker Framework — heavier, includes a compile-time type checker.
• JSpecify — the nascent consolidation effort.

Use a consistent one per project. Treat IntelliJ / SonarQube warnings as errors.

When NOT to use Optional

• Field — adds memory per instance; use null + annotation.
• Method parameter — forces callers to wrap; allow null explicitly or provide overloads.
• Collection element — List<Optional<T>> almost always means: filter out the nothings.

Helpful NPE messages

Since Java 14 (on by default): the exception points to which variable was null in a chain:

a.b.c.d  →  Cannot invoke "Y.d()" because the return value of "X.c()" is null

Flag: -XX:+ShowCodeDetailsInExceptionMessages.

Interview Qs covered

§17 addresses Q 30 (null safety without Optional-everywhere).

---

18. Common Gotchas & Tricky Outputs

Predict-the-output drills. Expect 1–2 of these in a live interview.

1. Integer cache

Integer a = 127, b = 127;     // a == b → true  (cached)
Integer c = 128, d = 128;     // c == d → false (new instances)

2. Mutating a HashMap key

List<String> k = new ArrayList<>(List.of("a"));
Map<List<String>, Integer> m = new HashMap<>();
m.put(k, 1);
k.add("b");                    // hashCode changed
m.get(k);                      // likely null — wrong bucket

Never use a mutable object as a map key.

3. switch fallthrough

switch (x) {
    case 1: System.out.println("one");
    case 2: System.out.println("two");    // both print if x=1
}

Prefer arrow-syntax switch (Java 14+), which never falls through.

4. Floating-point equality

System.out.println(0.1 + 0.2 == 0.3); // false

Use BigDecimal for money; Math.abs(a - b) < eps for approximate compare.

5. Autoboxing in ternary

Integer x = false ? 1 : null;  // null
int y = false ? 1 : null;      // NullPointerException — forces unbox

6. finally overrides return

int f() {
    try { return 1; } finally { return 2; }   // returns 2
}

7. Concurrent modification during iteration

List<Integer> l = new ArrayList<>(List.of(1,2,3));
for (Integer i : l) if (i == 2) l.remove(i); // CME

Use Iterator.remove() or List.removeIf(...).

8. Diamond defaults

Two interfaces provide the same default method; compiler forces the class to override.

9. String.split("")

"abc".split("");        // ["a","b","c"]  (Java 8+)
"abc".toCharArray();    // ['a','b','c']

10. Arrays.asList

List<Integer> l = Arrays.asList(1,2,3);
l.add(4);                                  // UnsupportedOperationException — fixed-size wrapper
List<Integer> l2 = new ArrayList<>(Arrays.asList(1,2,3)); // OK

11. Array covariance + generics invariance

Object[] arr = new String[3];
arr[0] = 1;                                // ArrayStoreException at runtime

List<Object> list = new ArrayList<String>(); // compile error

12. == on boxed types

Any two boxed types compared with == outside the Integer cache range → identity compare, not value.

13. HashMap iteration order

Not guaranteed. Never rely on it. Use LinkedHashMap if order matters.

14. Stream reuse

A stream can be consumed once. Calling another terminal op on a finished stream throws.

15. parallelStream on ConcurrentModificationException-prone sources

Parallel streams over a HashMap.entrySet() are safe only if no one mutates the map. Stick to ConcurrentHashMap or snapshot.

---

19. Build & Ecosystem

Maven vs Gradle

	Maven	Gradle
Build file	pom.xml (XML, verbose but predictable)	build.gradle(.kts) (Groovy/Kotlin DSL)
Convention	Strong	Strong + flexible
Speed	Fine, not incremental	Incremental, daemon, parallel — faster for large repos
Learning curve	Shallow	Steeper (esp. plugins)

For most Spring Boot apps, Maven is enough. Gradle wins in polyglot / monorepo / custom-tooling contexts.

Maven dependency scopes

Scope	Compile	Test	Runtime	Packaged in WAR/JAR
compile (default)	✓	✓	✓	✓
provided	✓	✓
runtime		✓	✓	✓ (e.g., JDBC driver)
test		✓
system	legacy, avoid
import	for BOMs only

BOMs

A Bill Of Materials pins versions for a set of related deps. Spring Boot's starter parent / spring-boot-dependencies BOM manages versions for hundreds of libraries — you declare without <version> and get coherent versions.

Lombok

Generates boilerplate at compile time via an annotation processor.

Annotation	Generates
@Getter/@Setter	Accessors
@RequiredArgsConstructor	Constructor for final + @NonNull fields
@AllArgsConstructor / @NoArgsConstructor	As named
@Data	@Getter + @Setter + @ToString + @EqualsAndHashCode + @RequiredArgsConstructor
@Value	Immutable @Data (all final)
@Builder	Fluent builder
@Slf4j	private static final Logger log = ...

Gotchas:

• Debugging: stack traces point to synthetic methods; IDE plugin required.
• @Data on JPA entities: equals/hashCode include all fields, including lazy relations → performance disaster. Prefer @Getter/@Setter + hand-written equals/hashCode based on ID.
• Jackson and Lombok mostly cooperate; occasionally need @JsonPOJOBuilder for @Builder.
• In Java 17+ with records, you often don't need Lombok for DTOs.

Logging

Stack of choice: SLF4J API + Logback or Log4j2 binding.

private static final Logger log = LoggerFactory.getLogger(MyService.class);

log.info("processed {} records", count);    // parameterized — no string build if level off
log.error("processing failed", ex);          // pass exception as LAST arg; don't concatenate

MDC (Mapped Diagnostic Context) — per-thread key-value store for log context:

MDC.put("traceId", traceId);
try { … } finally { MDC.remove("traceId"); }

With virtual threads, MDC works via ThreadLocal so the same hygiene applies. Scoped values are a future replacement.

Core libraries

Lib	Use
Jackson	JSON (de)serialization. Ship by default.
Caffeine	In-memory cache. Window-TinyLFU eviction, size/time-based. Default pick over legacy Guava Cache.
Guava	Misc (immutable collections pre-Java-9, hashing, preconditions). Less essential now.
Apache Commons Lang/IO	StringUtils, IOUtils. Useful but smaller surface with modern Java.
MapStruct	Compile-time bean mapping. Much better than ModelMapper's reflection.
Resilience4j	Circuit breaker, retry, bulkhead.

---

20. Connect to Your Experience

Stories to anchor abstract topics. Drop these specifics into behavioral / technical answers.

Anchor example: legacy MQ microservice (10k+ tx/day)

• Thread sizing — tune listener container concurrency vs downstream DB pool. Size the pool via Little's Law (concurrency = rate × latency).
• Memory leak investigation — capture a heap dump in prod under pressure; a common find is a growing MDC on a pooled thread, fixed by MDC.clear() in the listener's finally.
• Backpressure — throttle consumer concurrency when downstream latency spikes to avoid cascading OOM.
• GC tuning — move from Parallel to G1 with -XX:MaxGCPauseMillis=100 after pause-related SLO misses.

Anchor example: cross-team schema standardization

• Schema evolution — enforce backward compatibility via schema registry; block breaking changes at CI.
• Serialization internals — Avro's compactness vs JSON's 10× overhead on a 10k-tx/day feed.
• Records as DTOs — use Java records for the generated domain types' container classes.
• Pairs directly with §15 Serialization.

Anchor example: JAXB migration from Thymeleaf

• XML parsing + XXE — harden XMLInputFactory (XMLConstants.FEATURE_SECURE_PROCESSING, disable DTDs and external entities). See §15.
• Generics in generated code — JAXBElement<T> wrapper and ObjectFactory patterns.
• Classloader quirks — JAXB moved out of the JDK in Java 11; add jakarta.xml.bind dependency explicitly.

Anchor example: ArgoCD rollouts (99% deploy success rate)

• Containerized JVM tuning — -XX:+UseContainerSupport (on by default 10+), -XX:MaxRAMPercentage=75.0 over hard -Xmx so pod resizing stays coherent.
• Liveness/readiness — tie startup probe delays to actual app init time; use Spring Actuator /health/liveness and /health/readiness.
• Rollback drills — argocd app rollback vs git revert; practice both.

Anchor example: mentoring a ~20-person intern cohort

• The exact topics juniors trip on: == vs equals, mutability, HashMap with mutable keys, ThreadLocal leaks, Optional.get() without isPresent.
• Build a small katalog (immutable class, thread-safe cache, streaming transform) — these are the problems to drill on.

---

21. Rapid-Fire Review

One-liners for each of the 30 INTERVIEW_PREP §1 questions. Morning-of.

1. == vs .equals() — == is reference identity; .equals() is logical equality. Override equals + hashCode together.
2. hashCode/equals contract — equal objects must have equal hashCodes. Break it → HashMap.get() returns null on an "equal" key; duplicates in HashSet.
3. ArrayList vs LinkedList vs Vector — ArrayList default (O(1) index, O(n) insert-middle); LinkedList rarely wins due to cache misses; Vector legacy, synchronized, skip.
4. HashMap vs LinkedHashMap vs TreeMap vs ConcurrentHashMap — unordered / insertion-order / sorted / thread-safe. CHM uses per-bucket locking + CAS.
5. HashMap internals (8+) — bucket array, chain → red-black tree at 8 nodes (and table ≥ 64), back to list at 6. Load factor 0.75.
6. Checked vs unchecked — checked = compile-time enforced, for recoverable; unchecked = programmer error. Spring leans unchecked.
7. try-with-resources — auto-closes AutoCloseable in reverse declaration order; suppressed exceptions on e.getSuppressed().
8. Immutability — final class + final fields + no setters + defensive copies + no leaking this. Thread-safe by construction.
9. String vs StringBuilder vs StringBuffer — immutable / mutable unsync / mutable sync. Builder for loops; Buffer legacy.
10. String pool — literals interned to a single heap instance; new String("x") creates a fresh object. Use .intern() to canonicalize.
11. Type erasure — generics are compile-time; at runtime T is Object (or bound). Hence no new T(), no T[], no instanceof T.
12. PECS — Producer Extends, Consumer Super. List<? extends T> read-only-of-T; List<? super T> write-T.
13. Optional — return types only. Not for fields / params / collection elements.
14. Streams intermediate vs terminal — intermediate lazy, terminal triggers execution. Short-circuiting ops stop early.
15. map vs flatMap — 1:1 transform vs 1:many with flattening (Stream<Stream<T>> → Stream<T>).
16. parallelStream pitfalls — ForkJoin common pool, shared state races, blocking I/O monopolizes the pool, small N is overhead. Benchmark.
17. Functional interfaces — Function, Predicate, Consumer, Supplier, BiFunction, UnaryOperator, BinaryOperator.
18. Records — compiler-generated final fields / constructor / accessors / equals+hashCode+toString. Not for mutable state or inheritance.
19. Sealed classes — permits list restricts hierarchy; subclasses final/sealed/non-sealed. Enables exhaustive switches.
20. Pattern matching — obj instanceof User u binds; switch on types and record patterns destructures; when adds guards.
21. Text blocks — """…"""; common indentation stripped. Great for embedded JSON/SQL/XML.
22. Virtual threads — lightweight, JVM-scheduled, M:N on carrier threads. Great for blocking I/O at scale. Pinning on synchronized (improved in 24+) and JNI is the main gotcha.
23. JVM memory — heap (young: Eden+S0+S1, old) + metaspace (class metadata, native) + stack per thread. String pool in heap since 7.
24. SOE vs OOM — SOE: deep recursion, per-thread stack. OOM: heap / metaspace / direct buffer / GC-overhead. Dump heap + MAT for OOM.
25. G1 vs ZGC vs Shenandoah — G1 default balanced; ZGC sub-ms on large heaps; Shenandoah similar, Red Hat origin. Pick ZGC for strict latency SLOs.
26. Leak analysis — jcmd <pid> GC.heap_dump → MAT dominator tree + leak suspects. Root causes: ThreadLocal in pools, static caches, inner-class outer refs, classloader leaks.
27. final / finally / finalize — final no-reassign/override/extend; finally always runs (except JVM death); finalize deprecated, use AutoCloseable/Cleaner.
28. Serializable dangers — gadget chains → RCE. Use Object Input Filters if forced; prefer JSON/Avro/Protobuf.
29. JPMS — named modules, exports/requires/opens, strong encapsulation. Most pain is --add-opens in reflection-heavy frameworks.
30. Null safety — Objects.requireNonNull at boundaries; @Nullable/@NonNull annotations; Optional for return types only. -XX:+ShowCodeDetailsInExceptionMessages (default 14+).

---

22. Practice Exercises

Tier 1 — Code from memory

Set a timer; no IDE help.

A. Immutable Event class

• Fields: String id, Instant timestamp, List<String> tags, Map<String, String> attrs.
• Truly immutable: final class, defensive copies, equals / hashCode based on id.
• toString useful for logs.

B. LRU cache with LinkedHashMap

public class Lru<K,V> extends LinkedHashMap<K,V> {
    private final int cap;
    public Lru(int cap) { super(cap, 0.75f, true); this.cap = cap; }
    @Override protected boolean removeEldestEntry(Map.Entry<K,V> e) {
        return size() > cap;
    }
}

• Then rewrite it from scratch using HashMap + doubly-linked list.

C. Thread-safe singleton

• Eager (preferred):

public final class Reg { public static final Reg INSTANCE = new Reg(); private Reg() {} }

• Enum (Effective Java Item 3): public enum Reg { INSTANCE; }
• Lazy double-checked locking (for the record):

private static volatile Reg instance;
public static Reg get() {
    Reg r = instance;
    if (r == null) synchronized (Reg.class) {
        if ((r = instance) == null) r = instance = new Reg();
    }
    return r;
}

D. Correct equals / hashCode

• Write one for a class with long id, String name, LocalDate dob. Use Objects.hash(...). Satisfy all five equals rules.

Tier 2 — Predict the output

Run through the 15 gotchas in §18 without peeking. Target: 12/15 right.

Tier 3 — Mini design

A. Memoizing function cache

• Implement <T,R> Function<T,R> memoize(Function<T,R> fn) thread-safe using ConcurrentHashMap.computeIfAbsent. Handle null returns correctly. Add optional size cap (Caffeine-style) as a stretch.

B. Min-and-max in one stream pass

• Write a Collector<Integer, ?, int[]> that returns {min, max} in a single pass. Use Collector.of(...). Handle the empty case. Then bonus: support a combiner for parallel streams.

C. Safe ThreadLocal-based request context

• Build RequestContext with set(ctx), get(), clear(), and a run(ctx, Runnable) helper that always clears in a finally. Write a tiny JUnit test that proves reuse across a FixedThreadPool doesn't leak state.

Spaced-review checklist

Mark ✅ / 🔁 / ❌ per section. Repeat ❌ daily, 🔁 every other day, ✅ weekly.

• [ ] §1 Basics
• [ ] §2 OOP
• [ ] §3 Strings
• [ ] §4 Immutability
• [ ] §5 Exceptions
• [ ] §6 Generics
• [ ] §7 Collections
• [ ] §8 Functional
• [ ] §9 Modern Java (especially sealed, pattern matching, virtual threads)
• [ ] §10 JVM memory
• [ ] §11 GC
• [ ] §12 Concurrency refresher
• [ ] §13 I/O
• [ ] §14 Reflection / annotations
• [ ] §15 Serialization
• [ ] §16 JPMS
• [ ] §17 Null safety
• [ ] §18 Gotchas (drill 15)
• [ ] §19 Build / ecosystem
• [ ] §20 Experience tie-ins

---

Further reading

• Java Language Spec (JLS) and JVM Spec — definitive source of truth.
• Effective Java (Joshua Bloch, 3rd ed.) — items 17 (immutability), 18 (composition over inheritance), 49 (param validation), 80 (executors over threads).
• Java Concurrency in Practice (Goetz) — the JMM / concurrency reference. Companion to the future CONCURRENCY.md.
• Oracle JEPs — authoritative notes on every new feature. Cross-reference rather than blog posts.
• Inside.java — Oracle's technical blog; good for Loom / Amber / Valhalla developments.

---

Next in the series: CONCURRENCY.md (full depth on executors, locks, CompletableFuture, ForkJoin, virtual threads internals, structured concurrency), then SPRING_BOOT.md.