Synchronized: co to je, princip činnosti a použití v Java

Co je synchronized?

Synchronized je klíčové slovo v Java, které zaručuje, že pouze jedno vlákno současně spouští chráněnou část kódu, čímž zabraňuje poškození dat při paralelním přístupu. Objevilo se v první verzi Java a zůstává nejjednodušším způsobem zajištění bezpečnosti vláken pro vývojáře všech úrovní.

Definice a role v Java

Modifikátor synchronized řeší dva úkoly: vzájemné vyloučení (mutual exclusion) a viditelnost změn (visibility). Když vlákno opustí synchronized blok, všechny změny jsou zaručeně viditelné pro další vlákna vstupující do bloku synchronizovaného na stejném objektu.

Synchronized lze aplikovat na celou metodu nebo na libovolný blok kódu s určením monitorovacího objektu. V obou případech JVM vkládá instrukce monitorenter a monitorexit na úrovni bytekódu.

Důvody vzniku

Ve vícevláknových aplikacích bez synchronizace vzniká závitové prohledávání (race condition) — když dvě vlákna současně mění stejná data, což vede k nepředvídatelným výsledkům. Synchronized se stal prvním a hlavním nástrojem Java pro boj s tímto problémem, poskytující jednoduchou deklarativní syntaxi přístupnou každému vývojáři.

Jak synchronized funguje?

Mechanismus synchronized je založen na konceptu monitoru — vysokoúrovňového synchronizačního primitivu vestavěného do každého objektu Java. Monitor je k objektu připojen při prvním použití synchronized bloku na něm.

Monitor objektu

Každý objekt v Java má přidružený monitor. Když vlákno vstoupí do synchronized bloku, převezme monitor objektu. Pokud je monitor již obsazen jiným vláknem, vlákno je blokováno do uvolnění. V bytekódu tomu odpovídá dvojice instrukcí monitorenter a monitorexit.

Stavy zámku (biased locking)

JVM optimalizuje synchronized prostřednictvím několika úrovní: biased locking (předpojaté zamykání) pro jednovláknový přístup, lightweight locking (lehlé zamykání) při nízké konkurenci a heavyweight locking (těžké zamykání) při intenzivní konkurenci s účastí OS. Tyto úrovně zvyšují výkon bez změny kódu.

class Counter {
    private int count = 0;

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

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

Pravidlo happens-before

Synchronized vytváří vztah happens-before: všechny akce ve vlákně před opuštěním synchronized bloku jsou viditelné pro jiné vlákno po vstupu do bloku synchronizovaného na stejném objektu. To zaručuje nejen vzájemné vyloučení, ale také konzistenci dat pro všechna vlákna.

Synchronized metoda vs blok

Java nabízí dva způsoby aplikace synchronized: na úrovni metody a na úrovni bloku. Volba mezi nimi ovlivňuje výkon a granularitu synchronizace.

Synchronized metoda

Označením metody modifikátorem synchronized ji automaticky synchronizujete na aktuální instanci (pro běžnou metodu) nebo na objektu Class (pro statickou metodu). To je nejjednodušší způsob zajištění vzájemného vyloučení, ale často je nadbytečný, pokud kritická sekce tvoří pouze malou část metody a zbytek kódu nevyžaduje synchronizaci.

Synchronized blok

Synchronized blok poskytuje přesnou kontrolu: určíte monitorovací objekt a synchronizujete pouze potřebnou část kódu, přičemž zbytek metody zůstává mimo zámek. To minimalizuje dobu držení monitoru a zvyšuje celkový výkon aplikace ve vícevláknovém prostředí, protože ostatní vlákna mohou paralelně spouštět nesouvisející kód bez čekání na uvolnění monitoru.

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

    public void process() {
        // kód mimo kritickou sekci - bez synchronizace
        prepareData()

        synchronized (lock) {
            // pouze tento blok je chráněn
            updateSharedState()
        }

        // pokračování bez zámku
        cleanup()
    }
}

Synchronized v Android

Při vývoji pro Android se synchronized široce používá k ochraně SharedPreferences, přístupu k databázi a komponent UI. Jeho použití na hlavním vlákně se však kategoricky nedoporučuje kvůli riziku zamrznutí rozhraní.

Použití s SharedPreferences

SharedPreferences v Android poskytuje základní bezpečnost vláken, ale při úpravě více vlákny přes Editor může být vyžadována externí synchronizace. Synchronized blok s odděleným objektem zámku zaručuje konzistenci změn.

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

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

Omezení v aplikacích pro Android

Hlavní omezení synchronized na Android — blokování vlákna. Na rozdíl od coroutin s Mutex, synchronized blokuje celé systémové vlákno. Na hlavním vlákně to způsobuje ANR. V moderním vývoji pro Android se doporučuje nahradit synchronized coroutinami (suspend Mutex) nebo atomickými typy (AtomicInteger).

Alternativy k synchronized

Moderní Java a Kotlin nabízejí několik alternativ k synchronized, z nichž každá řeší stejné úkoly s menším počtem omezení nebo lepším výkonem.

Lock z java.util.concurrent

Rozhraní Lock s implementacemi ReentrantLock a ReadWriteLock poskytuje časové limity, přerušitelné čekání a několik front Condition. Je flexibilnější než synchronized, ale vyžaduje explicitní uvolnění v finally, což zvyšuje riziko chyby při zapomenutém unlock.

Atomické třídy

Třídy AtomicInteger, AtomicLong, AtomicReference a další používají Lock-Free algoritmy založené na CAS (Compare-And-Swap). Jsou výrazně rychlejší než synchronized ve scénářích s mírnou konkurencí, protože neblokují vlákna, ale provádějí optimistické opakované pokusy a nevyžadují přepínání kontextu jádrem OS.

ThreadLocal a bezpečnost vláken

ThreadLocal poskytuje alternativní přístup: každá proměnná ThreadLocal je izolována v rámci jednoho vlákna a nevyžaduje synchronizaci pro čtení a zápis. To zcela eliminuje potřebu synchronized pro data, která by neměla být sdílena mezi vlákny. ThreadLocal je aktivně používán v rámcích (Spring, Hibernate) pro ukládání kontextu transakcí a relací.

Coroutiny a přístup compose

V Kotlin projektech pro Android je alternativou k synchronized Mutex z kotlinx.coroutines. Neblokuje vlákno operačního systému, ale pozastaví coroutinu do uvolnění zámku — to umožňuje efektivní využití vláken z poolu a vyhnutí se ANR při dlouhém čekání na uvolnění prostředku.

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

val mutex = Mutex()
var counter = 0

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

Výkon synchronized

Výkon synchronized se v posledních verzích Java výrazně změnil. Dříve byl považován za „těžký„ mechanismus, ale moderní JVM odstranily většinu režie díky pokročilým optimalizacím JIT kompilátoru. Pojďme se podrobně podívat, jak virtuální stroj urychluje synchronizovaný kód za běhu.

Biased Locking a Lock Coarsening

JIT kompilátor JVM aplikuje několik optimalizací: biased locking eliminuje synchronizaci, pokud zámek vždy přebírá jedno vlákno; lock coarsening spojuje sousední synchronized bloky do jednoho; lock elimination odstraňuje synchronizaci, pokud je objekt přístupný pouze jednomu vláknu. Tyto optimalizace činí synchronized prakticky bezplatným při nízké konkurenci.

Měření konkurence a výběr optimalizace

JVM určuje úroveň konkurence pro každý objekt: při nepřítomnosti konkurence se aktivuje biased locking, při objevení druhého vlákna přechází zámek do režimu lightweight se spin-čekáním a teprve při dlouhém čekání — do heavyweight se systémovým mutexem. Tato eskalace probíhá automaticky a vývojář nemusí ručně vybírat strategii.

Srovnání s Lock a atomickými třídami

V moderních benchmarkách (Java 17+) vykazuje synchronized výkon srovnatelný s ReentrantLock při nízké a střední konkurenci. Při vysoké konkurenci může mít Lock výhodu díky efektivnější frontě čekání s podporou timeoutů a přerušení. Pro vysoce zatížené systémy, kde je konkurence konstantní, poskytuje ReentrantLock v režimu fair předvídatelnější chování.

Atomické třídy (AtomicInteger, AtomicReference) zůstávají nejrychlejší pro jednoduché čítače a příznaky díky Lock-Free implementaci na CAS. Vůbec neblokují vlákna — při konfliktu se operace jednoduše opakuje ve smyčce. To poskytuje 3-5násobné zvýšení výkonu ve srovnání se synchronized u operací inkrementace čítače na 4-8 vláknech.