Synchronized: ce este, principiul de funcționare și utilizare în Java

Ce este synchronized?

Synchronized este un cuvânt cheie în Java care garantează că un singur fir de execuție rulează simultan porțiunea protejată de cod, prevenind deteriorarea datelor la accesul paralel. A apărut în prima versiune Java și rămâne cea mai simplă modalitate de a asigura siguranța firelor de execuție pentru dezvoltatori de orice nivel.

Definiție și rol în Java

Modificatorul synchronized rezolvă două sarcini: excluderea mutuală (mutual exclusion) și vizibilitatea modificărilor (visibility). Când un fir de execuție iese dintr-un bloc synchronized, toate modificările sunt garantat vizibile pentru alte fire care intră în blocul sincronizat pe același obiect.

Synchronized poate fi aplicat întregii metode sau unui bloc de cod arbitrar cu specificarea obiectului-monitor. În ambele cazuri, JVM inserează instrucțiunile monitorenter și monitorexit la nivel de bytecode.

Premisele apariției

În aplicațiile multi-thread fără sincronizare apare starea de cursă (race condition) — când două fire modifică simultan aceleași date, ducând la rezultate imprevizibile. Synchronized a devenit primul și principalul instrument Java pentru combaterea acestei probleme, oferind o sintaxă declarativă simplă, accesibilă oricărui dezvoltator.

Cum funcționează synchronized?

Mecanismul synchronized se bazează pe conceptul de monitor — un primitiv de sincronizare de nivel înalt încorporat în fiecare obiect Java. Monitorul este asociat cu obiectul la prima utilizare a unui bloc synchronized pe acesta.

Monitorul obiectului

Fiecare obiect în Java are un monitor asociat. Când un fir de execuție intră într-un bloc synchronized, acesta preia monitorul obiectului. Dacă monitorul este deja ocupat de un alt fir, firul este blocat până la eliberare. În bytecode, acestuia îi corespunde perechea de instrucțiuni monitorenter și monitorexit.

Stări de blocare (biased locking)

JVM optimizează synchronized prin mai multe niveluri: biased locking (blocare înclinată) pentru acces single-thread, lightweight locking (blocare ușoară) la concurență scăzută și heavyweight locking (blocare grea) la concurență intensă cu participarea OS. Aceste niveluri măresc performanța fără a modifica codul.

class Counter {
    private int count = 0;

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

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

Regula happens-before

Synchronized stabilește relația happens-before: toate acțiunile dintr-un fir înainte de ieșirea dintr-un bloc synchronized sunt vizibile pentru un alt fir după intrarea în blocul sincronizat pe același obiect. Aceasta garantează nu doar excluderea mutuală, ci și consistența datelor pentru toate firele.

Metoda synchronized vs bloc

Java oferă două moduri de aplicare a synchronized: la nivel de metodă și la nivel de bloc. Alegerea între ele influențează performanța și granularitatea sincronizării.

Metoda synchronized

Marcând o metodă cu modificatorul synchronized, o sincronizați automat pe instanța curentă (pentru metoda obișnuită) sau pe obiectul Class (pentru metoda statică). Este cel mai simplu mod de a asigura excluderea mutuală, dar adesea este excesiv dacă secțiunea critică constituie doar o mică parte a metodei, iar restul codului nu necesită sincronizare.

Blocul synchronized

Blocul synchronized oferă control precis: specificați obiectul-monitor și sincronizați doar porțiunea necesară de cod, lăsând restul metodei în afara blocării. Aceasta minimizează timpul de deținere a monitorului și crește performanța generală a aplicației în medii multi-thread, deoarece alte fire pot executa paralel cod neînrudit fără a aștepta eliberarea monitorului.

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

    public void process() {
        // codul în afara secțiunii critice - fără sincronizare
        prepareData()

        synchronized (lock) {
            // doar acest bloc este protejat
            updateSharedState()
        }

        // continuare fără blocare
        cleanup()
    }
}

Synchronized în Android

În dezvoltarea Android, synchronized este utilizat pe scară largă pentru protejarea SharedPreferences, accesul la baza de date și componentele UI. Cu toate acestea, utilizarea sa pe firul principal este categoric nerecomandată din cauza riscului de înghețare a interfeței.

Utilizarea cu SharedPreferences

SharedPreferences în Android asigură siguranța firelor de bază, dar la editarea de către mai multe fire prin Editor poate fi necesară sincronizarea externă. Blocul synchronized cu un obiect de blocare separat garantează consistența modificărilor.

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

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

Limitări în aplicațiile Android

Principala limitare a synchronized pe Android — blocarea firului. Spre deosebire de corutine cu Mutex, synchronized blochează întregul fir de sistem. Pe firul principal, aceasta provoacă ANR. În dezvoltarea modernă Android, se recomandă înlocuirea synchronized cu corutine (suspend Mutex) sau tipuri atomice (AtomicInteger).

Alternative la synchronized

Java și Kotlin moderne oferă mai multe alternative la synchronized, fiecare rezolvând aceleași sarcini cu mai puține limitări sau performanță mai bună.

Lock din java.util.concurrent

Interfața Lock cu implementările ReentrantLock și ReadWriteLock oferă timeouturi, așteptare întreruptibilă și multiple cozi Condition. Este mai flexibilă decât synchronized, dar necesită eliberarea explicită în finally, ceea ce crește riscul de eroare la un unlock uitat.

Clase atomice

Clasele AtomicInteger, AtomicLong, AtomicReference și altele utilizează algoritmi Lock-Free bazați pe CAS (Compare-And-Swap). Ele sunt semnificativ mai rapide decât synchronized în scenarii cu concurență moderată, deoarece nu blochează firele, ci execută încercări repetate optimiste și nu necesită comutare de context de către nucleul OS.

ThreadLocal și siguranța firelor

ThreadLocal oferă o abordare alternativă: fiecare variabilă ThreadLocal este izolată în cadrul unui singur fir și nu necesită sincronizare pentru citire și scriere. Aceasta elimină complet necesitatea synchronized pentru datele care nu trebuie partajate între fire. ThreadLocal este utilizat activ în frameworkuri (Spring, Hibernate) pentru stocarea contextului tranzacțiilor și sesiunilor.

Corutine și abordarea compose

În proiectele Kotlin pentru Android, alternativa la synchronized este Mutex din kotlinx.coroutines. Acesta nu blochează firul sistemului de operare, ci suspendă corutina până la eliberarea blocării — aceasta permite utilizarea eficientă a firelor din pool și evitarea ANR la așteptarea îndelungată pentru eliberarea resursei.

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

val mutex = Mutex()
var counter = 0

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

Performanța synchronized

Performanța synchronized s-a schimbat semnificativ în versiunile recente Java. Anterior era considerat un mecanism „grea„ dar JVM-urile moderne au eliminat majoritatea supraîncărcărilor datorită optimizărilor avansate ale compilatorului JIT. Să analizăm detaliat cum mașina virtuală accelerează codul sincronizat în runtime.

Biased Locking și Lock Coarsening

Compilatorul JIT al JVM aplică mai multe optimizări: biased locking elimină sincronizarea dacă blocarea este întotdeauna preluată de un singur fir; lock coarsening îmbină blocurile synchronized vecine într-unul singur; lock elimination elimină sincronizarea dacă obiectul este accesibil doar unui singur fir. Aceste optimizări fac synchronized practic gratuit la concurență scăzută.

Măsurarea concurenței și alegerea optimizării

JVM determină nivelul de concurență pentru fiecare obiect: la absența concurenței se activează biased locking, la apariția celui de-al doilea fir blocarea trece în modul lightweight cu spin-waiting și doar la așteptare prelungită — în heavyweight cu mutex de sistem. Această escaladare are loc automat, iar dezvoltatorul nu trebuie să aleagă manual strategia.

Comparația cu Lock și clasele atomice

În benchmarkurile moderne (Java 17+) synchronized arată performanță comparabilă cu ReentrantLock la concurență scăzută și moderată. La concurență ridicată, Lock poate avea avantaj datorită cozii de așteptare mai eficiente cu suport pentru timeouturi și întreruperi. Pentru sistemele cu încărcare mare unde concurența este constantă, ReentrantLock în modul fair oferă un comportament mai predictibil.

Clasele atomice (AtomicInteger, AtomicReference) rămân cele mai rapide pentru contoare și flaguri simple datorită implementării Lock-Free pe CAS. Ele nu blochează deloc firele — la conflict, operația este pur și simplu repetată în buclă. Aceasta oferă o creștere a performanței de 3-5 ori comparativ cu synchronized la operații de incrementare a contorului pe 4-8 fire.