{"id":34113,"date":"2023-06-14T10:40:00","date_gmt":"2023-06-14T08:40:00","guid":{"rendered":"https:\/\/www.happycoders.eu\/?p=34113"},"modified":"2025-09-09T14:09:26","modified_gmt":"2025-09-09T12:09:26","slug":"structured-concurrency-structuredtaskscope","status":"publish","type":"post","link":"https:\/\/www.happycoders.eu\/de\/java\/structured-concurrency-structuredtaskscope\/","title":{"rendered":"Structured Concurrency in Java mit StructuredTaskScope"},"content":{"rendered":"\n

Structured Concurrency<\/em> wurde \u2013 zusammen mit virtuellen Threads<\/a> und Scoped Values<\/a> \u2013 in Project Loom<\/a> entwickelt. Structured Concurrency<\/em> ist seit Java 19<\/a> als Incubator-Feature und seit Java 21<\/a> als Preview-Feature im JDK enthalten.<\/p>\n\n\n\n

<\/path><\/svg><\/div>
<\/div>

In Java 25<\/a> wird die StructuredTaskScope<\/code>-API durch JDK Enhancement Proposal 505<\/a> grundlegend \u00fcberarbeitet. Da Java 25 noch nicht released ist und du Structured Concurrency<\/em> evtl. mit einer \u00e4lteren Java-Version ausprobieren m\u00f6chtest, habe ich alle Code-Beispiele in zwei Varianten angegeben: f\u00fcr Java 21\u201324 und f\u00fcr Java 25.<\/p><\/div><\/div>\n\n\n\n

In diesem Artikel erf\u00e4hrst du:<\/p>\n\n\n\n

    \n
  • Warum ben\u00f6tigen wir Structured Concurrency?<\/li>\n\n\n\n
  • Was ist Structured Concurrency?<\/li>\n\n\n\n
  • Wie wird StructuredTaskScope<\/code> verwendet?<\/li>\n\n\n\n
  • Was ist eine Policy<\/em>? Welche Policies gibt es, und wie k\u00f6nnen wir selbst eine Policy schreiben?<\/li>\n\n\n\n
  • Was ist der Vorteil von Structured Concurrency?<\/li>\n<\/ul>\n\n\n\n

    Eine begleitende Demo-Anwendung (mit Java-21- als auch Java-25-Code) findest du in diesem GitHub-Repository<\/a>.<\/p>\n\n\n\n

    Schauen wir uns zuerst einmal an, wie wir nebenl\u00e4ufige Teilaufgaben bisher implementiert haben.<\/p>\n\n\n\n

    Warum ben\u00f6tigen wir Structured Concurrency?<\/h2>\n\n\n\n

    Wenn eine Aufgabe aus verschiedenen \u2013 vor allem blockierenden \u2013 Teilaufgaben besteht, die nebenl\u00e4ufig erledigt werden k\u00f6nnen (z. B. Zugriff auf Daten aus einer Datenbank oder Aufruf einer Remote API), so konnten wir hierf\u00fcr bisher das Java-Executor-Framework einsetzen.<\/p>\n\n\n\n

    Das k\u00f6nnte dann z. B. so aussehen (Klasse InvoiceGenerator3_ThreadPool<\/a> in der Demo-Anwendung):<\/p>\n\n\n

    Invoice createInvoice<\/span>(int<\/span> orderId, int<\/span> customerId, String language)<\/span>\n    throws<\/span> InterruptedException, ExecutionException <\/span>{\n  Future<Order> orderFuture = \n      executor.submit(() -> orderService.getOrder(orderId));\n\n  Future<Customer> customerFuture =\n      executor.submit(() -> customerService.getCustomer(customerId));\n\n  Future<InvoiceTemplate> invoiceTemplateFuture =\n      executor.submit(() -> invoiceTemplateService.getTemplate(language));\n\n  Order order = orderFuture.get();\n  Customer customer = customerFuture.get();\n  InvoiceTemplate invoiceTemplate = invoiceTemplateFuture.get();\n\n  return<\/span> Invoice.generate(order, customer, invoiceTemplate);\n}<\/code><\/span>Code-Sprache:<\/span> Java<\/span> (<\/span>java<\/span>)<\/span><\/small><\/pre>\n\n\n
    Wir \u00fcbergeben die drei Teilaufgaben an den Executor<\/code> und warten auf die Teilergebnisse. Der Happy Path ist schnell implementiert. Aber wie behandeln wir Ausnahmen?<\/p>\n\n\n\n
      \n
    • Wenn in einem Subtask ein Fehler auftritt \u2013 wie k\u00f6nnen wir dann die anderen Subtasks abbrechen? Wenn im Beispiel oben loadOrderFromOrderService(...)<\/code> fehlschl\u00e4gt, dann wirft orderFuture.get()<\/code> eine Exception, die createInvoice(...)<\/code>-Methode endet, und wir haben evtl. zwei noch weiterlaufende Threads.<\/li>\n\n\n\n
    • Wie k\u00f6nnen wir die Subtasks abbrechen, wenn der Parent Task (\u201eErstelle eine Rechung\u201d) abgebrochen wird \u2013 oder wenn die komplette Anwendung heruntergefahren wird?<\/li>\n\n\n\n
    • Wie k\u00f6nnen wir \u2013 in einem alternativen Use Case \u2013 verbleibende Subtasks abbrechen, wenn lediglich das Ergebnis eines einzigen Subtasks ben\u00f6tigt wird?<\/li>\n<\/ul>\n\n\n\n
      Alles ist machbar, erfordert aber \u00e4u\u00dferst komplexen, schwer wartbaren Code (im GitHub-Repository findest du zwei Beispiele daf\u00fcr: InvoiceGenerator2b_CompletableFutureCancelling<\/a> und InvoiceGenerator4b_NewVirtualThreadPerTaskCancelling<\/a>).<\/p>\n\n\n\n
      Und was, wenn wir Code dieser Art debuggen m\u00f6chten? Ein Thread-Dump z. B. w\u00fcrde uns haufenweise Threads mit dem Namen \u201epool-X-thread-Y\u201d liefern \u2013 wir w\u00fcssten aber nicht, welcher Pool-Thread zu welchem aufrufenden Thread geh\u00f6rt, da sich alle aufrufenden Threads den Thread-Pool des Executors teilen.<\/p>\n\n\n\n
      Was ist Unstructured Concurrency?<\/h2>\n\n\n\n
      \u201eUnstructured Concurrency\u201d bedeutet, dass unsere Tasks in einem Netz von Threads ablaufen, deren Start und Ende im Code schwer erkennbar ist. Eine saubere Fehlerbehandlung ist meist nicht vorhanden, und oft kommt es zu verwaisten Threads, wenn eine Kontrollstruktur (im Beispiel oben: die createInvoice(...)<\/code>-Methode) endet:<\/p>\n\n\n
      \n
      \"Unstructured
      Unstructured Concurrency<\/figcaption><\/figure>\n<\/div>\n\n\n
      Was ist Structured Concurrency?<\/h2>\n\n\n\n
      Die in Java 19<\/a> als Incubator und Java 21<\/a> als Preview eingef\u00fchrte \u2013 und in Java 25 noch einmal \u00fcberarbeitete \u2013 Structured Concurrency<\/em> ist ein Konzept, das die Implementierung, Lesbarkeit und Wartbarkeit von Code f\u00fcr die Aufteilung einer Aufgabe in Teilaufgaben und deren nebenl\u00e4ufige Abarbeitung erheblich verbessert.<\/p>\n\n\n\n
      Dazu f\u00fchrt sie mit der Klasse StructuredTaskScope<\/code> eine Kontrollstruktur ein, die <\/p>\n\n\n\n
        \n
      • einen klaren Scope definiert, an dessen Anfang die Threads der Teilaufgaben starten und an dessen Ende die Threads der Teilaufgaben enden,<\/li>\n\n\n\n
      • die eine saubere Fehlerbehandlung erm\u00f6glicht<\/li>\n\n\n\n
      • und die einen sauberen Abbruch von Teilaufgaben erlaubt, deren Ergebnisse nicht mehr ben\u00f6tigten werden.<\/li>\n<\/ul>\n\n\n\n
        Was das genau bedeutet, zeige ich dir in den folgenden Abschnitten an mehreren Beispielen.<\/p>\n\n\n\n
        StructuredTaskScope Beispiel<\/h2>\n\n\n\n
        Structured Concurrency<\/em> wird mit der Klasse StructuredTaskScope<\/code> implementiert. Mit dieser Klasse k\u00f6nnen wir das Beispiel wie folgt umschreiben.<\/p>\n\n\n\n
        StructuredTaskScope Beispiel \u2013 Java 21\u201324<\/h3>\n\n\n\n
        Klasse InvoiceGenerator5_StructuredTaskScope.java<\/a> im java-21<\/code>-Branch der Demo-Anwendung:<\/p>\n\n\n
        Invoice createInvoice<\/span>(int<\/span> orderId, int<\/span> customerId, String language)<\/span>\n    throws<\/span> InterruptedException <\/span>{\n  try<\/span> (var<\/span> scope = new<\/span> StructuredTaskScope<>()) {\n    Subtask<Order> orderSubtask = \n        scope.fork(() -> orderService.getOrder(orderId));\n\n    Subtask<Customer> customerSubtask = \n        scope.fork(() -> customerService.getCustomer(customerId));\n\n    Subtask<InvoiceTemplate> invoiceTemplateSubtask =\n        scope.fork(() -> invoiceTemplateService.getTemplate(language));\n\n    scope.join();\n\n    Order order = orderSubtask.get();\n    Customer customer = customerSubtask.get();\n    InvoiceTemplate template = invoiceTemplateSubtask.get();\n\n    return<\/span> Invoice.generate(order, customer, template);\n  }\n}<\/code><\/span>Code-Sprache:<\/span> Java<\/span> (<\/span>java<\/span>)<\/span><\/small><\/pre>\n\n\n
        Eine gemeinsame Erkl\u00e4rung f\u00fcr alle Java-Versionen folgt unter dem Java-25-Beispiel.<\/p>\n\n\n\n
        StructuredTaskScope Beispiel \u2013 Java 25<\/h3>\n\n\n\n
        Klasse InvoiceGenerator5_StructuredTaskScope.java<\/a> im main<\/code>-Branch der Demo-Anwendung:<\/p>\n\n\n
        Invoice createInvoice<\/span>(int<\/span> orderId, int<\/span> customerId, String language)<\/span>\n    throws<\/span> InterruptedException <\/span>{\n  try<\/span> (var<\/span> scope = StructuredTaskScope.open()) {\n    Subtask<Order> orderSubtask = \n        scope.fork(() -> orderService.getOrder(orderId));\n\n    Subtask<Customer> customerSubtask = \n        scope.fork(() -> customerService.getCustomer(customerId));\n\n    Subtask<InvoiceTemplate> invoiceTemplateSubtask =\n        scope.fork(() -> invoiceTemplateService.getTemplate(language));\n\n    scope.join();\n\n    Order order = orderSubtask.get();\n    Customer customer = customerSubtask.get();\n    InvoiceTemplate template = invoiceTemplateSubtask.get();\n\n    return<\/span> Invoice.generate(order, customer, template);\n  }\n}<\/code><\/span>Code-Sprache:<\/span> Java<\/span> (<\/span>java<\/span>)<\/span><\/small><\/pre>\n\n\n
        In diesem einfachen Beispiel unterscheidet sich lediglich die Art, wie der StructuredTaskScope<\/code> ge\u00f6ffnet wird: vor Java 25 mit new StructuredTaskScope<>()<\/code> und ab Java 25 mit StructuredTaskScope.open()<\/code>.<\/p>\n\n\n\n
        Erl\u00e4uterungen f\u00fcr alle Java-Versionen<\/h3>\n\n\n\n
        Verglichen mit dem Un<\/em>structured-Concurrency-Beispiel ersetzen wir den im Scope der Klasse<\/em> liegenden ExecutorService<\/code> durch einen im Scope der Methode<\/em> liegenden StructuredTaskScope<\/code> \u2013 und executor.submit()<\/code> durch scope.fork()<\/code>.<\/p>\n\n\n\n
        Mit scope.join()<\/code> warten wir darauf, dass alle Tasks erledigt sind. Das Risiko verwaister Tasks besteht damit nicht mehr.<\/p>\n\n\n\n
        Danach k\u00f6nnen wir \u00fcber Subtask.get()<\/code> die Ergebnisse der drei Tasks auslesen. <\/p>\n\n\n\n
        StructuredTaskScope Fehlerbehandlung \u2013 Java 21\u201324<\/h3>\n\n\n\n
        Sollte es in einem der Tasks zu einer Exception gekommen sein, wirft Subtask.get()<\/code> eine IllegalStateException<\/code>. Besser ist es daher mit state()<\/code> den Status eines Subtasks abzufragen, bevor wir get()<\/code> aufrufen:<\/p>\n\n\n
        Order order;\nif<\/span> (orderSubtask.state() == Subtask.State.SUCCESS) {\n  order = orderSubtask.get();\n} else<\/span> {\n  \/\/ Handle error<\/span>\n}\n<\/code><\/span>Code-Sprache:<\/span> Java<\/span> (<\/span>java<\/span>)<\/span><\/small><\/pre>\n\n\n
        StructuredTaskScope Fehlerbehandlung \u2013 Java 25<\/h3>\n\n\n\n
        Wenn es in Java 25 zu einer Exception in einem der Tasks kommt, wird diese \u2013 gewrappt in eine StructuredTaskScope.FailedException<\/code> \u2013 bereits von scope.join()<\/code> geworfen. Eine Pr\u00fcfung des Subtask-Status nach dem Aufruf von scope.join()<\/code> ist daher nicht erforderlich.<\/p>\n\n\n\n
        Den Beispielcode ausf\u00fchren<\/h3>\n\n\n\n
        Falls du das Beispiel selbst ausprobieren m\u00f6chtest: Preview-Features m\u00fcssen explizit freigeschaltet werden, in diesem Fall mit --enable-preview --source <verwendete Java-Version><\/code>. Eine genaue Anleitung findest du in der README<\/a> der Demo-Anwendung.<\/p>\n\n\n