Moderne Java-Systeme mischen Ausführungsmodelle, weil keines der beiden Modelle jede Aufgabe am besten löst. Spring MVC und Spring WebFlux existieren als getrennte Stacks nebeneinander, und die Spring-Dokumentation nennt ausdrücklich einen Mischfall: MVC-Controller, die den reaktiven WebClient verwenden. Virtuelle Threads machen synchron geschriebenen Code für viele I/O-lastige Dienste wieder attraktiv. Reaktive Verarbeitung bleibt dort stark, wo nicht-blockierendes I/O, Streaming und explizite Backpressure zentral sind. Dieser Artikel zeigt, wo die Grenzen verlaufen und woran Sie die Entscheidung festmachen.
Was “reaktiv” und “synchron” hier meinen
Synchroner, imperativer Code bildet den Kontrollfluss direkt ab: Ein Aufruf liefert einen Wert oder wirft eine Exception. Bei blockierendem I/O wartet der ausführende Thread. Das Modell ist breit verständlich und passt zu vielen Bibliotheken und Datenzugriffsschichten. Auf klassischen Plattform-Threads wird Thread-pro-Anfrage allerdings teuer, wenn sehr viele Anfragen gleichzeitig warten.
As an Amazon Associate I earn from qualifying purchases.
Reaktiv bedeutet mehr als “asynchron gestartet”. Project Reactor baut auf Reactive Streams, nicht-blockierendem asynchronem Arbeiten und Backpressure auf. Seine zentralen Typen sind Flux (0 bis N Elemente) und Mono (0 oder 1 Element). Datenflüsse werden als Publisher und Operator-Ketten beschrieben, und Backpressure regelt die Nachfrage zwischen Komponenten.
Was virtuelle Threads leisten und was nicht
Virtuelle Threads sind eine leichte Implementierung von java.lang.Thread. Sie erlauben synchronen, imperativen Code mit blockierenden I/O-APIs, während ein wartender virtueller Thread nicht dauerhaft einen Betriebssystem-Thread belegt. Oracle (Java SE 26, Virtual Threads) formuliert den Nutzen präzise:
“Virtual threads can significantly improve the throughput—not the latency—of servers written in the thread-per-request style.”
Die Einschränkung gehört zur Aussage: Es geht um Durchsatz bei Servern im Thread-per-Request-Stil. Daraus folgt nicht, dass virtuelle Threads die Antwortzeit einer einzelnen Anfrage senken. Sie sind auch keine Reactive-Streams-Bibliothek und liefern daher keine Backpressure und keine Operatoren für Streams. Oracle hebt zudem hervor, dass bestehende Thread-Konzepte weitgehend anwendbar bleiben. Das erleichtert Schreiben, Lesen und Debuggen.
Rank #2
Warum die Modelle auf Systemebene koexistieren
Spring bietet zwei Stacks, die kombinierbar sind
Spring MVC basiert auf der Servlet-Welt, WebFlux ist Spring Webs reaktiver Stack. Beide sind getrennte, optionale Module. Laut Spring-Dokumentation können sie in einzelnen Anwendungen nebeneinander auftreten. Das dokumentierte Beispiel ist ein MVC-Controller, der einen reaktiven WebClient für Aufrufe an andere Dienste nutzt. Imperative Geschäftslogik und eine reaktive Integrationsgrenze lassen sich so in einem Dienst vereinen.
The Tool Desk
Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Ein reaktiver Typ ist kein eigener Thread
Reactor ist nebenläufigkeitsagnostisch. Ein Flux oder Mono bekommt nicht allein deshalb einen eigenen Thread. Den Ausführungskontext steuern publishOn und subscribeOn. Wer Reactor einsetzt, muss also Scheduler und Operatoren verstehen, um zu wissen, wo Code tatsächlich läuft. (Die Scheduler-Dokumentation ist versionsabhängig; prüfen Sie Details gegen Ihre Reactor-Version.)
Blockierende Aufrufe sind die kritische Naht
Blockierende Abhängigkeiten lassen sich in einem reaktiven Ablauf auf einen separaten Thread verlagern. Spring weist aber darauf hin, dass das den nicht-blockierenden WebFlux-Stack nicht voll ausschöpft. Ein blockierender JDBC-Treiber hinter einem WebFlux-Controller ersetzt keinen nicht-blockierenden Treiber. Mischbetrieb funktioniert am besten, wenn die Übergänge klar definiert sind und keine unbemerkten blockierenden Aufrufe auf Event-Loop-Pfaden landen.
Wann welcher Ansatz passt
| Kriterium | Synchron mit virtuellen Threads | Reaktiv mit WebFlux und Reactor |
|---|---|---|
| Programmiermodell | Imperativer Kontrollfluss, blockierende APIs bleiben möglich; viele parallel wartende Aufgaben werden billiger. | Asynchrone Publisher-Ketten mit Flux/Mono, Reactive Streams und Backpressure. |
| Bibliotheken | Passt, wenn Treiber und Frameworks synchron und blockierend sind. | Lohnt sich, wenn der gesamte Datenpfad nicht-blockierende Treiber und reaktive APIs nutzt. |
| Datenfluss | Anfrage-Antwort-Logik, die sich direkt ausdrücken lässt. | Streaming oder explizite Nachfragekontrolle. |
| Lesbarkeit im Team | Schrittweise lesbar, übliche Thread-Regeln gelten weiter. | Operatoren, Scheduler und Ausführungskontext müssen verstanden werden. |
| Leistungsziel | Höherer Durchsatz bei Thread-per-Request, laut Oracle nicht niedrigere Latenz. | Spring nennt hohe Parallelität bei weniger blockierten Threads als Ziel; eine allgemeingültige Vergleichszahl nennt die Dokumentation nicht. |
Die Tabelle ist eine Entscheidungshilfe, kein Benchmark. Die offiziellen Quellen von Oracle, Spring und Reactor nennen keine Messzahl, die ein Modell über alle Workloads hinweg zum Sieger erklärt. Auch Springs Aussage, reaktive Verarbeitung könne mehr gleichzeitige Nutzer mit weniger Microservice-Instanzen bedienen, ist eine allgemeine Herstellerbeschreibung und kein belegter Messwert für ein konkretes Szenario.
Rank #4
Eine praktische Entscheidungsreihenfolge
- Datenpfad prüfen: Gibt es für Datenbank, Messaging und externe Dienste durchgängig nicht-blockierende Treiber? Wenn nein, verliert WebFlux einen großen Teil seines Nutzens.
- Datenform klären: Handelt es sich um klassische Anfrage und Antwort oder um Streams, bei denen Konsumenten die Rate bestimmen müssen? Letzteres spricht für Reactor.
- Engpass benennen: Sind es wartende Threads bei hoher Parallelität (dann sind virtuelle Threads ein naheliegender Kandidat) oder fehlende Flusskontrolle?
- Team und Bestand einbeziehen: Bestehender, blockierender Code und die Lesbarkeit für das Team sind reale Kosten.
- Am eigenen Lastprofil messen: Vergleichen Sie Durchsatz, Tail-Latenz, Ressourcenverbrauch, Thread-Sättigung und das Verhalten unter Überlast, nicht nur Mittelwerte.
Typische Mischarchitekturen
- MVC-Dienst mit reaktivem
WebClient: Das von Spring dokumentierte Muster. Die Geschäftslogik bleibt imperativ, ausgehende Aufrufe nutzen den reaktiven Client. - Synchroner Dienst auf virtuellen Threads: Blockierende Bibliotheken bleiben, viele wartende Anfragen belegen weniger Betriebssystem-Threads.
- Reaktiver Streaming-Rand, synchroner Kern: Streams oder Gateways laufen reaktiv, daran angeschlossene Fachlogik bleibt gewöhnlicher Code. Planen Sie die Übergänge bewusst, damit blockierende Aufrufe nicht auf Event-Loop-Pfaden landen.
Stolperstellen
- “Reaktiv heißt automatisch mehrere Threads”: Falsch. Der Kontext hängt von
publishOn,subscribeOnund der Quelle ab. - “Virtuelle Threads ersetzen Backpressure”: Sie bieten keinen Reactive-Streams-Mechanismus. Ob Sie ihn brauchen, hängt vom Datenfluss ab.
- “Blockierenden Code einfach auslagern”: Möglich, aber es ersetzt keinen nicht-blockierenden Treiber.
- Pauschale Leistungsversprechen: Zahlen ohne Workload, Version und Messmethode sind keine Entscheidungsgrundlage.
Machen virtuelle Threads reaktive Programmierung überflüssig?
Nicht pauschal. Für viele klassische, I/O-lastige Request-Response-Dienste nehmen virtuelle Threads einen Teil des Drucks weg, der früher für reaktive Stacks sprach: viele gleichzeitig wartende Anfragen bei lesbarem Code. Sobald Streaming, Nachfragesteuerung oder ein durchgängig nicht-blockierender Datenpfad die Anforderung ist, bleibt Reactor das passendere Werkzeug. Die Frage “Wann WebFlux statt Spring MVC?” beantwortet deshalb der Ende-zu-Ende-Datenfluss, nicht ein Trend.
Do these 3 things before closing this tab:
1Repair Windows errors before they cause bigger problems2Fix the driver behind crashes, sound loss and screen glitches3Clear out junk files and repair common Windows errorsThe Bottom Line
Wählen Sie pro Dienst und pro Grenze, nicht pro Unternehmen: synchron mit virtuellen Threads, wo blockierende Bibliotheken und einfacher Kontrollfluss überwiegen, reaktiv, wo Streaming, Backpressure und nicht-blockierende Treiber den Datenpfad prägen. Belegen Sie die Entscheidung mit Messungen am eigenen Workload.
Quick Recap
Best Value
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
