Shared State
Shared State bezeichnet Daten, auf die mehrere Programmteile gleichzeitig zugreifen und die sie auch verändern dürfen. Das spart Kopien und hält alle auf demselben Stand, führt aber leicht zu Fehlern, wenn zwei Zugriffe zeitlich zusammenfallen.
Ein Programm merkt sich während der Arbeit ständig Dinge: den Namen des angemeldeten Nutzers, den Inhalt eines Warenkorbs, den Punktestand in einem Spiel. Diese gemerkten Werte nennt man den Zustand des Programms. Von Shared State spricht man, wenn mehrere Teile eines Programms auf denselben Wert zugreifen und ihn auch ändern dürfen. Das Gegenstück wäre, dass jeder Teil seine eigene private Kopie hat und niemand sonst sie anfassen kann. Ein anschauliches Bild ist ein Whiteboard im Büro: Alle sehen dasselbe Board, alle dürfen darauf schreiben, und deshalb muss man sich einigen, wer wann schreibt.
Warum geteilte Daten so leicht kaputtgehen
Solange nur ein Programmteil zur Zeit arbeitet, ist geteilter Zustand harmlos. Moderne Software läuft aber fast nie so. Ein Server bearbeitet hunderte Anfragen gleichzeitig, eine App rechnet im Hintergrund weiter, während der Nutzer tippt. Wenn zwei dieser Abläufe denselben Wert gleichzeitig ändern, kann das Ergebnis falsch werden.
Das klassische Beispiel ist ein Kontostand von 100 Euro. Zwei Abbuchungen von je 30 Euro lesen den Stand gleichzeitig, beide sehen 100, beide rechnen 70 aus, beide schreiben 70 zurück. Am Ende fehlen 30 Euro, obwohl beide Buchungen erfolgreich meldeten. Solche Fehler heißen Race Conditions, also Wettlaufsituationen. Sie sind gefürchtet, weil sie nur manchmal auftreten und im Test oft unsichtbar bleiben.
Genau deshalb ist Shared State ein Thema, das weit über Programmierdetails hinausgeht. Fehlerhafte Zustandsverwaltung steckt hinter doppelt gebuchten Flügen, verschwundenen Bestellungen und falsch angezeigten Lagerbeständen. Der Aufwand, den Firmen dagegen betreiben, ist entsprechend groß.
Sperren, Kopien und Nachrichten
Die älteste Lösung ist die Sperre, im Englischen Lock. Wer den Wert ändern will, meldet sich an und blockiert ihn für alle anderen. Die übrigen warten, bis die Sperre wieder freigegeben wird. Das funktioniert zuverlässig, kostet aber Tempo, weil Wartezeit entsteht.
Ein zweiter Weg ist, den geteilten Zustand möglichst zu vermeiden. Statt einen Wert zu überschreiben, erzeugt das Programm eine neue Version und lässt die alte unangetastet. Dieses Prinzip heißt Unveränderlichkeit und ist die Grundidee vieler moderner Programmiersprachen. Wo nichts überschrieben wird, kann auch kein Wettlauf entstehen.
Der dritte Ansatz verzichtet ganz auf gemeinsame Daten. Jeder Programmteil besitzt seinen eigenen Zustand und schickt den anderen Nachrichten, wenn sie etwas wissen sollen. Man nennt das Message Passing, also Nachrichtenaustausch. Ein häufiger Irrtum ist übrigens, Sperren seien immer die sichere Wahl. Sperrt man ungeschickt, warten zwei Teile gegenseitig aufeinander und nichts geht mehr weiter; dieser Stillstand heißt Deadlock.
Von Web-Apps bis zu KI-Agenten
Im Alltag begegnet einem Shared State überall dort, wo mehrere Menschen dasselbe Dokument bearbeiten. Bei Google Docs oder Figma sehen alle Beteiligten denselben Text, und das System muss entscheiden, welche Änderung zuerst zählt. Dass dabei so selten etwas verloren geht, ist das Ergebnis jahrzehntelanger Forschung an genau diesem Problem.
In der Softwareentwicklung taucht der Begriff bei Frontend-Bibliotheken wie React auf. Dort ist der geteilte Zustand die zentrale Datenablage, aus der sich alle Bildschirmelemente bedienen. Ändert sich der Wert an einer Stelle, aktualisiert sich die Anzeige überall automatisch.
Aktuell liest man den Begriff besonders oft im Zusammenhang mit KI-Agenten. Mehrere solcher Programme arbeiten gemeinsam an einer Aufgabe und teilen sich dafür ein Gedächtnis: bisherige Zwischenergebnisse, gefundene Fakten, offene Teilaufgaben. Dieser gemeinsame Speicher ist Shared State im klassischen Sinn. Und er bringt dieselben alten Probleme mit, wenn zwei Agenten denselben Eintrag gleichzeitig überschreiben.