Java 21 Features Interview Questions and Answers

Why Java 21 features dominate current interviews

Java 21 is the newest widely-adopted LTS release, and its virtual threads are the biggest change to Java concurrency in a decade — so interviewers ask about it to see whether you are current and whether you grasp why it matters. The features here are not cosmetic: virtual threads change how you write servers, and pattern matching for switch changes how you process data. Strong answers explain the shift in thinking, not just the syntax.

This page covers the Java 21 features that come up most. For the prior LTS and the pattern-matching groundwork, pair it with the Java 17 features questions; for the concurrency model virtual threads build on, see the concurrency set.

Q1. Why is Java 21 significant?

Java 21 is a Long-Term-Support release, the successor baseline to Java 17. Its landmark feature is virtual threads, which make blocking-style code scale to enormous concurrency; it also finalized record patterns, pattern matching for switch, and sequenced collections, and continued maturing the pattern-matching direction of the language.

The context to give: after Java 17, the language kept previewing pattern matching and Project Loom's virtual threads, and Java 21 is where virtual threads, record patterns and pattern matching for switch all became final. Framing it as "the LTS that made Loom real" gives the interviewer the headline.

Q2. What are virtual threads and what problem do they solve?

Virtual threads are lightweight threads scheduled by the JVM onto a small pool of OS "carrier" threads. Because they are cheap — you can have millions — you can write simple blocking code (one request per thread) and still scale, instead of resorting to reactive/async callbacks to avoid exhausting OS threads.

// Each task gets its own virtual thread; blocking I/O no longer wastes an OS thread
try (var executor = Executors.newVirtualThreadPerTaskExecutor()) {
    for (int i = 0; i < 100_000; i++) {
        executor.submit(() -> {
            String body = fetch("https://example.com");  // blocks cheaply
            return body.length();
        });
    }
}   // try-with-resources waits for all tasks

The key mechanism to explain: when a virtual thread hits blocking I/O, the JVM unmounts it from its carrier thread so that carrier can run other virtual threads — the OS thread is never blocked idly. The practical takeaway: platform (OS) threads are the scarce resource virtual threads stop wasting; you no longer size a thread pool around I/O.

Q3. When would virtual threads not help?

They help I/O-bound, high-concurrency workloads. They do not speed up CPU-bound work — you still only have so many cores — and they should not be pooled, because the whole point is that creating one is nearly free. Long-running CPU tasks or code that holds a native lock (pinning the carrier) still need care.

The senior detail: a virtual thread can be "pinned" to its carrier if it blocks inside a synchronized block or a native call, preventing unmounting; the recommended fix is to prefer ReentrantLock over synchronized on hot blocking paths. Knowing the pinning caveat is what separates a real answer from a headline recital.

Q4. What are record patterns?

Record patterns let you deconstruct a record in a pattern, binding its components to variables directly. Instead of matching a type and then calling accessors, you name the pieces inline — and patterns nest, so you can destructure records inside records in one match.

record Point(int x, int y) {}
record Line(Point start, Point end) {}

String describe(Object obj) {
    return switch (obj) {
        case Point(int x, int y) -> "point at " + x + "," + y;
        case Line(Point(var x1, var y1), Point(var x2, var y2)) ->
                "line " + x1 + "," + y1 + " -> " + x2 + "," + y2;   // nested
        default -> "unknown";
    };
}

The interviewer is checking whether you see that record patterns + pattern matching for switch turn data processing into something declarative — you describe the shape you want and get the fields, without casts or accessor chains.

Q5. Explain pattern matching for switch, including guards.

A switch can branch on the runtime type of a value, bind it, deconstruct records, and apply a guard with when. Combined with sealed types, the compiler checks exhaustiveness, so every case is covered without a default. null can be handled explicitly with a case null label.

String classify(Object o) {
    return switch (o) {
        case null            -> "null";
        case Integer i when i > 0 -> "positive int";
        case Integer i       -> "non-positive int";
        case String s        -> "string of length " + s.length();
        default              -> "other";
    };
}

Two details that impress: guarded patterns (when) let two branches share a type but differ on a condition, and order matters — a more specific guarded case must precede the unguarded one, or it is unreachable and will not compile.

Q6. What are sequenced collections?

Java 21 introduced SequencedCollection, SequencedSet and SequencedMap, giving ordered collections a uniform API: getFirst(), getLast(), addFirst(), addLast(), and reversed(). Before this, accessing the first and last element was inconsistent across List, Deque and LinkedHashSet.

List<String> names = new ArrayList<>(List.of("a", "b", "c"));
names.getFirst();      // "a"  — uniform, replaces get(0)
names.getLast();       // "c"  — replaces get(size() - 1)
List<String> back = names.reversed();  // reverse-ordered view

The value is consistency: LinkedHashSet finally has a clean way to get its last element, and reversed() provides a view without copying. It is a small quality-of-life addition, but naming the three interfaces shows you actually looked at the release.

Q7. How do virtual threads compare to reactive programming?

Both target high-concurrency I/O, but virtual threads let you keep simple, sequential, blocking code and debuggable stack traces, while reactive frameworks require restructuring logic into non-blocking callback or stream pipelines. Virtual threads give much of reactive's scalability with a fraction of the cognitive and debugging cost.

The nuanced answer acknowledges reactive still has a place for back-pressure-heavy streaming, but that for typical request-per-task servers, virtual threads make the async complexity unnecessary. Interviewers ask this to see whether you understand the motivation behind Loom, which is exactly this trade-off.

Q8. How would you adopt Java 21 features in an existing codebase?

Incrementally: switch executors to virtual-thread-per-task for I/O-bound request handling first, since blocking code stays as-is; then adopt record patterns and pattern matching for switch where you have type-dispatch chains or sealed hierarchies; and replace ad-hoc first/last access with sequenced-collection methods for clarity.

The judgement to show: virtual threads are near drop-in for thread-per-request servers but require auditing for synchronized blocks that cause pinning, and pattern matching pays off most where you already have instanceof cascades. "Adopt where it removes real complexity, not everywhere at once" is the answer that reads as experienced.

How to prepare

Run virtual threads yourself — spin up a hundred thousand tasks that sleep, and watch them finish without a thread pool; the "that actually worked" moment is what makes the concept stick. Then write a small sealed hierarchy and process it with record patterns and a guarded switch. Place Java 21 in the timeline after the Java 17 features, and connect virtual threads back to the fundamentals in the concurrency questions so you can explain what problem they replace. Rehearse the virtual-threads-versus-reactive trade-off out loud in a mock interview, since it is the follow-up interviewers reach for.