Synchronized: Was es ist, Funktionsprinzip und Verwendung in Java

Was ist synchronized?

Synchronized ist ein Schlüsselwort in Java, das garantiert, dass nur ein Thread zu jeder Zeit einen geschützten Codeabschnitt ausführt und so Datenkorruption bei gleichzeitigem Zugriff verhindert. Es erschien in der ersten Version von Java und bleibt der einfachste Weg, um Threadsicherheit für Entwickler aller Erfahrungsstufen zu gewährleisten.

Definition und Rolle in Java

Der synchronized-Modifikator löst zwei Aufgaben: gegenseitigen Ausschluss (mutual exclusion) und Sichtbarkeit von Änderungen. Wenn ein Thread einen synchronized-Block verlässt, sind alle Änderungen für andere Threads sichtbar, die einen auf demselben Objekt synchronisierten Block betreten.

Synchronized kann auf eine gesamte Methode oder auf einen beliebigen Codeblock unter Angabe eines Monitor-Objekts angewendet werden. In beiden Fällen fügt die JVM auf Bytecode-Ebene monitorenter- und monitorexit-Anweisungen ein.

Gründe für die Entstehung

In Multithread-Anwendungen ohne Synchronisation tritt eine Race Condition auf, wenn zwei Threads gleichzeitig dieselben Daten ändern, was zu unvorhersehbaren Ergebnissen führt. Synchronized wurde zum ersten und wichtigsten Werkzeug von Java zur Bekämpfung dieses Problems und bietet eine einfache deklarative Syntax, die jedem Entwickler zugänglich ist.

Wie funktioniert synchronized?

Der synchronized-Mechanismus basiert auf dem Konzept des Monitors — einem hochwertigen Synchronisationsprimitiv, das in jedes Java-Objekt eingebaut ist. Der Monitor wird einem Objekt zugeordnet, wenn erstmals ein synchronized-Block darauf verwendet wird.

Objektmonitor

Jedes Objekt in Java hat einen zugehörigen Monitor. Wenn ein Thread in einen synchronized-Block eintritt, erwirbt er den Monitor des Objekts. Wenn der Monitor bereits von einem anderen Thread gehalten wird, blockiert der Thread, bis er freigegeben wird. Im Bytecode entspricht dies dem Paar von monitorenter- und monitorexit-Anweisungen.

Sperrzustände (Biased Locking)

Die JVM optimiert synchronized über mehrere Ebenen: Biased Locking für Single-Thread-Zugriff, Lightweight Locking für geringe Konkurrenz und Heavyweight Locking für intensive Konkurrenz unter Beteiligung des Betriebssystems. Diese Ebenen verbessern die Leistung ohne Codeänderung.

class Counter {
    private int count = 0;

    public synchronized void increment() {
        count++;
    }

    public synchronized int getCount() {
        return count;
    }
}

Happens-before-Regel

Synchronized stellt eine Happens-before-Beziehung her: Alle Aktionen in einem Thread vor dem Verlassen eines synchronized-Blocks sind für einen anderen Thread sichtbar, nachdem er einen auf demselben Objekt synchronisierten Block betreten hat. Dies garantiert nicht nur gegenseitigen Ausschluss, sondern auch Datenkonsistenz für alle Threads.

Synchronized-Methode vs. Block

Java bietet zwei Möglichkeiten, synchronized anzuwenden: auf Methodenebene und auf Blockebene. Die Wahl zwischen ihnen beeinflusst die Leistung und die Granularität der Synchronisation.

Synchronized-Methode

Das Markieren einer Methode mit dem synchronized-Modifikator synchronisiert sie automatisch auf der aktuellen Instanz (für Instanzmethoden) oder auf dem Class-Objekt (für statische Methoden). Dies ist der einfachste Weg, gegenseitigen Ausschluss zu gewährleisten, aber oft überzogen, wenn der kritische Abschnitt nur einen kleinen Teil der Methode ausmacht und der restliche Code keine Synchronisation benötigt.

Synchronized-Block

Ein synchronized-Block gibt präzise Kontrolle: Sie geben das Monitor-Objekt an und synchronisieren nur den notwendigen Codeabschnitt, während der Rest der Methode außerhalb der Sperre bleibt. Dies minimiert die Haltezeit des Monitors und verbessert die Gesamtleistung der Anwendung in einer Multithread-Umgebung, da andere Threads nicht auf die Freigabe des Monitors warten müssen, um nicht verwandten Code parallel auszuführen.

class DataProcessor {
    private final Object lock = new Object();

    public void process() {
        // Code außerhalb des kritischen Abschnitts - ohne Synchronisation
        prepareData()

        synchronized (lock) {
            // nur dieser Block ist geschützt
            updateSharedState()
        }

        // Fortsetzung ohne Sperre
        cleanup()
    }
}

Synchronized in Android

In der Android-Entwicklung wird synchronized häufig zum Schutz von SharedPreferences, Datenbankzugriffen und UI-Komponenten verwendet. Die Verwendung im Hauptthread wird jedoch aufgrund des Risikos von Einfrieren der Benutzeroberfläche dringend vermieden.

Verwendung mit SharedPreferences

SharedPreferences in Android bietet grundlegende Threadsicherheit, aber bei Bearbeitung durch mehrere Threads über den Editor kann eine externe Synchronisation erforderlich sein. Ein synchronized-Block mit einem separaten Sperrobjekt garantiert die Konsistenz der Änderungen.

class PreferencesManager(private val prefs: SharedPreferences) {
    private val lock = Any()

    fun writeToken(token: String) {
        synchronized (lock) {
            prefs.edit()
                .putString("auth_token", token)
                .apply()
        }
    }
}

Einschränkungen in Android-Anwendungen

Die Haupteinschränkung von synchronized auf Android ist die Thread-Blockierung. Im Gegensatz zu Coroutinen mit Mutex blockiert synchronized den gesamten Systemthread. Im Hauptthread verursacht dies ANR. In der modernen Android-Entwicklung wird empfohlen, synchronized durch Coroutinen (suspend Mutex) oder atomare Typen (AtomicInteger) zu ersetzen.

Alternativen zu synchronized

Modernes Java und Kotlin bieten mehrere Alternativen zu synchronized, die jeweils die gleichen Probleme mit weniger Einschränkungen oder besserer Leistung lösen.

Lock aus java.util.concurrent

Das Lock-Interface mit den Implementierungen ReentrantLock und ReadWriteLock bietet Timeouts, unterbrechbares Warten und mehrere Condition-Warteschlangen. Es ist flexibler als synchronized, erfordert aber explizite Freigabe in finally, was das Risiko von Fehlern bei vergessenem unlock erhöht.

Atomare Klassen

AtomicInteger, AtomicLong, AtomicReference und andere Klassen verwenden Lock-Free-Algorithmen auf Basis von CAS (Compare-And-Swap). Sie sind in Szenarien mit moderater Konkurrenz deutlich schneller als synchronized, da sie Threads nicht blockieren, sondern optimistische Wiederholungen ohne Kontextwechsel des OS-Kernels durchführen.

ThreadLocal und Threadsicherheit

ThreadLocal bietet einen alternativen Ansatz: Jede ThreadLocal-Variable ist innerhalb eines einzelnen Threads isoliert und erfordert keine Synchronisation für Lese- und Schreibzugriffe. Dies beseitigt vollständig die Notwendigkeit von synchronized für Daten, die nicht zwischen Threads geteilt werden sollen. ThreadLocal wird aktiv in Frameworks (Spring, Hibernate) zur Speicherung von Transaktionskontexten und Sitzungen verwendet.

Coroutinen und Compose-Ansatz

In Kotlin-Projekten für Android dient Mutex aus kotlinx.coroutines als Alternative zu synchronized. Es blockiert nicht den Betriebssystem-Thread, sondern setzt die Coroutine bis zur Freigabe der Sperre aus — dies ermöglicht eine effiziente Nutzung der Pool-Threads und vermeidet ANR bei langen Wartezeiten auf die Ressourcenfreigabe.

import kotlinx.coroutines.sync.Mutex
import kotlinx.coroutines.sync.withLock

val mutex = Mutex()
var counter = 0

suspend fun safeIncrement() {
    mutex.withLock {
        counter++
    }
}

Leistung von synchronized

Die Leistung von synchronized hat sich in den letzten Java-Versionen deutlich verändert. Früher galt es als „schwerer“ Mechanismus, aber moderne JVMs haben die meisten Gemeinkosten durch fortschrittliche JIT-Compiler-Optimierungen beseitigt. Sehen wir uns im Detail an, wie die virtuelle Maschine synchronisierten Code zur Laufzeit beschleunigt.

Biased Locking und Lock Coarsening

Der JIT-Compiler der JVM wendet mehrere Optimierungen an: Biased Locking eliminiert die Synchronisation, wenn die Sperre immer vom selben Thread erworben wird; Lock Coarsening fasst benachbarte synchronized-Blöcke zu einem zusammen; Lock Elimination entfernt die Synchronisation, wenn das Objekt nur von einem Thread zugänglich ist. Diese Optimierungen machen synchronized bei geringer Konkurrenz praktisch kostenlos.

Messung der Konkurrenz und Auswahl der Optimierung

Die JVM bestimmt den Konkurrenzgrad für jedes Objekt: Bei keiner Konkurrenz wird Biased Locking aktiviert; beim Auftreten eines zweiten Threads wechselt die Sperre in den Lightweight-Modus mit Spin-Warten; und nur bei längerem Warten eskaliert sie zu Heavyweight mit einem System-Mutex. Diese Eskalation erfolgt automatisch, und der Entwickler muss nicht manuell eine Strategie wählen.

Vergleich mit Lock und atomaren Klassen

In modernen Benchmarks (Java 17+) zeigt synchronized eine mit ReentrantLock vergleichbare Leistung bei niedriger und moderater Konkurrenz. Bei hoher Konkurrenz kann Lock dank einer effizienteren Warteschlange mit Timeout- und Interrupt-Unterstützung Vorteile haben. Für hochlastige Systeme mit konstanter Konkurrenz bietet ReentrantLock mit Fair-Mode ein vorhersehbareres Verhalten.

Atomare Klassen (AtomicInteger, AtomicReference) bleiben dank der Lock-Free-CAS-Implementierung die schnellsten für einfache Zähler und Flags. Sie blockieren Threads überhaupt nicht — bei Konflikten wiederholt die Operation einfach in einer Schleife. Dies ergibt einen 3- bis 5-fachen Leistungsgewinn im Vergleich zu synchronized bei Zählererhöhungsoperationen mit 4-8 Threads.