Which is better for high-throughput I/O - platform or virtual threads, and why?

For workloads dominated by blocking I/O, such as a typical web service making blocking database or HTTP calls per request, virtual threads are the better fit in Java 21.

Platform threads map one-to-one to OS threads, which are expensive to create and hold significant memory for their stacks (often megabytes each), so a thread-per-request model on platform threads realistically caps out at a few thousand concurrent requests before the OS and JVM overhead of managing that many threads dominates. This is why traditional servers instead used a limited platform-thread pool combined with either asynchronous, callback-based, or reactive code to avoid tying up a scarce thread on every blocking call.

// blocking style, but scales like async, thanks to virtual threads
try (var executor = Executors.newVirtualThreadPerTaskExecutor()) {
    executor.submit(() -> {
        var result = blockingDbCall();   // carrier freed while this blocks
        respond(result);
    });
}

Virtual threads let you write the same simple, blocking-style, thread-per-request code, but because a blocked virtual thread unmounts from its carrier instead of tying it up, a small number of carrier platform threads can support hundreds of thousands of concurrently blocked virtual threads at once. The result is I/O-bound throughput that rivals async/reactive approaches, without giving up straightforward, debuggable, synchronous-looking code.

Platform threads still make sense for long-running, CPU-bound work, where there's no blocking to unmount from anyway and virtual threads offer no advantage, or when interacting with code that pins frequently, such as legacy synchronized-heavy libraries doing I/O.