53 Senior Java Interview Questions and Answers (2026)

In Java 8+, a HashMap resolves collisions by chaining entries in the same bucket, and once a bucket grows too long it converts that chain from a linked list into a Red-Black Tree to improve lookup from O(n) to O(log n).

• Collision handling: Keys hashing to the same bucket index are stored as nodes; the map walks them comparing with hashCode() then equals().

• Treeification thresholds:

  1. A bucket converts to a tree when its chain reaches TREEIFY_THRESHOLD (8) entries,

  2. AND the table capacity is at least MIN_TREEIFY_CAPACITY (64); otherwise it just resizes the table instead.

• Untreeify: On removal/resize, a tree bucket shrinks back to a list when it drops to UNTREEIFY_THRESHOLD (6).

• Why a tree: it bounds worst-case collision cost (e.g. malicious or poor hash distributions) to O(log n), mitigating hash-collision DoS attacks.

A HashMap stores entries in an array of buckets indexed by the key's hash; entries colliding in one bucket are chained, and Java 8 upgrades long chains to balanced trees for faster lookup.

• Bucket placement: Index is computed from the key's hash, spread by (h = key.hashCode()) ^ (h >>> 16) then masked with (n - 1) so high bits influence the slot.

• LinkedList to TreeNode transition:

  1. Colliding entries start as a singly-linked chain of Node objects.

  2. When a bucket's length reaches 8 and table capacity is ≥ 64, the chain is treeified into TreeNode objects forming a Red-Black Tree (O(log n) lookup).

  3. If capacity is below 64, the map resizes instead of treeifying.

  4. A tree reverts to a list when its size falls to 6.

• Resizing: At size > capacity * loadFactor (default 0.75) the table doubles and entries are rehashed/split.

LinkedList wins only when you do frequent inserts/removals at the ends (or via an already-positioned iterator) and rarely random-access, since modern CPUs heavily favor the contiguous memory of ArrayList.

• Queue/Deque workloads: Constant-time addFirst()/removeFirst() make it a natural FIFO queue; ArrayList front removal is O(n) due to shifting.

• Mid-list edits during iteration: Removing/inserting via a ListIterator already at the spot is O(1) (relink nodes), versus O(n) array shifting.

• The cache caveat: Each node is a separate heap object, so traversal causes cache misses and pointer chasing; for plain iteration or random access ArrayList usually wins even where Big-O looks equal.

• Bottom line: In practice ArrayDeque often beats LinkedList for queue/stack needs too, so true wins are narrow.

ConcurrentHashMap allows concurrent reads with no locking and localizes write contention to individual buckets; Java 8 replaced the older fixed segment locks with fine-grained per-bucket synchronization plus CAS, greatly improving concurrency.

• Pre-Java 8: segment locking: The map was split into a fixed number of segments (default 16), each a separately locked sub-table; concurrency was capped at the segment count.

• Java 8: bucket-level CAS + synchronized:

  • Segments were dropped; inserting into an empty bucket uses a lock-free CAS on the bin head.

  • When a bucket already has entries, it locks only that bucket's first node with synchronized, so unrelated buckets proceed in parallel.

• Reads are lock-free: Nodes use volatile fields for visibility, so get() never locks.

• Other guarantees: Treeifies long buckets like HashMap, forbids null keys/values, and provides weakly-consistent (fail-safe) iterators.

Both signal that a class can't be loaded, but ClassNotFoundException is a checked exception thrown during explicit dynamic loading, while NoClassDefFoundError is an Error thrown by the JVM when a class present at compile time is missing at runtime.

• ClassNotFoundException:

  • A checked Exception thrown when code asks the loader for a class by name and it isn't found.

  • Triggered by Class.forName(), ClassLoader.loadClass(), etc.

• NoClassDefFoundError:

  • An Error (unchecked) thrown when the class compiled fine but is absent from the classpath at runtime.

  • Also thrown if a class's static initializer previously failed, leaving it unusable.

• Rule of thumb:

  • Exception = you tried to load it dynamically and it wasn't there.

  • Error = the JVM expected it (a normal reference) and couldn't link it.

parallelStream() splits work across multiple threads to use more cores, but it adds overhead and correctness risks, and by default all parallel streams in the JVM share one ForkJoinPool.commonPool(), so they compete for the same threads.

• Correctness risks:

  • Shared mutable state or non-thread-safe collectors cause race conditions; lambdas must be stateless and side-effect-free.

  • Operations that depend on encounter order (forEachOrdered, limit) may behave differently or lose performance.

• Performance risks:

  • Splitting, thread coordination, and merging add overhead; small datasets often run slower than sequential.

  • Sources that split poorly (LinkedList, iterator-based) gain little; ArrayList and arrays split well.

• The shared common pool:

  • Default size is availableProcessors() - 1, shared across the whole JVM.

  • A blocking call (I/O, locks) inside a parallel stream ties up common-pool threads and can starve other parallel tasks application-wide.

  • To isolate work, submit the stream inside your own ForkJoinPool so it doesn't run on the common pool.

• Rule of thumb: use it only for large, CPU-bound, easily-split, independent workloads, and measure.

Parallel streams are detrimental when the dataset is small, the per-element work is cheap, the source splits poorly, or the operation isn't truly stateless: the splitting/merging overhead and thread coordination then cost more than they save. They also share the JVM-wide common ForkJoinPool, so a long parallel task can starve unrelated parts of the app.

• When parallelism hurts:

  1. Small collections: fork/join setup dominates.

  2. Poorly splittable sources like LinkedList or stream from an iterator (vs ArrayList/arrays which split evenly).

  3. Operations with shared mutable state, ordering requirements, or blocking I/O inside the lambda.

  4. Cheap per-element work where memory bandwidth, not CPU, is the limit.

• The shared ForkJoinPool problem:

  • By default all parallel streams use ForkJoinPool.commonPool(), sized to CPU cores minus one.

  • A blocking or long-running parallel stream occupies those threads, so other parallel streams (or anything using the common pool) queue up and stall.

  • Workaround: run the pipeline inside your own ForkJoinPool via submit, or avoid parallel streams for blocking work.

• Rule of thumb: Parallelize only large, CPU-bound, stateless, easily-splittable workloads, and measure before trusting it.

The Closed World Assumption means a sealed type declares the complete, finite set of subtypes that may extend it, so the compiler knows every possible implementation at compile time.

• "Closed" set of subtypes: A sealed type's permits clause lists exactly which classes/interfaces may extend it, no others allowed.

• Enables exhaustiveness checking:

  • In a switch over a sealed type, if every permitted subtype is handled, no default branch is required and the compiler proves all cases are covered.

  • Add a new subtype later and the switch fails to compile until you handle it: errors caught at compile time, not runtime.

• Contrast with the open world: A normal (non-sealed) class can be extended by anyone, so the compiler must assume unknown subtypes exist and always demands a default.

An Algebraic Data Type models data as a fixed set of alternatives (a "sum" of types), where each alternative holds a fixed set of fields (a "product" of values). In Java, sealed types express the closed set of alternatives and records express each alternative's data, giving you a type-safe, exhaustively-checkable model.

• Sum types (the "or"): A sealed interface or sealed class lists its permitted subtypes, so the value is exactly one of them.

• Product types (the "and"): Each record bundles a fixed group of fields that travel together.

• How they combine:

  • Records implements the sealed interface, forming the closed family of cases.

  • Consumers use switch with record/type patterns to deconstruct each case; the compiler proves all cases are handled.

• Why it matters: You move behavior out of the data (no scattered polymorphic methods) and centralize it in exhaustive switches: adding a case forces every switch to be updated.

Sealed types let an author declare a closed, known set of permitted implementations, turning an open hierarchy into a finite one the compiler can reason about. That closure is what makes switch pattern matching exhaustive and therefore reliable.

• Architectural benefits:

  • Controlled extension: permits names exactly which types may extend/implement, documenting and enforcing the design.

  • Models a finite domain (the ADT "sum" of cases) so the type system mirrors the problem.

  • Stronger encapsulation of a hierarchy than public + convention without going fully final.

• Reliability for switch:

  • The compiler knows every possible subtype, so it can prove a switch is exhaustive without a catch-all default.

  • Adding a new permitted type causes existing switches to fail compilation until updated: errors surface at build time, not runtime.

  • Avoiding a defensive default means genuinely unhandled cases are caught rather than silently swallowed.

The Java Memory Model defines the rules for how and when writes by one thread become visible to others, and what reorderings the compiler/CPU may perform. "Happens-before" is the core ordering relation: if action A happens-before action B, then A's effects are guaranteed visible to and ordered before B.

• Why the JMM exists:

  • Compilers, CPUs, and caches reorder and buffer memory operations for speed, so without rules a thread might never see another's updates (visibility) or see them out of order (ordering).

  • The JMM is the contract that says which behaviors are guaranteed versus undefined (a data race).

• Happens-before guarantees:

  • Program order: actions in a single thread happen-before later actions in that same thread.

  • Monitor lock: unlocking a synchronized block happens-before a subsequent lock of the same monitor.

  • Volatile: a write to a volatile field happens-before every later read of that field.

  • Thread start/join: Thread.start() happens-before the thread's run; the thread's actions happen-before a successful join().

  • Transitivity: if A happens-before B and B happens-before C, then A happens-before C.

• Data races:

  • Two accesses to the same non-final field, at least one a write, with no happens-before relation, is a race: results are unpredictable.

  • Use synchronized, volatile, final, or java.util.concurrent tools to establish the needed ordering.

• Key insight: correctness comes from establishing happens-before edges, not from how fast or in what wall-clock order threads appear to run.

Happens-before is the JMM's ordering guarantee: if action A happens-before action B, then A's memory effects are visible to and ordered before B. Without such a relationship, the JVM/CPU may reorder or cache writes, so one thread may never see another's changes.

• What it actually means: It is a guarantee of visibility plus ordering, not necessarily real-time sequence: B is guaranteed to observe everything A did.

• Common happens-before edges:

  • Program order within a single thread.

  • Unlocking a monitor happens-before a later lock of the same monitor.

  • A volatile write happens-before a subsequent read of that same field.

  • Thread.start() happens-before the started thread's actions; a thread's actions happen-before another thread returning from its join().

• Why it is critical: Thread safety means establishing a happens-before chain between a write in one thread and a read in another; without it, no visibility is promised and data races result.

The JMM is the specification defining how and when writes by one thread become visible to others, and which reorderings the compiler/CPU may perform. A thread can see a partially initialized object because, absent proper synchronization, the publication of a reference can be reordered ahead of the writes that initialize the object's fields.

• What the JMM defines:

  • The rules of visibility, atomicity, and ordering across threads, formalized through happens-before relationships.

  • It permits aggressive optimizations (caching in registers, instruction reordering) as long as single-threaded semantics are preserved.

• Why partial initialization happens:

  • Writing the field values and writing the reference are separate stores that may be reordered, so another thread can read a non-null reference before the constructor's writes are visible.

  • This is the classic broken double-checked locking bug when the field is not volatile.

• How to prevent it:

  • Publish safely: store the reference in a volatile field, a final field, or behind synchronization to establish happens-before.

  • final fields get a special guarantee: their correctly constructed values are visible without extra synchronization.

False sharing happens when two threads update different variables that happen to live on the same CPU cache line: each write invalidates the line in the other core's cache, forcing constant cache-coherence traffic even though the threads never touch the same data. @Contended fixes it by padding fields so hot variables land on separate cache lines.

• The root cause: cache lines, not variables:

  • CPUs move memory in fixed blocks (typically 64 bytes); two adjacent fields can share one line.

  • A write by one core marks the whole line dirty, so the other core must re-fetch it (ping-ponging), killing scalability.

• How @Contended helps:

  • Introduced in Java 8 (in jdk.internal.misc/sun.misc), it pads the annotated field(s) with empty bytes so they occupy their own cache line.

  • Requires the JVM flag -XX:-RestrictContended to use it outside the JDK.

  • Used internally by LongAdder and the JDK's striped counters.

• Tradeoff: it trades memory (padding bytes) for throughput, so apply it only to genuinely hot, independently-written fields.

Happens-before is the JMM's ordering guarantee: if action A happens-before action B, then A's memory effects are visible to B and ordered before it. volatile establishes such a relationship so reads see the latest write (visibility), but a single volatile access can't make a read-modify-write sequence indivisible (atomicity).

• What happens-before guarantees:

  • It is a partial ordering across threads that makes one thread's writes visible to another, preventing reordering across the barrier.

  • Common edges: program order within a thread, unlock then lock of the same monitor, a volatile write then a subsequent read of it, Thread.start(), and Thread.join().

• Why volatile fixes visibility: A write goes to main memory and a read always fetches fresh, so threads never see stale cached copies.

• Why it does NOT give atomicity:

  • Operations like count++ are read-modify-write: three steps. Two threads can both read the same value, both increment, and one update is lost.

  • For compound actions use AtomicInteger, a lock, or synchronized.

Use StampedLock when reads vastly outnumber writes and you want to avoid even the overhead of acquiring a read lock: its optimistic read mode lets you read with no locking at all and then validate. The tradeoffs are that it is not reentrant, not directly tied to Condition, and optimistic reads can fail and need a fallback.

• Prefer StampedLock when:

  • Read-heavy workloads where ReentrantReadWriteLock's read-lock bookkeeping becomes a bottleneck.

  • You can tolerate retrying a read if a write intervenes.

• How optimistic reading works:

  • Call tryOptimisticRead() to get a stamp, read the fields, then call validate(stamp).

  • If a write happened in between, validate returns false and you fall back to a real read lock.

• Tradeoffs / pitfalls:

  • Not reentrant: re-acquiring in the same thread can deadlock.

  • No Condition support and not directly interruptible like the reentrant locks.

  • Optimistic reads must copy values into locals before validating; never act on data read but not yet validated.

Atomic classes like AtomicInteger provide lock-free, thread-safe updates by relying on Compare-And-Swap (CAS), a single hardware instruction that atomically updates a value only if it still holds the value you expected.

• How CAS works:

  • CAS takes three inputs: the memory location, the expected value, and the new value.

  • It writes the new value only if the current value equals the expected one, all in one uninterruptible CPU instruction (e.g. cmpxchg).

• How the atomic classes use it:

  • Methods like incrementAndGet() loop: read the current value, compute the new one, CAS it; retry if another thread won the race.

  • The field is volatile so reads are always fresh.

• Tradeoffs:

  • Lock-free and fast under low contention; under heavy contention the retry loop wastes CPU (consider LongAdder).

  • Vulnerable to the ABA problem; use AtomicStampedReference when identity of intermediate changes matters.

Confirm it's a real leak (not just a large working set) by watching heap usage across full GCs, then capture heap dumps to find which objects accumulate and who keeps them alive.

• Confirm the trend, not a single spike:

  • Watch heap after full GCs over time: if the post-GC live set keeps rising and never returns, it's a leak, not transient load.

  • Use jstat -gcutil, JMX, or GC logs (-Xlog:gc*) to see old-gen occupancy climbing.

• Capture and compare heap dumps:

  • Trigger with jmap -dump or auto-dump on OOM via -XX:+HeapDumpOnOutOfMemoryError.

  • Take two dumps at different times and diff them: classes whose instance count grows steadily are suspects.

• Analyze retention, not just size:

  • In Eclipse MAT or VisualVM, run a dominator tree and use Path to GC Roots to find what reference chain prevents collection.

  • Common culprits: unbounded caches/collections, static maps, unremoved listeners, ThreadLocals.

• Profile allocation in production-like load: Use async-profiler or JFR to see allocation hotspots feeding the growth.

Escape analysis is a JIT optimization that determines whether an object's reference escapes the method or thread that created it; if it doesn't, the JVM can avoid heap allocation entirely, including via scalar replacement where the object's fields are treated as independent local values.

• What escape analysis decides:

  • No escape: the object never leaves the method (not returned, not stored in a field, not passed where it could be retained).

  • Arg/global escape: reference becomes visible to other methods or threads, so it must live on the heap.

• Scalar replacement:

  • If an object doesn't escape, the JIT can decompose it: its fields become separate local variables (scalars) held in registers or on the stack.

  • The object is never actually allocated, so no header, no GC pressure.

• Related optimizations it enables: Stack allocation and lock elision (removing synchronization on thread-local objects).

• Caveat: It's a runtime JIT decision (controlled by -XX:+DoEscapeAnalysis, on by default), not something the source guarantees.

An OutOfMemoryError reports more than just a full heap: it can come from exhausting other memory regions, hitting GC overhead limits, or being unable to find a large contiguous block despite total free space.

• It's not always the heap:

  • OutOfMemoryError: Metaspace: too many loaded classes (classloader leaks).

  • unable to create new native thread: OS/native thread limit, not heap.

  • Direct buffer / native memory exhaustion from ByteBuffer.allocateDirect.

• GC overhead limit: GC overhead limit exceeded: GC runs constantly reclaiming almost nothing, so the JVM gives up even with some free space.

• Fragmentation / contiguous allocation: Requested array exceeds VM limit or a huge array needs a contiguous region the fragmented heap can't provide.

Double brace initialization uses an anonymous inner class plus an instance initializer block to populate a collection in one expression; it leaks because that anonymous subclass holds an implicit reference to the enclosing instance.

• What it actually creates:

  • The outer braces create an anonymous subclass of the collection; the inner braces are an instance initializer that runs add() calls.

  • So you get an extra class and an extra object, not a plain collection.

• Why it leaks:

  • A non-static anonymous inner class keeps a hidden reference to this (the enclosing object).

  • If the collection outlives the enclosing instance (cached, returned, stored statically), it pins that whole enclosing object in memory.

• Other costs: Extra classes bloat Metaspace and slow class loading.

• Better alternatives: List.of(...), Map.of(...), or Arrays.asList(...) / a builder.

Metaspace (since Java 8) stores class metadata in native memory instead of the fixed-size PermGen region of the heap, so it grows dynamically and fails differently: typically from classloader leaks exhausting native memory rather than a small preset cap.

• PermGen (pre-Java 8):

  • Part of the Java heap with a fixed max (-XX:MaxPermSize); easy to exhaust, giving OutOfMemoryError: PermGen space.

  • Also held interned strings and static data, complicating sizing.

• Metaspace (Java 8+):

  • Allocated in native memory, auto-grows by default, so it rarely fills from normal class counts.

  • Bounded by -XX:MaxMetaspaceSize (unbounded if unset) and a high-water mark that triggers GC of unused classes.

• Why the OOM differs:

  • OutOfMemoryError: Metaspace almost always means a classloader leak: classloaders (and their classes) stay reachable and accumulate.

  • Common in app servers redeploying repeatedly, or heavy dynamic proxy/bytecode generation.

new ArrayList() allocates an object in the heap (usually in the young generation's Eden space): the reference variable lives on the stack, while the object itself carries a header plus its fields, and the JVM tracks its survival count in that header to decide promotion.

• Where things live:

  • The local variable (the reference) is on the thread's stack.

  • The ArrayList object and its backing array are on the heap, typically Eden first.

• Object header: Stored at the start of the object on the heap, it holds the mark word (identity hash, lock state, GC age bits) and a klass pointer to the class metadata in Metaspace.

• How age is tracked:

  • Each minor GC that the object survives increments an age counter in the mark word.

  • Surviving objects are copied between survivor spaces; once age crosses -XX:MaxTenuringThreshold (or survivor space fills), it's promoted to the old generation.

• Possible optimization: If escape analysis proves the list never escapes, the JIT may skip heap allocation entirely.

Local primitives live on the stack because they have fixed size and method-bounded lifetime, while objects go on the shared heap since their lifetime can outlive the method and their references can be shared; escape analysis lets the JIT put non-escaping objects on the stack too.

• Why primitives on the stack:

  • A local primitive (or reference) is a fixed-size slot in the method's stack frame, allocated/freed automatically when the frame pushes/pops.

  • No sharing across threads or methods, so no GC needed.

• Why objects on the heap:

  • Objects can be referenced from many places and outlive the creating method, so they need a managed region the GC oversees.

  • Note: primitive fields of an object live inside that object on the heap, not on the stack.

• Escape analysis exception:

  • If the JIT proves an object never escapes its method or thread, it can stack-allocate or scalar-replace it, getting heap-free allocation with stack-like cleanup.

  • Enabled by default via -XX:+DoEscapeAnalysis; it's a runtime decision, so behavior can vary.

G1 is a region-based, mostly-concurrent collector tuned for balanced throughput and predictable pauses; ZGC is a fully concurrent, scalable low-latency collector that keeps pauses sub-millisecond regardless of heap size.

• G1 (Garbage-First):

  • Divides the heap into equal-sized regions and still uses Young/Old generations logically.

  • Pauses scale with heap and live-set size: typically tens to low hundreds of milliseconds.

  • Does evacuation (copying live objects) during stop-the-world pauses, aiming to meet a pause-time goal.

• ZGC:

  • Almost all work (marking, relocation) is concurrent; pauses stay under ~1ms and don't grow with heap size.

  • Uses colored pointers and load barriers to relocate objects while the application runs.

  • Designed for very large heaps (hundreds of GB to terabytes).

• Trade-off: ZGC prioritizes latency, sometimes at slightly higher CPU/throughput cost; G1 balances throughput and latency for general workloads.

G1 balances throughput and pause time for general-purpose apps, while ZGC is fully concurrent with sub-millisecond pauses; for a strict low-latency application, prefer ZGC.

• Key differences:

  • G1 evacuates objects during STW pauses; pause time grows with live-set size (tens to hundreds of ms).

  • ZGC relocates concurrently using colored pointers and load barriers; pauses are constant and sub-ms regardless of heap size.

• When to prefer ZGC:

  • Latency-sensitive systems (trading, real-time APIs) where multi-hundred-ms pauses are unacceptable.

  • Very large heaps where G1 pauses would scale up badly.

• When to prefer G1:

  • Throughput-oriented or moderate-heap apps where occasional tens-of-ms pauses are fine.

  • You want the well-tested default with lower CPU overhead.

• Enable with -XX:+UseZGC or -XX:+UseG1GC.

ZGC keeps pauses sub-millisecond by doing nearly all GC work concurrently with the application, using colored pointers and load barriers so it can relocate objects without stopping threads; its pause cost is fixed and independent of heap or live-set size.

• Colored pointers:

  • Metadata bits (marked, remapped, etc.) are stored inside the 64-bit reference itself.

  • The GC reads an object's state directly from the pointer, no extra lookup.

• Load barriers:

  • A small check runs whenever a reference is loaded; if the object was relocated, the barrier fixes the pointer on the fly ('self-healing').

  • This lets relocation happen concurrently while threads keep running.

• Concurrent phases: Marking, relocation, and remapping all happen alongside the app; only tiny root-scanning pauses are STW.

• Why heap size doesn't matter: Pause work is proportional to the thread/root count, not the amount of live data, so a 16GB and a 16TB heap pause similarly.

G1 is a region-based collector that does evacuation in STW pauses and balances throughput with predictable (but heap-dependent) pauses, while ZGC is fully concurrent with fixed sub-millisecond pauses; choose ZGC when latency must stay low on large heaps.

• Primary differences:

  • Pause behavior: G1 pauses scale with live data; ZGC pauses are constant and sub-ms.

  • Concurrency: G1 copies objects during pauses; ZGC relocates concurrently via load barriers and colored pointers.

  • Heap scale: G1 suits moderate heaps; ZGC scales to terabytes without growing pauses.

  • Cost: ZGC's barriers add some throughput/CPU overhead versus G1.

• Choose ZGC when:

  • The application has strict latency SLAs (e.g. p99 under a few ms) and can't tolerate long pauses.

  • Heaps are very large, where G1's pause times would become unacceptable.

• Otherwise: G1 (the default since Java 9) is the safe choice for general throughput-focused services.

Type erasure is how Java implements generics: the compiler enforces type checks at compile time, then erases type parameters from the bytecode, replacing them with their bounds (or Object) and inserting casts. This keeps generics backward-compatible with pre-generics code but means generic type info doesn't exist at runtime.

• What happens at compile time:

  • List<String> becomes List in bytecode; <T> becomes Object (or its bound, e.g. <T extends Number> becomes Number).

  • The compiler inserts casts and synthetic bridge methods to preserve polymorphism.

• Limitations it causes:

  • No runtime type info: you can't do obj instanceof List<String> or get T.class.

  • Can't instantiate type parameters: new T() or new T[] are illegal.

  • No overloading on generic type: foo(List<String>) and foo(List<Integer>) clash (same erasure).

  • Static fields can't be of type T, and primitives can't be type arguments (forcing boxing).

• Workarounds: Pass a Class<T> token when runtime type is needed (e.g. clazz.newInstance()).

PECS is a guideline for choosing bounded wildcards: use <? extends T> when a structure produces (you read from) values, and <? super T> when it consumes (you write into) values.

• Producer Extends:

  • A List<? extends Number> is a source you read from: every element is at least a Number, so reads are safe.

  • You cannot add (except null): the exact subtype is unknown.

• Consumer Super:

  • A List<? super Integer> is a sink you write into: it accepts any Integer because the list holds that type or a supertype.

  • Reads only give back Object, since the exact supertype is unknown.

• Both (read and write): use an exact type T with no wildcard.

• Canonical example: Collections.copy(List<? super T> dest, List<? extends T> src).

Type erasure strips generic type parameters at compile time, leaving only raw types (with Object or bounds) at runtime. Primitives can't be type arguments because erasure assumes reference types, and Project Valhalla aims to lift that restriction via value types and specialized generics.

• Erasure and primitives:

  • Generic code operates on Object references; primitives aren't objects, so only wrappers like Integer are allowed.

  • This forces autoboxing, which costs allocation and pointer chasing.

• How Project Valhalla helps:

  • Introduces value (inline) classes that have no identity and can be laid out flat in memory, like primitives.

  • Goal of "specialized generics": let List<int> exist with primitives stored directly, no boxing.

  • Aims to unify primitives and objects so generics work over both efficiently ("Codes like a class, works like an int").

• Status: still in development; current Java still requires wrapper types.

In a CompletableFuture pipeline, an exception completes the stage exceptionally and is propagated downstream, skipping normal stages until a handler stage catches it.

• Propagation behavior:

  • If a stage throws, dependent thenApply/thenCompose stages are skipped; the failure flows down until handled.

  • The exception is wrapped in a CompletionException when observed downstream or via join().

• Handling operators:

  • exceptionally(fn): recovers by supplying a fallback value when the stage failed.

  • handle(biFn): runs on both success and failure, receiving (result, throwable).

  • whenComplete(biConsumer): observes outcome without altering it (re-throws the original).

• Trap: if you never call get(), join(), or a handler, the exception can be silently swallowed.

The Fork/Join framework (ForkJoinPool) is built for divide-and-conquer parallelism: a task recursively splits (forks) into subtasks and combines (joins) their results. Work-stealing keeps all threads busy by letting idle threads pull tasks from others' queues.

• Core model:

  • Extend RecursiveTask<V> (returns a value) or RecursiveAction (no result).

  • fork() schedules a subtask asynchronously; join() waits for and merges its result.

  • Split until subtasks reach a small threshold, then compute directly.

• Work-stealing for load balancing:

  • Each worker thread has its own double-ended queue (deque) of tasks.

  • A thread pushes/pops its own tasks from one end (LIFO, cache-friendly).

  • An idle thread steals from the opposite end of a busy thread's deque, minimizing contention.

  • Result: uneven workloads self-balance without a central scheduler bottleneck.

• Used by parallelStream() via the common ForkJoinPool; avoid blocking I/O inside fork/join tasks since it ties up worker threads.

All three are java.util.concurrent synchronizers, but they coordinate threads differently: a latch waits for events to complete, a barrier waits for parties to meet, and a semaphore limits concurrent access to a resource.

• CountDownLatch: one-time gate:

  • Initialized with a count; threads call await() until countDown() drives it to zero.

  • Not reusable: once it hits zero it stays open. Use it to wait for N tasks to finish (e.g. main thread waits for workers to initialize).

• CyclicBarrier: reusable rendezvous:

  • A fixed number of threads each call await(); all are released only when the last arrives, then the barrier resets.

  • Can run an optional barrier action when tripped. Use for iterative/phased parallel algorithms where threads must sync at each step.

• Semaphore: permit-based throttle:

  • Holds a set of permits; acquire() takes one (blocking if none), release() returns one.

  • Use to bound concurrent access to a limited resource (connection pool, rate limiting). A binary semaphore can act as a lock.

• Key distinction: Latch counts down to release waiters once; barrier counts up arrivals and recycles; semaphore counts permits up and down repeatedly.

Pinning is when a virtual thread cannot unmount from its carrier platform thread while blocking, so it holds the OS thread captive. This defeats the scalability benefit and can starve the carrier pool.

• Normal behavior: During a blocking operation a virtual thread normally unmounts so the carrier can run others.

• When pinning happens:

  • Inside a synchronized block or method while blocking (pre-JDK 24): the thread stays mounted.

  • When calling a native method or foreign function via JNI/FFM while blocking.

• Why it matters: A pinned carrier can't serve other virtual threads; many pins can exhaust the carrier pool and reduce throughput.

• Mitigation: Replace synchronized around blocking I/O with ReentrantLock; diagnose with -Djdk.tracePinnedThreads. JDK 24 (JEP 491) largely eliminates the synchronized pinning case.

In early virtual-thread releases (JDK 21-23), blocking inside a synchronized block pins the virtual thread to its carrier, so it can't unmount and the OS thread is wasted while blocked. This undermines scalability if many threads block under the same monitor.

• The root cause: Monitor ownership in the JVM is tied to the underlying carrier thread, so the runtime can't safely unmount a virtual thread that holds a monitor.

• The practical risk:

  • A short synchronized block with no blocking inside is fine; the problem is blocking I/O while holding the monitor.

  • If the carrier pool gets fully pinned, throughput collapses or deadlock-like starvation appears.

• The fix:

  • Use java.util.concurrent.locks.ReentrantLock instead: it doesn't pin and supports unmounting.

  • JDK 24 (JEP 491) reworks monitors so synchronized no longer pins in most cases, so this concern is largely transitional.

Choose virtual threads when you want simple, readable, blocking-style code that still scales for I/O-bound workloads; choose reactive when you need fine-grained backpressure, stream composition, or must integrate with an existing reactive stack.

• Prefer virtual threads when:

  • Your workload is I/O-bound (many concurrent network/DB calls) and you want straightforward sequential code.

  • You value debuggability: normal stack traces, breakpoints, and try/catch work as usual.

  • You want to avoid the cognitive overhead and callback/operator chains of reactive APIs.

• Prefer reactive (Flux/Mono) when:

  • You need built-in backpressure to control fast producers vs slow consumers.

  • You're modeling streaming or event pipelines with rich operators (map, flatMap, buffer, windowing).

  • You already have a fully reactive codebase/framework where mixing styles would add friction.

• Key trade-off: Virtual threads solve the scalability problem of blocking without the complexity of reactive, but they don't provide backpressure or declarative stream composition out of the box.

Pinning is when a virtual thread cannot be unmounted from its carrier thread while blocked, so it holds the OS thread captive instead of releasing it. This defeats the scalability benefit because the carrier can't run other virtual threads during the block.

• What unmounting normally does: On a blocking call the JVM parks the virtual thread and returns the carrier to the pool.

• Scenario 1: inside a synchronized block/method: If the virtual thread blocks while holding a monitor, it stays pinned to the carrier (pre-Java 24 behavior).

• Scenario 2: native code / foreign function: Blocking inside a JNI or native frame also pins, because the JVM can't safely unwind it.

• Why it hurts: With a small carrier pool, many pinned threads can starve the application or even deadlock.

• Mitigation: Replace synchronized with ReentrantLock around blocking sections; diagnose with -Djdk.tracePinnedThreads=full. (JDK 24/JEP 491 largely removes synchronized pinning.)

Scoped values are designed for the virtual-thread world: they share immutable data within a bounded dynamic scope, avoiding the memory cost and leak risk of millions of ThreadLocal entries.

• Memory footprint:

  • A ThreadLocal allocates a per-thread value; with millions of virtual threads that multiplies into a serious heap cost.

  • A ScopedValue binds one immutable value visible to the scope, not copied per thread.

• Immutability and safety: Scoped values are read-only once bound, removing the unpredictable mutation that plagues ThreadLocal.

• Lifecycle / leak prevention: Bindings are automatically unbound when the run() block exits, so there is no stale-value or leak risk from forgetting remove().

• Inheritance to child tasks: Works cleanly with structured concurrency: forked subtasks inherit the binding without copying.