Connect with us

Künstliche Intelligenz

Core Java: Parallel, aber richtig – Wie Java-Collectors unter Last bestehen


Manchmal reicht es nicht aus, dass Code funktioniert – er muss auch unter Last funktionieren. In modernen Anwendungen, die große Datenmengen verarbeiten, steht Entwicklerinnen und Entwicklern mit der Streams-API in Java ein elegantes, deklaratives Werkzeug zur Verfügung, um Daten in Pipelines zu transformieren, zu filtern und schließlich zu aggregieren. Die Vorstellung, mit wenigen Zeilen komplexe Datenoperationen zu beschreiben, ist nicht nur verführerisch, sondern tatsächlich realistisch. Doch was passiert, wenn diese Operationen auf Millionen von Einträgen treffen? Wenn die Ausführung in mehreren Threads parallel erfolgen soll, um Zeit zu sparen und Mehrkernsysteme effektiv zu nutzen?


Sven Ruppert

Sven Ruppert

Seit 1996 programmiert Sven Java in Industrieprojekten und seit über 15 Jahren weltweit in Branchen wie Automobil, Raumfahrt, Versicherungen, Banken, UN und Weltbank. Seit über 10 Jahren ist er von Amerika bis nach Neuseeland als Speaker auf Konferenzen und Community Events, arbeitete als Developer Advocate für JFrog und Vaadin und schreibt regelmäßig Beiträge für IT-Zeitschriften und Technologieportale.
Neben seinem Hauptthema Core Java beschäftigt er sich mit TDD und Secure Coding Practices.

Genau an dieser Stelle rückt ein Konzept in den Vordergrund, das oft zu wenig Beachtung findet: der Collector. Er ist das Element am Ende einer Stream-Pipeline, das bestimmt, was mit den verarbeiteten Daten geschehen soll. Und obwohl die API einfach erscheint – collect(Collectors.toList()) – verbirgt sich dahinter eine Architektur, die in paralleler Ausführung ganz eigene Herausforderungen mit sich bringt.

Im Folgenden geht es daher nicht nur um die Syntax oder die Mechanik von Collectoren, sondern um ein tiefes Verständnis für die Bedingungen, unter denen sie korrekt und effizient zum Einsatz kommen. Wir schauen auf Standardlösungen des JDK (Java Development Kit), diskutieren individuelle Implementierungen, zeigen typische Fehler – und kommen letztlich zu der Frage: Wie viel Parallelisierung verträgt ein Collector, ohne dass es gefährlich wird?

Grundlagen: Collector und Parallelität

Die Streams-API von Java vermittelt auf den ersten Blick den Eindruck, dass sich das Sammeln von Ergebnissen – das sogenannte terminale Aggregieren – problemlos parallelisieren lässt. Doch hinter der Methode collect(...) verbirgt sich mehr als nur syntaktische Bequemlichkeit. Sie ist eine koordinierte Zusammenarbeit zwischen einem Datenstrom und einem Collector – einem Objekt, das aus Einzelteilen ein Ganzes formt.

Ein Collector besteht im Kern aus vier funktionalen Komponenten: dem supplier, der für jeden Teilprozess einen neuen Zwischenspeicher bereitstellt; dem accumulator, der Elemente in diesen Zwischenspeicher einspeist; dem combiner, der mehrere Zwischenspeicher zu einem zusammenführt; und schließlich dem finisher, der das Endergebnis produziert. Während supplier und accumulator auch in sequenziellen Streams essenziell sind, tritt der combiner erst dann in Aktion, wenn mehrere Threads unabhängig voneinander gesammelt haben – also bei einem parallelStream().

Hier liegt der erste fundamentale Unterschied zwischen sequenzieller und paralleler Verarbeitung: In einem sequenziellen Stream genügt es, schrittweise in einen einzigen Speicher zu akkumulieren. In der parallelen Variante hingegen entstehen mehrere voneinander isolierte Zwischenspeicher, deren Inhalte später konfliktfrei zu einem Endergebnis verschmolzen werden müssen. Dieses Verschmelzen geschieht durch den combiner – und genau an dieser Stelle entscheidet sich, ob ein Collector für parallele Verarbeitung tauglich ist oder nicht.

Die Tauglichkeit hängt von mehreren Eigenschaften ab: Die Operationen müssen assoziativ sein, also unabhängig von der Kombination der Zwischenergebnisse dasselbe Resultat liefern. Zudem darf kein geteilter Zustand ohne Synchronisierung vorliegen. Und nicht zuletzt müssen die einzelnen Schritte deterministisch und frei von Seiteneffekten bleiben – andernfalls wird aus einer Parallelisierung schnell eine Quelle subtiler Fehler.

Das Wissen um diese strukturellen Anforderungen ist der erste Schritt zu einem bewussten Einsatz paralleler Verarbeitung. Denn nur wer verstanden hat, wie Collector und Stream im Zusammenspiel funktionieren, kann abschätzen, wann ein Performancegewinn möglich ist – und wann man sich stattdessen instabile oder schlicht falsche Ergebnisse einhandelt.

Kriterien für parallelisierbare Collectoren

Stellen wir uns vor, ein Stream wird parallel ausgeführt – etwa über ein großes Dataset, das in mehrere Segmente aufgeteilt ist. Jedes dieser Segmente wird nun unabhängig verarbeitet. Was trivial klingt, hat tiefgreifende Implikationen: Sobald mehrere Threads gleichzeitig sammeln, dürfen sich deren Zwischenergebnisse nicht in die Quere kommen. Die Verantwortung für die Korrektheit liegt beim Collector – genauer: bei seiner strukturellen und funktionalen Ausgestaltung.

Die erste grundlegende Eigenschaft ist Assoziativität. Ein combiner-Aufruf muss unabhängig von der Reihenfolge konsistente Ergebnisse liefern. combine(a, b) und combine(b, a) müssen äquivalente Resultate erzeugen. Das ist notwendig, weil die Reihenfolge der Kombination in einem parallelen Kontext vom Scheduler abhängt – und somit unvorhersagbar ist.

Der zweite Punkt betrifft den Zugriff auf Speicherstrukturen. Sobald ein Collector während der Akkumulation einen gemeinsamen, veränderbaren Zustand nutzt – etwa eine nicht synchronisierte Liste oder Map – entsteht ein potenzieller Hotspot für Race Conditions. Der Collector muss entweder ausschließlich mit lokalen, thread-isolierten Zwischenspeichern arbeiten oder sich auf nebenläufige Datenstrukturen stützen, wie etwa ConcurrentHashMap, LongAdder oder explizit synchronisierte Wrapper.

Darüber hinaus ist auch Determinismus ein wesentliches Kriterium: Eine parallele Ausführung darf nicht zu unterschiedlichen Ergebnissen führen – weder inhaltlich noch strukturell. Insbesondere bei ungeordneten Strukturen wie HashSet oder HashMap ist Vorsicht geboten, da die Iterationsreihenfolge variieren kann – was bei Collectors.joining() oder Collectors.toMap() problematisch wird, wenn die Anwendung auf Ordnung angewiesen ist.

Die drei Anforderungen Assoziativität, isolierter Zustand und Determinismus bilden den technischen Prüfstein für parallele Collectoren. Sie sind nicht optional, sondern grundlegend. Wer sie ignoriert, riskiert schwer zu reproduzierende Fehler, unvollständige Ergebnisse oder performante, aber semantisch falsche Ausgaben.

Parallelität in Java Streams ist mächtig, aber nicht trivial umzusetzen

Beispiele aus der Java-Standardbibliothek: Ein naheliegender Weg, um das abstrakte Konzept paralleler Collectoren greifbar zu machen, führt über die bereits in der Java-Standardbibliothek enthaltenen Collectors. Viele Entwickler nutzen Collectors.toList(), toSet() oder joining() nahezu täglich – selten jedoch im Wissen darum, ob und wie sich diese Collectoren in einem parallelen Kontext verhalten.

Ein einfaches Beispiel: Der Collector Collectors.toList() nutzt intern eine ArrayList. Diese ist nicht thread-sicher. Folglich ist das Ergebnis bei paralleler Verwendung potenziell inkonsistent, sofern nicht intern für Isolation der Zwischenspeicher gesorgt ist.


public static 
Collector> toList() {
   return new CollectorImpl<>(ArrayList::new, List::add,
                              (left, right) -> { left.addAll(right); return left; },
                              CH_ID);
}


Tatsächlich funktioniert dieser Collector in parallelen Streams dennoch korrekt, weil die Streams-API jedem Thread seinen eigenen Akkumulationsbereich zuteilt und erst am Ende über einen kombinierten Merge-Prozess zusammenführt. Der entscheidende Punkt liegt also nicht in der Datenstruktur selbst, sondern in ihrer kontrollierten Isolierung.

Weniger robust zeigt sich Collectors.groupingBy(...). Diese Variante basiert auf einer HashMap, die nicht für gleichzeitigen Zugriff ausgelegt ist. Wird dieser Collector ohne Schutzmaßnahmen in einem parallelStream() eingesetzt, drohen Race Conditions. Die Standardlösung dafür lautet Collectors.groupingByConcurrent(...), die intern auf ConcurrentHashMap setzt und somit für gleichzeitigen Zugriff konzipiert ist.


public static 
Collector>>
groupingByConcurrent(Function super T, ? extends K> classifier) {
   return groupingByConcurrent(classifier, ConcurrentHashMap::new, toList());
}


Ein Blick auf die Signatur dieser Methode zeigt bereits die Intention:


Map> result = namen.parallelStream()
    .collect(Collectors.groupingByConcurrent(String::length));


In diesem Beispiel werden Strings nach ihrer Länge gruppiert – in einer parallel verarbeitbaren Weise. Entscheidend ist, dass sowohl die Map-Implementierung als auch der Akkumulationsprozess thread-safe sind.

Ebenso interessant ist Collectors.toConcurrentMap(...), der explizit dafür vorgesehen ist, große Mengen von Key-Value-Paaren parallel zu aggregieren. Hier ist die Kombination von Schlüsselkonflikten und der richtige Umgang mit Merge-Funktionen von besonderem Interesse.

Die Erkenntnis aus diesen Beispielen lautet: Nicht jeder Standard-Collector ist per se für Parallelität geeignet. Nur weil eine Methode aus dem Collectors-Baukasten stammt, bedeutet das nicht, dass sie in jeder Ausführungskonfiguration korrekt funktioniert. Der Kontext entscheidet – und mit ihm die verwendete Datenstruktur, das Verhalten des combiner und die Art der Akkumulation.

Wer also aus einem Stream nicht nur ein beliebiges Ergebnis, sondern ein korrektes und performantes Ergebnis ziehen will, sollte die Wahl seines Collectors ebenso sorgfältig treffen wie das Filterkriterium am Anfang der Pipeline.

Eigene parallele Collector-Implementierungen

So mächtig die vorgefertigten Collectors der Java-Standardbibliothek auch sein mögen, manchmal reichen sie für spezifische Anforderungen nicht aus. Besonders wenn domänenspezifische Aggregationen, spezialisierte Datenstrukturen oder nicht-triviale Reduktionslogik benötigt werden, lohnt sich ein Blick auf die Möglichkeit, eigene Collector-Implementierungen zu erstellen.

In der Regel lässt sich ein eigener Collector mit der statischen Methode Collector.of(...) erstellen. Diese Methode erwartet fünf Parameter: einen Supplier, der einen neuen Akkumulator erzeugt; einen BiConsumer, der ein Element in den Akkumulator einfügt; einen BinaryOperator zum Kombinieren zweier Akkumulatoren; optional eine Function zur Konvertierung des Ergebnisses; und schließlich ein Array Collector.Characteristics..., das Metainformationen wie CONCURRENT oder UNORDERED bereitstellt.

Ein einfacher, aber aussagekräftiger Collector könnte etwa Zeichenketten parallel zu einer ConcurrentLinkedQueue sammeln:


Collector> toConcurrentQueue() {
    return Collector.of(
        ConcurrentLinkedQueue::new,
        Queue::add,
        (left, right) -> { left.addAll(right); return left; },
        Collector.Characteristics.CONCURRENT, Collector.Characteristics.UNORDERED
    );
}


Dieser Collector ist sowohl CONCURRENT als auch UNORDERED, das bedeutet: Er kann von mehreren Threads gleichzeitig beschrieben werden, ohne dass die Einfügereihenfolge garantiert werden muss. Wichtig ist dabei, dass ConcurrentLinkedQueue als thread-sichere Datenstruktur fungiert und die Operation addAll ebenfalls nebenläufig unkritisch ist.

Doch auch komplexere Szenarien sind denkbar, etwa das parallele Ermitteln von statistischen Kennzahlen (Minimum, Maximum, Durchschnitt) über eine Datenmenge. In solchen Fällen kann ein record als Akkumulatorstruktur dienen, der in sich bereits alle benötigten Teilzustände kapselt. Der combiner muss dann lediglich diese Strukturen feldweise konsolidieren.

Eigene Collector-Implementierungen zwingen dazu, sich mit der Parallelisierbarkeit der genutzten Datenstrukturen und der Kombinierbarkeit der Aggregationslogik intensiv auseinanderzusetzen. Das ist kein Nachteil, sondern ein wertvoller Lerneffekt. Denn nur wer versteht, was ein Collector im Inneren macht, kann ihn bewusst und sicher einsetzen.

Best Practices für den produktiven Einsatz

Wer Collectoren im Parallelisierungskontext produktiv einsetzen möchte, sollte einige bewährte Strategien berücksichtigen – nicht als starre Regeln, sondern als Orientierungsrahmen für robuste und effiziente Implementierungen.

Ein erster Grundsatz lautet: Nur parallelisieren, wenn ein echter Nutzen zu erwarten ist. Kleine Datenmengen, triviale Transformationen oder IO-gebundene Prozesse profitieren in der Regel nicht von parallelStream(). Im Gegenteil: Der Overhead des Thread-Managements kann den potenziellen Performancegewinn sogar übersteigen. Eine Parallelisierung lohnt sich erst dann, wenn die zu verarbeitenden Datenmengen hinreichend groß und die Operationen CPU-intensiv sind.

Zweitens: Nur thread-sichere oder isolierte Datenstrukturen verwenden. Das bedeutet entweder, dass jeder Thread seinen eigenen Akkumulator nutzt – was die Streams-API intern unterstützt – oder dass explizit nebenläufige Datenstrukturen wie ConcurrentHashMap, ConcurrentLinkedQueue oder atomare Wrapper eingesetzt werden.

Drittens: Collectors gezielt auswählen. Die Standardbibliothek bietet mit groupingByConcurrent, toConcurrentMap oder mapping leistungsfähige Werkzeuge, die speziell für den parallelen Einsatz konzipiert wurden. Wer darüber hinaus eigene Lösungen entwickelt, sollte besonderes Augenmerk auf den combiner und die Assoziativität der Logik legen.

Viertens: Ergebnisse validieren – insbesondere bei neuen oder komplexen Pipelines. Parallele Streams verhalten sich nicht deterministisch in der Ausführung, deshalb sind Tests in unterschiedlichen Auslastungsszenarien und unter variierender Last notwendig. Das gilt vor allem dann, wenn Entwicklerinnen oder Entwickler Collectoren selbst entwickeln oder anpassen.

Und nicht zuletzt: Messen statt vermuten. Tools wie JMH (Java Microbenchmark Harness), Flight Recorder oder async-profiler helfen dabei, realistische Aussagen über die Performancevorteile zu treffen. Parallelisierung ohne Metriken ist wie Blindflug mit Rückenwind – vielleicht schneller, aber womöglich in die falsche Richtung.




(Bild: Playful Creatives / Adobe Stock)

Am 14. Oktober findet die betterCode() Java 2025 statt. Bei der von iX und dpunkt.verlag ausgerichteten Online-Konferenz dreht sich alles um das für September geplante Java 25, das auch als LTS-Release verfügbar sein wird. Außerdem gibt es eine Keynote und ein Panel zu 30 Jahren Java und einen Vortrag zu ML für Java-Anwendungen.



Source link

Verwandte Themen:
Weiterlesen
Kommentar schreiben

Leave a Reply

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Künstliche Intelligenz

Fusionsenergie: Warum Europa und die USA das Rennen verlieren könnten


Fusionsenergie hat das Potenzial, unsere geopolitische Landschaft, die sich noch immer um fossile Energieträger dreht, grundlegend zu verändern. Ein Durchbruch hier würde endlich Energieunabhängigkeit, Energiesicherheit und Energiefülle liefern, die für die modernen Industrie- und Dienstleistungssektoren erforderlich sind. Klar ist aber auch: Die Technologie wird von jenen Ländern kontrolliert werden, denen sowohl die Entwicklung der erforderlichen komplexen Lieferketten als auch der Bau entsprechender Kraftwerke in ausreichender wirtschaftlicher Größe gelingt.

Fusionsenergie: Wo die USA und der Westen noch investieren müssen

Die USA und die anderen westlichen Länder müssen daher neben der Entwicklung der Grundlagen für praktische Fusionskraftwerke auch starke Lieferketten für eine Reihe neuer Technologien aufbauen. Denn Investitionen in solche Lieferketten und die Skalierung komplexer Produktionsprozesse sind zunehmend eine Stärke Chinas. Gleichzeitig sind sie seit Jahrzehnten eine Schwäche des Westens, was zur Abwanderung vieler wichtiger Industrien aus dem Westen nach China geführt hat. Mit der Fusionsenergie laufen wir Gefahr, dass sich die Geschichte wiederholt.

Eigentlich muss das nicht sein: Die USA und Europa waren die dominierenden öffentlichen Geldgeber für die Fusionsenergieforschung und sind die Heimat vieler weltweit wegweisender Projekte des Sektors aus der Privatwirtschaft. Der Westen hat also viele der grundlegenden Technologien entwickelt, die die Fusionsenergie nutzbar machen könnten. Doch China holt auf: In den vergangenen fünf Jahren wurde die Fusionsenergie mit Investitionen massiv gestärkt.

Die industrielle Basis, die Chinas aufstrebender Fusionsenergieindustrie zur Verfügung steht, könnte es dem Land nun ermöglichen, die Lernkurve viel schneller und effektiver zu nehmen als einst der Westen. Die Kommerzialisierung erfordert Know-how, spezielle Fähigkeiten und ergänzende Ressourcen, darunter besagte Lieferketten und Arbeitskräfte in angrenzenden Branchen. Insbesondere im Vergleich zu China haben die USA und Europa die für eine Fusionsindustrie erforderlichen industriellen Ressourcen – wie Dünnschichtverarbeitung und Leistungselektronik – deutlich zu wenig gefördert. Um wettbewerbsfähig zu bleiben, müssen die USA, ihre Verbündeten und Partner nicht nur stärker in die Fusionsenergie selbst investieren, sondern auch in die angrenzenden Technologien, die für die industrielle Basis von entscheidender Bedeutung sind.

Chinas Fusionsenergie setzt auf das Konzept Tokamak

Chinas Weg zur Dominanz und Ideen für den Westen, wettbewerbsfähig zu bleiben, lassen sich anhand der derzeit vielversprechendsten wissenschaftlichen und technologischen Ansätze zur Erzeugung von Fusionsenergie im stromnetzrelevanten Maßstab verstehen. Dieser Weg basiert auf dem Tokamak, einer Technologie, bei der ein Magnetfeld ionisiertes Gas – Plasma genannt – einschließt und schließlich Kerne verschmilzt. Bei diesem Prozess wird Energie freigesetzt, die von Wärme in Elektrizität umgewandelt werden kann. Tokamaks bestehen aus mehreren kritischen Systemen, darunter Plasmaeinschluss und Plasmaheizung, die notwendige Brennstoffproduktion und -verarbeitung, sogenannte Blankets samt Wärmeflussmanagement sowie Energieumwandlung.

Ein genauer Blick auf die für den Bau dieser kritischen Systeme erforderlichen verwandten Branchen zeigt deutlich den Vorsprung Chinas und gibt gleichzeitig einen Einblick in die Herausforderungen beim Aufbau einer industriellen Basis für die Fusionsenergie in den USA oder Europa. China ist in drei von sechs Schlüsselindustrien für diesen Bereich führend. Der Westen läuft gleichzeitig Gefahr, in zwei weiteren Industrien seine Führungsposition zu verlieren. Chinas industrielle Stärke in den Bereichen Dünnschichtverarbeitung, großen Metalllegierungsstrukturen und Leistungselektronik bildet eine solide Grundlage für den Aufbau der vorgelagerten Lieferkette für die Fusionsenergie.

Die Bedeutung der Dünnschichtverarbeitung wird im Plasmaeinschlusssystem deutlich. Tokamaks verwenden starke Elektromagnete, um das Fusionsplasma an Ort und Stelle zu halten, und die Magnetspulen müssen aus supraleitenden Materialien hergestellt werden. Seltenerd-Barium-Kupferoxid-Supraleiter (REBCO) sind die leistungsfähigsten Materialien, die in ausreichender Menge für den Einsatz in der Fusionsenergie verfügbar sind.

Die REBCO-Industrie, die auf Dünnschichttechnologien angewiesen ist, hat derzeit aber geringe Produktionsmengen, die sich auf weltweit verteilte Hersteller aufspalten. Mit dem Wachstum der Fusionsenergieindustrie wird sich die Produktionsbasis für REBCO jedoch wahrscheinlich auf diejenigen Industrieunternehmen konzentrieren, die schnell von Skaleneffekten profitieren können. China ist heute weltweit führend in der Dünnschicht-Großserienfertigung von Solarzellen und Flachbildschirmen und verfügt über die entsprechenden Fachkräfte, den notwendigen Werkzeugbau, die Infrastruktur und die vorgelagerte Materialversorgungskette. Ohne erhebliche Aufmerksamkeit und Investitionen seitens des Westens ist China hervorragend positioniert, um die Dünnschichtverarbeitung von REBCO für Fusionsenergiemagnete zu dominieren.

Konstruktion in XL und Metalllegierungen

Das ist nicht alles: Die Elektromagnete in einem Tokamak in Originalgröße sind so hoch wie ein dreistöckiges Gebäude. Um diese Elektromagnete um den großen Vakuumbehälter herum zu halten, der das magnetisch eingeschlossene Plasma physisch enthält, sind Konstruktionen aus starken Metalllegierungen erforderlich. Ähnliche groß dimensionierte, komplexe Metallkonstruktionen werden für den Schiffbau, die Luft- und Raumfahrt, die Öl- und Gasinfrastruktur sowie für Turbinen benötigt. Für Fusionskraftwerke werden jedoch neue Legierungen notwendig, die strahlungsbeständig sind, kryogenen Temperaturen standhalten und korrosionsbeständig bleiben. Chinas Fertigungskapazitäten und seine metallurgische Forschung versetzen das Land in eine gute Position, um andere globale Anbieter bei der Herstellung der erforderlichen Speziallegierungen und deren Verarbeitung zu komplexen Strukturen für die Fusionsenergie zu übertrumpfen.

Der Westen hat noch Chancen in der Fusionsenergie

Ein Tokamak erfordert weiterhin eine gigantische Leistungselektronik. Auch hier dominiert China. Ähnliche Systeme finden sich in der Infrastruktur von Hochgeschwindigkeitsbahnzügen (HSR), in Microgrids für Stromnetze und in Lichtbogenöfen. Bis 2024 hatte China über 48.000 Kilometer HSR-Strecken in Betrieb genommen. Das ist dreimal so viel wie das europäische HSR-Netz und 55-mal so lang wie das Acela-Netz in den USA, das langsamer ist als das der Chinesen. Zwar sind auch andere Länder in diesem Bereich vertreten, doch verfügt China über neuere Fachkenntnisse, die in größerem Umfang angewendet werden. Aber: Der Westen hat noch immer die Chance, in den drei anderen für die Fusionsenergielieferkette wichtigen Branchen die Führung zu übernehmen. Das sind Kryoanlagen, Brennstoffverarbeitung und Blankets.

Die Elektromagnete in einem funktionsfähigen Tokamak müssen auf kryogenen Temperaturen von etwa 20 Kelvin gehalten werden, um ihre Supraleitfähigkeit zu halten. Dies erfordert große Kühlungsanlagen mit einer Leistung von mehreren Megawatt. Hier ist noch nicht klar, welches Land am besten aufgestellt ist, um die Branche anzuführen. Die beiden weltweit größten Anbieter von Kryoanlagen sind die europäischen Unternehmen Linde Engineering und Air Liquide Engineering; in den USA sind Air Products and Chemicals und Chart Industries vertreten. Aber sie sind nicht allein: Zu den chinesischen Marktführern im Kryobereich zählen Hangyang Group, SASPG, Kaifeng Air Separation und SOPC. Jede dieser Weltregionen verfügt bereits über eine industrielle Basis, die skaliert werden könnte, um die Anforderungen der Fusionsenergie zu erfüllen.

Die Brennstoffproduktion ist ein noch junger Teil der Technik, der Verarbeitungstechnologien für leichte Isotopengase – Wasserstoff, Deuterium und Tritium – erfordert. Einige Verfahren werden bereits in kleinem Maßstab in der Medizin, bei der Herstellung von Wasserstoffwaffen und in der wissenschaftlichen Forschung in den USA, Europa und China eingesetzt. Der für die Fusionsenergieindustrie erforderliche Maßstab ist jedoch in der heutigen industriellen Basis nicht vorhanden, was eine große Chance für Erstentwickler der erforderlichen Fähigkeiten darstellt.

Ebenso bieten Blankets und Wärmeflussmanagement eine Chance für den Westen. Blankets sind das Medium, mit dem Energie aus der Fusionsreaktion absorbiert und Tritium erzeugt wird. Für Blankets im kommerziellen Maßstab wird eine völlig neue Technologie erforderlich. Bislang verfügt keine der angrenzenden Branchen über relevante kommerzielle Fachkenntnisse in den Bereichen flüssiges Lithium, Lithium-Blei-Eutektika oder fusionsspezifische Schmelzsalze, die für die Blanket-Technologie erforderlich sind. Einige sich überschneidende Verfahren befinden sich in der frühen Entwicklungsphase in der Atomindustrie. Als weltweit größter Produzent von Beryllium haben die USA die Chance, hier eine Führungsrolle zu übernehmen, da dieses Element ein Schlüsselelement in führenden Konzepten für Fusionsenergieblankets ist. Die Verwendung von Beryllium muss jedoch mit Technologieentwicklungsprogrammen für die anderen Spezialkomponenten einhergehen.

Peking hat die Möglichkeiten erkannt

Die sechs genannten Branchen werden für die Skalierung der Fusionsenergie von entscheidender Bedeutung sein. In einigen Bereichen, wie der Dünnschichtverarbeitung und großen Metalllegierungsstrukturen, hat China bereits einen beträchtlichen Vorsprung. Entscheidend ist, dass die Volksrepublik die Bedeutung dieser angrenzenden Branchen erkannt hat und sie aktiv für seine Fusionsenergiebemühungen nutzt.

So hat China beispielsweise ein Konsortium ins Leben gerufen, dem Industriegiganten aus den Bereichen Stahl, Werkzeugmaschinen, Stromnetze, Stromerzeugung und Luft- und Raumfahrt angehören. Für den Westen wird es äußerst schwierig sein, in diesen Bereichen aufzuholen. Politische Entscheidungsträger und Wirtschaftsführer müssen aufmerksam sein und versuchen, robuste, alternative Lieferketten aufzubauen.

Als industrielles Kraftzentrum könnten Kryoanlagen weiterhin eine Chance für die Führungsrolle des Westens sein. Die Stärkung der westlichen Kryoanlagenproduktion etwa durch die Schaffung einer Nachfrage nach mehr Erdgasverflüssigung wäre ein großer Segen für die zukünftige Lieferkette für Kryoanlagen, die die Fusionsenergie unterstützen.

Die USA und die europäischen Länder haben auch die Chance, in den aufstrebenden Industriebereichen der Brennstoffverarbeitung und der Blanket-Technologien eine Führungsrolle zu übernehmen. Dazu müssen die politischen Entscheidungsträger mit den Unternehmen arbeiten, um sicherzustellen, dass öffentliche und private Mittel für diese wichtigen neuen Lieferketten bereitgestellt werden. Die Regierungen müssen möglicherweise als Erstkunden fungieren und Fremdkapital für bedeutende Kapitalinvestitionen bereitstellen.

Japan und Südkorea sollen helfen

Der Westen könnte auch mehr tun, um Anreize für privates Kapital und Eigenkapitalfinanzierung zu schaffen, beispielsweise durch eine günstige Besteuerung von Kapitalerträgen aus Fusionsenergie. In den Bereichen der Dünnschicht- und Metalllegierungsproduktion werden die USA und Europa wahrscheinlich Partner wie Südkorea und Japan benötigen, die über die industrielle Basis verfügen, um weltweit mit China konkurrieren zu können.

Die Notwendigkeit, mehrere Branchen und Lieferketten miteinander zu verbinden und zu kapitalisieren, erfordert langfristiges Denken und eine klare Führung. Ein Fokus auf die Nachfrageseite dieser komplementären Branchen ist unerlässlich. Die Fusionsenergie ist, schätzen Beobachter, noch gut ein Jahrzehnt von der Industriereife entfernt, daher muss ihre Lieferkettenbasis risikolos gestellt und kurzfristig rentabel gestaltet werden, indem man sich auf andere primäre Nachfragemärkte konzentriert, die zu unserer wirtschaftlichen Vitalität beitragen. Um nur einige zu nennen: Die Politik kann die Modernisierung des Stromnetzes unterstützen, um die Binnennachfrage nach Leistungselektronik und die heimische Halbleiterfertigung zur Unterstützung der Dünnschichtverarbeitung anzukurbeln.

Der Westen muss sich auch auf die Nachfrage nach Energieerzeugung selbst konzentrieren. Als weltweit größter Energieverbraucher wird China die Nachfrage seines riesigen Binnenmarktes nutzen, um die Lernkurve schnell zu nehmen und nationale Marktführer zu stärken. Diese Strategie hat China lange mit großem Erfolg eingesetzt, um die globale Fertigung zu dominieren, zuletzt in der Elektrofahrzeugindustrie. Insgesamt waren Investitionen sowohl auf der Angebots- als auch auf der Nachfrageseite eine erfolgreiche Strategie für China.

Der Wettbewerb um die Zukunft der Fusionsenergie hat also begonnen. Jetzt ist es an der Zeit, dass die USA und ihre westlichen Verbündeten in das grundlegende Innovationsökosystem investieren, das für eine dynamische und resiliente industrielle Basis erforderlich ist, um uns diese Zukunft zu sichern.

Dieser Beitrag ist zuerst bei t3n.de erschienen.


(jle)



Source link

Weiterlesen

Künstliche Intelligenz

Das Mercedes-Team der Formel 1 nutzt TeamViewer im Simulator


Das Formel-1-Team von Mercedes-AMG Petronas nutzt einen digitalen Simulator, um Team, Fahrer und Material auf das jeweils kommende Rennwochenende vorzubereiten, ohne dabei die in Handarbeit gefertigten Wagen zu verschleißen. Wie der Mercedes-Rennstall im südlichen England und der Simulator aussehen, zeigt Brad Pitt als Rennfahrer Sonny Hayes in Joseph Kosinskis Kinofilm F1.

Formel-1-Simulator mit digitalem Zwilling

Im sogenannten „Driver-in-the-Loop“-Simulator läuft ein digitaler Zwilling des Rennwagens. Piloten George Russell und Formel-1-Neuling Kimi Antonelli nutzen den Simulator zur Vorbereitung, beispielsweise um zu testen, wie sich der Wagen auf der Strecke bei den gegebenen Wetterbedingungen verhält.

Im DiL-Simulator können die Piloten die Streckenbedingungen und Fahrzeugkomponenten virtuell testen, bevor sie auf der Strecke zum Einsatz kommen. Dabei werden neben Telemetriedaten auch subjektive Rückmeldungen der Fahrer einbezogen, um Aerodynamik, Reifenstrategien oder Fahrzeugbalance zu optimieren.

Auch Simulator- und Reservefahrer arbeiten an Rennwochenenden mit den Ingenieuren aus der Fabrik in Brackley zusammen, um an Lösungen für Herausforderungen auf der Strecke zu tüfteln. Was im Simulator gelingt, findet im nächsten Renneinsatz Anwendung.

Datenübertragung per Fernwartungssoftware

Jedes Formel-1-Team spannt während der Rennen eigene WLANs auf, um große Mengen telemetrischer Daten über Verhalten und Zustand von Reifen, Bremsen, Motorleistung und andere Details möglichst verlässlich zu übertragen und dabei vor dem Zugriff durch die Konkurrenz zu schützen.

Dafür nutzt der Rennstall die Software TeamViewer Tensor. Über die Fernwartungsplattform können sich Ingenieure aus der Ferne mit dem Simulator verbinden und die Ergebnisse gemeinsam mit den Fahrern bewerten, etwa bei Nachtschichten während eines Grand-Prix-Wochenendes. Über „dynamisches Remoting“ können mehrere Nutzer gleichzeitig auf dasselbe Gerät zugreifen.

Für die Übertragung des Remote-Bildschirms in bis zu 4K-Auflösung nutzt TeamViewer einen eigenen Algorithmus, der analysiert, wie viel Bewegung gerade auf dem entfernten Bildschirm stattfindet. Läuft dort ein Video oder Videospiel, nutzt die Software einen auf dem System installierten Videocodec wie H.264 oder AV1. Wird nur ein Dokument angezeigt, überträgt TeamViewer Einzelbilder.


(akr)



Source link

Weiterlesen

Künstliche Intelligenz

Alles Muzak? Wie KI-Generatoren die Musikindustrie umkrempeln


Wer verstehen will, was KI-Generatoren wie Suno oder Udio mit der Musikindustrie anrichten, sollte einen alten Philosophen befragen. Vor über hundertfünfzig Jahren analysierte Karl Marx den kapitalistischen Produktionsprozess – und prognostizierte dessen Untergang. Von künstlicher Intelligenz war damals keine Rede, wohl aber von vollautomatischen Fabriken, die ohne menschliches Zutun Waren am Fließband herstellen.

Betrachtet man die Entwicklung der Musikindustrie – von der Aufzeichnung auf Schellack über die Digitalisierung auf CD, von Streamingdiensten bis hin zu KI-Generatoren –, scheint dieser Punkt bald erreicht. Auf Knopfdruck generierte KI-Musik markiert jedoch nicht nur einen technischen Fortschritt, sondern auch eine Krise: die der Künstler und die der Musik als konsumierbare Ware.

  • KI-Musikdienste eignen sich die Werke von Musikern, Komponisten und Nutzern an, ohne sie bislang dafür zu bezahlen.
  • KI-Generatoren senken die Produktionskosten, aber auch den Tauschwert der Musik.
  • Damit Musikplattformen Mehrwert abschöpfen können, brauchen Sie weiter menschliche Komponisten und Musiker. Eine Vollautomation per KI würde ihr Geschäftsmodell kippen.

In diesem Artikel zeichnen wir die Etappen dieser Entwicklung nach und werfen einen Blick in die Zukunft: Was kommt nach den KI-Diensten und wie können Musiker diesen Prozess überleben?


Das war die Leseprobe unseres heise-Plus-Artikels „Alles Muzak? Wie KI-Generatoren die Musikindustrie umkrempeln“.
Mit einem heise-Plus-Abo können Sie den ganzen Artikel lesen.



Source link

Weiterlesen

Beliebt