{"id":683,"date":"2026-06-09T00:35:16","date_gmt":"2026-06-08T23:35:16","guid":{"rendered":"https:\/\/www.xn--javaeinfacherklrt-4qb.de\/?p=683"},"modified":"2026-06-17T00:35:54","modified_gmt":"2026-06-16T23:35:54","slug":"eclipse-vert-x-reaktive-nicht-blockierende-anwendungen-in-java","status":"publish","type":"post","link":"https:\/\/www.xn--javaeinfacherklrt-4qb.de\/?p=683","title":{"rendered":"Eclipse Vert.x \u2014 Reaktive, nicht-blockierende Anwendungen in Java"},"content":{"rendered":"\n

W\u00e4hrend Frameworks wie Spring Boot auf einem Thread-pro-Request-Modell basieren \u2014 jeder HTTP-Request blockiert einen Thread \u2014 setzt Eclipse Vert.x<\/strong> von Grund auf auf asynchrone, nicht-blockierende Verarbeitung. Das Ergebnis: eine einzige JVM-Instanz kann zehntausende parallele Verbindungen handhaben, ohne dass der Thread-Pool kollabiert.<\/p>\n\n\n\n

Das Event-Loop-Modell<\/h2>\n\n\n\n

Vert.x basiert auf dem Reactor-Pattern<\/strong>: Ein oder mehrere Event-Loop-Threads verarbeiten eingehende Ereignisse (HTTP-Requests, Timer, Nachrichten) in einer Endlosschleife. Blockierende Operationen sind tabu \u2014 sie w\u00fcrden den gesamten Event-Loop lahmlegen.<\/p>\n\n\n

Event Loop (Thread 1) --> Handler 1 --> Handler 2 --> DB (non-blocking) --> Resume\nEvent Loop (Thread 2) --> Handler 3 --> HTTP-Call (non-blocking) --> Resume\nEvent Loop (Thread N) --> Handler 4 --> Handler 5 --> Handler 6 --> Done\n<\/code><\/span><\/pre>\n\n\n
Grundbaustein: Das Verticle<\/h2>\n\n\n\n
Die Grundeinheit in Vert.x ist das Verticle<\/strong> \u2014 eine leichtgewichtige Komponente, die vom Event-Loop ausgef\u00fchrt wird:<\/p>\n\n\n
import<\/span> io.vertx.core.VerticleBase;\nimport<\/span> io.vertx.core.Future;\nimport<\/span> io.vertx.ext.web.Router;\n\npublic class<\/span> HttpServerVerticle<\/span> extends<\/span> VerticleBase<\/span> <\/span>{\n\n    @Override\n    public Future<?> start() {\n        Router router = Router.router(vertx);\n\n        router.get(\"\/hello\"<\/span>).handler(ctx -> {\n            ctx.response()\n                .putHeader(\"content-type\"<\/span>, \"text\/plain\"<\/span>)\n                .end(\"Hallo von Vert.x 5!\"<\/span>);\n        });\n\n        return<\/span> vertx.createHttpServer()\n            .requestHandler(router)\n            .listen(8080<\/span>)\n            .onSuccess(server ->\n                System.out.println(\"Server l\u00e4uft auf Port \"<\/span> + server.actualPort())\n            );\n    }\n}\n<\/code><\/span>Code-Sprache:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
Alle Handler-Callbacks werden vom Event-Loop ausgef\u00fchrt \u2014 niemals blockieren!<\/p>\n\n\n\n
Der Event Bus<\/h2>\n\n\n\n
Kommunikation zwischen Verticles erfolgt \u00fcber den Event Bus<\/strong>, eine verteilte, lose gekoppelte Nachrichten-Infrastruktur:<\/p>\n\n\n
<em>\/\/ Consumer-Verticle<\/em><\/span>\npublic<\/span> class<\/span> OrderVerticle<\/span> extends<\/span> VerticleBase<\/span> <\/span>{\n    @Override\n    public<\/span> Future<?<\/span>> start() {\n        vertx.eventBus().consumer(\"bestellung.neu\"<\/span>, message -> {\n            String payload = (String) message.body();\n            System.out.println(\"Neue Bestellung: \"<\/span> + payload);\n            message.reply(\"Bestellung verarbeitet\"<\/span>);\n        });\n        return<\/span> Future.succeededFuture();\n    }\n}\n\n<em>\/\/ Producer-Verticle<\/em><\/span>\npublic<\/span> class<\/span> ProducerVerticle<\/span> extends<\/span> VerticleBase<\/span> <\/span>{\n    @Override\n    public<\/span> Future<?<\/span>> start() {\n        return<\/span> vertx.eventBus().request(\"bestellung.neu\"<\/span>, \"B-1234\"<\/span>)\n            .onSuccess(reply -> System.out.println(\"Antwort: \"<\/span> + reply.body()))\n            .onFailure(err -> System.err.println(\"Fehler: \"<\/span> + err.getMessage()));\n    }\n}\n<\/code><\/span>Code-Sprache:<\/span> PHP<\/span> (<\/span>php<\/span>)<\/span><\/small><\/pre>\n\n\n
Der Event Bus unterst\u00fctzt Publish\/Subscribe, Request\/Response und kann \u2014 mit Clustering \u2014 sogar JVM-\u00fcbergreifend kommunizieren.<\/p>\n\n\n\n
Nicht-blockierender Datenbankzugriff<\/h2>\n\n\n\n
Blockierende JDBC-Aufrufe sind im Event-Loop t\u00f6dlich. Vert.x bietet mit dem SQL Client<\/strong> eine vollst\u00e4ndig asynchrone Alternative:<\/p>\n\n\n
import<\/span> io.vertx.jdbcclient.JDBCPool;\nimport<\/span> io.vertx.jdbcclient.JDBCConnectOptions;\nimport<\/span> io.vertx.sqlclient.Pool;\nimport<\/span> io.vertx.sqlclient.PoolOptions;\n\n<em<\/span>><\/span>\/\/ Pool anlegen<\/em<\/span>><\/span><\/span>\nJDBCConnectOptions connectOptions = new<\/span> JDBCConnectOptions()\n    .setJdbcUrl(\"jdbc:postgresql:\/\/localhost:5432\/shop\"<\/span>);\nPoolOptions poolOptions = new<\/span> PoolOptions()\n    .setMaxSize(16<\/span>);\nPool pool = JDBCPool.pool(vertx, connectOptions, poolOptions);\n\n<em<\/span>><\/span>\/\/ Asynchrone Query<\/em<\/span>><\/span><\/span>\npool.query(\"SELECT * FROM produkte WHERE preis > 19.99\"<\/span>)\n    .execute()\n    .onSuccess(rows -> {\n        for<\/span> (var<\/span> row : rows) {\n            System.out.println(row.getString(\"name\"<\/span>));\n        }\n    })\n    .onFailure(err -> {\n        System.err.println(\"Fehler: \"<\/span> + err.getMessage());\n    });\n<\/code><\/span>Code-Sprache:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
F\u00fcr PostgreSQL steht zudem der PgClient<\/strong> bereit \u2014 ein nativer, reaktiver Client, der ohne JDBC-Layer direkt \u00fcber das PostgreSQL-Wire-Protokoll kommuniziert und seit Vert.x 5 \u00fcber den PgBuilder<\/code> konfiguriert wird.<\/p>\n\n\n\n
Reaktive Alternativen: Mutiny und Virtual Threads<\/h2>\n\n\n\n
Neben RxJava unterst\u00fctzt Vert.x 5 auch SmallRye Mutiny<\/strong> \u2014 eine eigenst\u00e4ndige reaktive Programmierbibliothek, die als moderne Alternative zu RxJava positioniert ist. Mutiny bietet zwei Programmiermodelle: eine ereignisgesteuerte API (Multi<\/code>\/Uni<\/code>) und eine imperative, Coroutine-\u00e4hnliche Variante.<\/p>\n\n\n\n
F\u00fcr Entwickler, die blockierende APIs anbinden m\u00fcssen, bietet Vert.x seit dem Virtual-Threads-Incubator<\/strong> eine elegante L\u00f6sung: Blockierende Aufrufe k\u00f6nnen in virtuellen Threads ausgef\u00fchrt werden, ohne den Event-Loop zu blockieren. Seit Java 21 sind Virtual Threads fester Bestandteil der Plattform:<\/p>\n\n\n
vertx.executeBlocking(() -> {\n    <em<\/span>><\/span>\/\/ L\u00e4uft in einem virtuellen Thread \u2014 blockierende Aufrufe sind hier sicher<\/em<\/span>><\/span>\n    return legacyBlockingService.fetchData();\n}).onSuccess(result -> {\n    <em<\/span>><\/span>\/\/ Zur\u00fcck im Event-Loop<\/em<\/span>><\/span>\n    System.out.println(\"Ergebnis: \" + result);\n});\n<\/code><\/span>Code-Sprache:<\/span> HTML, XML<\/span> (<\/span>xml<\/span>)<\/span><\/small><\/pre>\n\n\n
Reaktive Streams mit RxJava<\/h2>\n\n\n\n
Vert.x l\u00e4sst sich direkt mit RxJava<\/strong> kombinieren (Pull-Abh\u00e4ngigkeit vertx-rx-java3<\/code>):<\/p>\n\n\n
import<\/span> io.vertx.rxjava3.core.AbstractVerticle;\nimport<\/span> io.vertx.rxjava3.ext.web.Router;\n\npublic class<\/span> RxVerticle<\/span> extends<\/span> AbstractVerticle<\/span> <\/span>{\n    @Override\n    public void<\/span> start() {\n        Router router = Router.router(vertx);\n\n        router.get(\"\/users\/:id\"<\/span>).handler(ctx -> {\n            String<\/span> id = ctx.pathParam(\"id\"<\/span>);\n\n            dbClient.preparedQuery(\"SELECT * FROM users WHERE id = $1\"<\/span>)\n                .rxExecute(Tuple.of(Integer.parseInt(id)))\n                .map(rows -> rows.iterator().next())\n                .subscribe(\n                    row -> ctx.response().end(row.toJson().encode()),\n                    err -> ctx.fail(500<\/span>, err)\n                );\n        });\n    }\n}\n<\/code><\/span>Code-Sprache:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
.rxExecute()<\/code> wandelt das Future-basierte Vert.x-API in eine RxJava-Single um \u2014 f\u00fcr flie\u00dfende reaktive Pipelines.<\/p>\n\n\n\n
Wann Vert.x?<\/h2>\n\n\n\n
Vert.x ist besonders interessant f\u00fcr:<\/p>\n\n\n\n
    \n
  • Hochskalierende Echtzeit-Anwendungen (Chat, Gaming, B\u00f6rsenticker)<\/li>\n\n\n\n
  • API-Gateways und Proxies mit minimalem Overhead<\/li>\n\n\n\n
  • Teams, die ein reaktives Modell mit leichtgewichtigem Toolkit einem Full-Stack-Framework vorziehen<\/li>\n\n\n\n
  • Polyglotte Projekte (Vert.x unterst\u00fctzt Java, Kotlin, Groovy und JavaScript)<\/li>\n\n\n\n
  • Microservices mit nativer Unterst\u00fctzung f\u00fcr OpenTelemetry, Health Checks und Circuit Breaker<\/li>\n<\/ul>\n\n\n\n
    Fazit<\/h2>\n\n\n\n
    Vert.x ist kein Framework, sondern ein Toolkit: leichtgewichtig, unaufdringlich und extrem performant. Es zwingt Entwickler, in Ereignissen zu denken \u2014 blockierende Aufrufe sind strukturell unm\u00f6glich. Wer bereit ist, das Future-basierte Programmiermodell (oder RxJava) zu akzeptieren, wird mit einer Skalierbarkeit belohnt, die traditionelle Servlet-basierte Frameworks nicht erreichen. Mit der aktuellen Version 5.1.2 ist Vert.x erwachsen geworden \u2014 stabil, gut dokumentiert und produktionserprobt.<\/p>\n","protected":false},"excerpt":{"rendered":"
    W\u00e4hrend Frameworks wie Spring Boot auf einem Thread-pro-Request-Modell basieren \u2014 jeder HTTP-Request blockiert einen Thread \u2014 setzt Eclipse Vert.x von Grund auf auf asynchrone, nicht-blockierende Verarbeitung. Das Ergebnis: eine einzige JVM-Instanz kann zehntausende parallele Verbindungen handhaben, ohne dass der Thread-Pool kollabiert. Das Event-Loop-Modell Vert.x basiert auf dem Reactor-Pattern: Ein oder mehrere Event-Loop-Threads verarbeiten eingehende Ereignisse (HTTP-Requests, Timer, Nachrichten) […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[4],"tags":[],"class_list":["post-683","post","type-post","status-publish","format-standard","hentry","category-plain_java"],"_links":{"self":[{"href":"https:\/\/www.xn--javaeinfacherklrt-4qb.de\/index.php?rest_route=\/wp\/v2\/posts\/683","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.xn--javaeinfacherklrt-4qb.de\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.xn--javaeinfacherklrt-4qb.de\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.xn--javaeinfacherklrt-4qb.de\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.xn--javaeinfacherklrt-4qb.de\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=683"}],"version-history":[{"count":1,"href":"https:\/\/www.xn--javaeinfacherklrt-4qb.de\/index.php?rest_route=\/wp\/v2\/posts\/683\/revisions"}],"predecessor-version":[{"id":684,"href":"https:\/\/www.xn--javaeinfacherklrt-4qb.de\/index.php?rest_route=\/wp\/v2\/posts\/683\/revisions\/684"}],"wp:attachment":[{"href":"https:\/\/www.xn--javaeinfacherklrt-4qb.de\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=683"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.xn--javaeinfacherklrt-4qb.de\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=683"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.xn--javaeinfacherklrt-4qb.de\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=683"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}