Java 9–25 Features & Virtual Threads — Interview Questions

How to use this lesson

Senior candidates are expected to know what shipped in which LTS, and which features change how you design code:

• records, sealed types and pattern matching give data-oriented programming;
• virtual threads give a thread-per-request comeback.

State preview versus final status accurately. It shows you actually follow the platform.

Q1. What is var (Java 10)? Is it just syntactic sugar?

Short answer: var is local variable type inference: the compiler infers the static type from the initialiser. The variable is still strongly and statically typed. It's syntactic sugar, with a few real capabilities:

• it can declare variables of non-denotable types: anonymous class types, and intersection types;
• it's usable in for loops, try-with-resources, and lambda parameters (Java 11, for annotations).

The limits:

• only for local variables with initialisers: no fields, parameters or return types;
• no var x = null;, and no array initialisers without new.

Style: use it when the type is obvious from the right-hand side (var orders = new ArrayList<Order>()). Avoid it when it hides important types (var result = service.process()), and beware of inferring concrete types: var list = new ArrayList<>() becomes ArrayList<Object>.

Q2. What are records, and how do they reduce boilerplate?

Short answer: A record (preview in 14 and 15, final in Java 16) is a transparent, shallowly immutable data carrier:

public record Money(BigDecimal amount, Currency currency) {
    public Money {                                             // compact constructor: validation and normalisation
        Objects.requireNonNull(amount); Objects.requireNonNull(currency);
        amount = amount.setScale(currency.getDefaultFractionDigits(), RoundingMode.HALF_EVEN);
    }
    public Money plus(Money other) { requireSameCurrency(other); return new Money(amount.add(other.amount), currency); }
    private void requireSameCurrency(Money o) { if (!currency.equals(o.currency)) throw new IllegalArgumentException(); }
}

The compiler generates:

• private final fields;
• a canonical constructor;
• accessors (amount(), not getAmount());
• equals/hashCode/toString over all the components.

Records are final, can't extend classes, and can't declare instance fields beyond their components. They can implement interfaces, and have static members, methods and nested types. They're ideal for DTOs, value objects, events, map keys, and multiple return values, and they support record patterns for deconstruction (Java 21).

Common trap: "records are deeply immutable". A List component can still be mutated, so copy it in the compact constructor (List.copyOf). Also, JPA entities can't be records.

Learn it in depth → Records

Q3. How do sealed, non-sealed and permits work together (Java 17)? When should you use sealed classes?

Short answer: A sealed class or interface restricts which types may extend or implement it, through permits. The permitted subclasses must be in the same module (or the same package in the unnamed module), and each must declare one of:

• final: the hierarchy stops there;
• sealed: it continues, but again restricted, with its own permits;
• non-sealed: it re-opens that branch to arbitrary extension.

Records and enums are implicitly final, so they're natural leaves.

public sealed interface Payment permits CardPayment, UpiPayment, WalletPayment {}
public record CardPayment(String token, int last4) implements Payment {}
public record UpiPayment(String vpa) implements Payment {}
public non-sealed class WalletPayment implements Payment {}      // partners may subclass wallet types

When to use them:

• closed domain alternatives (payment types, command and result types, AST nodes, state machines);
• where you want the compiler to check exhaustiveness in switch;
• to prevent unknown implementations of security-sensitive abstractions;
• for library APIs that must stay closed.

They were final in Java 17 (preview in 15 and 16).

Learn it in depth → Sealed Classes

Q4. What pattern-matching features does Java have?

Short answer:

• instanceof patterns (Java 16): if (obj instanceof Order o && o.isPaid()) {...}. They test, cast and bind in one step, with flow scoping.
• Pattern matching for switch (Java 21): switch over any type, with type patterns, guards (case Order o when o.total() > 1000 ->), case null, and exhaustiveness checking for sealed hierarchies and enums.
• Record patterns (Java 21): deconstruct records, including nested ones: case Circle(Point(var x, var y), double r) -> ....
• Unnamed variables and patterns _ (Java 22): case Point(var x, _) ->, and catch (Exception _).
• Primitive types in patterns are in preview in recent releases.

static String describe(Shape s) {
    return switch (s) {
        case Circle(var c, var r) when r > 100 -> "large circle at " + c;
        case Circle c    -> "circle r=" + c.radius();
        case Rectangle(var w, var h) -> "rectangle " + w + "x" + h;
        case Square sq   -> "square " + sq.side();
    };                                                    // exhaustive over the sealed Shape: no default
}

Learn it in depth → Pattern Matching

Q5. What are switch expressions (Java 14), and how do they differ from switch statements?

Short answer: A switch expression yields a value, and uses arrow labels:

• no fall-through, so no forgotten breaks;
• multiple labels per case (case SAT, SUN ->);
• yield to return a value from a block;
• exhaustiveness is required: the compiler forces default unless every enum constant or sealed subtype is covered.

The classic statement form falls through, doesn't produce a value, and isn't checked for exhaustiveness.

int workingHours = switch (day) {
    case SATURDAY, SUNDAY -> 0;
    case FRIDAY -> 6;
    default -> {
        log.debug("regular day {}", day);
        yield 8;
    }
};

Q6. What are text blocks (Java 15), and how are they useful?

Short answer: Multi-line string literals, delimited by """. Incidental indentation is stripped automatically (based on the closing delimiter's position), and newlines are normalised to \n. The escapes are \ (join lines) and \s (keep trailing spaces). They make embedded JSON, SQL, HTML, YAML and test fixtures readable, with no concatenation or escaped quotes. Combine them with formatted(...) for values, and never to build SQL from user input (use bind parameters).

String query = """
        SELECT o.id, o.total
        FROM orders o
        WHERE o.status = :status
          AND o.created_at > :since
        ORDER BY o.created_at DESC
        """;

Q7. What are virtual threads (Project Loom), and what's the architecture behind them?

Short answer: Virtual threads (final in Java 21, JEP 444) are lightweight Thread instances managed by the JVM, not by the OS.

• The architecture: a virtual thread is a continuation (its stack frames) plus a scheduler.
  • It mounts onto a carrier thread (a platform thread from a dedicated ForkJoinPool, with parallelism equal to the core count by default) to run.
  • When it blocks (socket I/O, sleep, BlockingQueue.take, locks), the JDK unmounts it: its stack frames are copied to the heap, the carrier is freed for another virtual thread, and the blocking operation is implemented with non-blocking I/O and park/unpark underneath.
  • When the operation completes, the virtual thread is rescheduled, and mounted again, possibly on a different carrier.
• The cost: creation is about as cheap as an object, and stacks grow and shrink on the heap. Millions of them are practical.
• The APIs: Thread.ofVirtual().start(r), Thread.startVirtualThread(r), and Executors.newVirtualThreadPerTaskExecutor(). In Spring Boot 3.2+, spring.threads.virtual.enabled=true.

Learn it in depth → Virtual Threads

Q8. How do virtual threads improve scalability? How do they affect blocking I/O?

Short answer: In thread-per-request servers, throughput is limited by the number of threads (Little's law: concurrency = throughput × latency). Platform threads are expensive (MBs of stack, OS scheduling), so pools of 200–500 cap throughput when requests spend most of their time waiting on I/O. Virtual threads make waiting cheap: a blocked virtual thread holds no OS thread, so you can have one virtual thread per request or task, with tens of thousands in flight.

The effect on blocking I/O: you keep simple, blocking, imperative code (JDBC, HttpClient, RestClient), and get near-reactive scalability, with readable stack traces and normal debugging and profiling.

Key points to cover:

• They don't make CPU-bound code faster. Throughput gains appear only when I/O waiting dominates.
• The downstream limits still apply: database connection pools are now your bottleneck. Limit concurrency with semaphores, not thread pools.

Q9. How do virtual threads compare with platform threads?

Short answer:

ThreadLocals work on virtual threads, but are costly with millions of threads. Prefer ScopedValue (final in Java 25).

Q10. What are pinned virtual threads?

Short answer: A virtual thread is pinned when it can't unmount from its carrier while blocking, so the carrier thread is blocked too, which reduces scalability, and can even deadlock with few carriers. The causes:

• In Java 21–23: blocking while holding a synchronized monitor, or inside Object.wait(). That was the big one.
• Native frames on the stack: a JNI call, or a callback from native code, into Java that blocks. This remains a cause.
• Class initialisation (<clinit>) blocking, and some file I/O operations (which are compensated by temporarily adding carriers).

Java 24 (JEP 491) reimplemented monitors, so synchronized no longer pins.

Detection: the JFR event jdk.VirtualThreadPinned (enabled by default, with a threshold). The older -Djdk.tracePinnedThreads was removed in 24.

Mitigation on 21–23: replace synchronized around blocking I/O with ReentrantLock, and upgrade libraries (JDBC drivers and connection pools updated for Loom).

Q11. What is structured concurrency, and what is StructuredTaskScope?

Short answer: Structured concurrency treats a group of concurrent subtasks as a single unit of work with a lexical scope, like a code block:

• subtasks are forked inside a scope;
• the parent waits for all of them before leaving the scope;
• failure or cancellation propagates: if one subtask fails, its siblings are cancelled (interrupted), and the error surfaces in the parent;
• there are no orphan threads, and thread dumps show the parent-child hierarchy.

Status: it's a preview API (JEP 505, fifth preview in Java 25, with a redesigned API: StructuredTaskScope.open(Joiner), fork, join). It's designed for virtual threads, and inherits scoped values automatically.

// Java 25 preview API (--enable-preview)
Response handle(long userId) throws InterruptedException {
    try (var scope = StructuredTaskScope.open()) {                  // default: fail if any subtask fails
        Subtask<User> user = scope.fork(() -> userService.find(userId));
        Subtask<List<Order>> orders = scope.fork(() -> orderService.recent(userId));
        scope.join();                                                // waits; the siblings are cancelled on failure
        return new Response(user.get(), orders.get());
    }
}

Compared with ad-hoc CompletableFuture fan-out, you get automatic cancellation, no leaked tasks, clearer error handling, and better observability.

Q12. What is the Vector API?

Short answer: jdk.incubator.vector expresses SIMD computations explicitly: FloatVector, IntVector, "species" matching the CPU's vector width, lane-wise operations, masks and reductions. The JIT compiles these to the platform's vector instructions (AVX2/AVX-512, NEON/SVE), with predictable performance, instead of relying on C2 auto-vectorising simple loops. It's used for numerical kernels, ML inference, image processing, and search or scoring. It's still incubating (10th incubator in Java 25), waiting on Project Valhalla value classes before finalisation. Enable it with --add-modules jdk.incubator.vector.

static final VectorSpecies<Float> S = FloatVector.SPECIES_PREFERRED;
static void scale(float[] a, float factor, float[] out) {
    int i = 0;
    for (; i < S.loopBound(a.length); i += S.length())
        FloatVector.fromArray(S, a, i).mul(factor).intoArray(out, i);
    for (; i < a.length; i++) out[i] = a[i] * factor;                // tail
}

Q13. What is the Foreign Function & Memory (FFM) API?

Short answer: Project Panama's replacement for JNI and Unsafe memory access, final in Java 22 (JEP 454):

• Memory: Arena (it controls lifetime: confined, shared or auto), MemorySegment (bounds-checked, off-heap or on-heap memory, with deterministic deallocation when the arena closes) and MemoryLayout (describes C structs).
• Functions: Linker creates downcall handles (MethodHandles calling native functions) and upcall stubs (native code calling back into Java). jextract generates Java bindings from C headers.

The benefits over JNI: no C glue code, safety (bounds and lifetime checks), performance comparable or better, and 64-bit memory offsets. It's used for native libraries (crypto, ML runtimes, databases), large off-heap data, and memory-mapped files with explicit unmapping. Native access needs --enable-native-access to avoid warnings.

Linker linker = Linker.nativeLinker();
MethodHandle strlen = linker.downcallHandle(
        linker.defaultLookup().find("strlen").orElseThrow(),
        FunctionDescriptor.of(ValueLayout.JAVA_LONG, ValueLayout.ADDRESS));
try (Arena arena = Arena.ofConfined()) {
    MemorySegment cString = arena.allocateFrom("Hello Panama");
    long len = (long) strlen.invokeExact(cString);             // 12; the memory is freed when the arena closes
}

Q14. How do you profile a JVM in production?

Short answer: Use low-overhead, always-available tooling:

• Continuous JFR (-XX:StartFlightRecording=...,settings=profile, about 1–2% overhead): dump on demand (jcmd <pid> JFR.dump) or on incidents, and analyse in JMC. It covers CPU samples, allocation, locks, GC, I/O and exceptions.
• async-profiler (attach temporarily, or as an agent): CPU, wall-clock, allocation and lock flame graphs, with no safepoint bias.
• Continuous profiling platforms (Pyroscope/Grafana, Datadog, Elastic) that sample the whole fleet continuously.
• Metrics: Micrometer JVM metrics (GC, memory pools, threads), plus tracing to find which requests are slow, before profiling why.
• Safe practice: profile a canary or a single instance, avoid heavy instrumentation profilers in production, restrict attach access, and correlate with deployments and load.

Q15. How would you tune a JVM (and the system) for a million users?

Short answer: A million users is a system problem first. The JVM is one part of it.

1. Estimate the load: peak requests per second, concurrency (Little's law), payload sizes, and the read/write mix.
2. Scale out stateless instances behind load balancers, and autoscale. The JVM settings must fit the container sizes.
3. The JVM per instance:
   • -Xms=-Xmx sized to the live set with headroom, or MaxRAMPercentage about 70–75;
   • G1 (the default), or generational ZGC for strict latency SLOs;
   • ExitOnOutOfMemoryError and heap dumps;
   • continuous JFR;
   • a CDS or AOT cache for fast startup during scale-outs;
   • virtual threads for I/O concurrency;
   • enough CPU (avoid 1-CPU pods, which fall back to Serial GC and throttling).
4. Reduce the work: caching (CDN, Redis, local), efficient serialisation, compression, pagination, asynchronous processing through queues.
5. Protect the dependencies: connection pools sized to the database's capacity, read replicas, sharding, bulkheads, rate limits, circuit breakers.
6. Validate: load tests at 2–3× the peak, soak tests for leaks, and chaos tests. Then iterate using p99 latency, error rates and saturation metrics.

Q16. How does Java compare with Go for backend systems?

Short answer:

• Java's strengths:
  • a mature ecosystem (Spring, Hibernate, Kafka clients, observability);
  • peak throughput with JIT optimisation;
  • world-class GC options;
  • tooling (JFR, profilers, IDEs);
  • a strong type system and modern language features;
  • virtual threads now match Go's goroutine-style concurrency for I/O.
• Go's strengths:
  • fast startup and small memory footprint (static binaries);
  • simple deployment;
  • a small language and fast compiles;
  • built-in goroutines and channels;
  • great for infrastructure tooling, CLIs, proxies and cloud-native components (Kubernetes, Docker, Prometheus are written in Go).
• Java's gaps are closing: GraalVM native images and CRaC/AOT caches (startup and footprint), and jlink (small runtimes).
• Choose by context: the team's skills, the existing ecosystem, the latency and footprint needs (serverless and edge favour Go or native Java), and integration requirements. Many organisations run both: Java for business services, Go for platform tooling.

Follow-up questions this topic invites — and their answers

Q: Which features are final in Java 21 (the LTS)? A: Virtual threads, record patterns, pattern matching for switch, sequenced collections, generational ZGC (as an option), and the key encapsulation mechanism API. String templates, structured concurrency and scoped values were previews in 21. Scoped values became final in Java 25, and string templates were withdrawn.

Q: Should you pool virtual threads, or limit them with a fixed-size pool? A: Never pool them: create one per task. To limit concurrency to a resource (say, 50 database calls), use a Semaphore, or the resource's own pool. Thread-pool sizing was only ever an indirect way of limiting concurrency.

Q: Do virtual threads work with ThreadLocal and synchronized code? A: Yes, they work. ThreadLocals cost memory per virtual thread (prefer ScopedValue). synchronized pinned carriers in Java 21–23, and doesn't since Java 24.

Q: What Java 25 LTS features are worth mentioning? A: Scoped values (final), flexible constructor bodies, compact source files and instance main methods, module import declarations, compact object headers (a product option), AOT method profiling and command-line ergonomics (Project Leyden), generational Shenandoah, and JFR CPU-time profiling.