Lezioni

Questa lezione parla di che cos’è una risorsa condivisa nelle applicazioni multithread, perché si verificano le race condition e gli «aggiornamenti persi», e come proteggere i dati con synchronized. Vedremo le tecniche di base di sincronizzazione (metodi e blocchi), parleremo degli strumenti moderni di java.util.concurrent ( Lock, ReentrantLock, Semaphore e altri), vedremo esempi pratici con l’incremento di un contatore e gli errori tipici (non atomicità di i ++, oggetto di lock errato, miti su volatile).

Lezione pratica sulla multithreading: analizziamo come funziona la parola chiave synchronized (blocchi e metodi, monitor dell’oggetto e blocco a livello di classe ClassName.class), in cosa la visibilità delle modifiche tramite volatile differisce dall’atomicità delle operazioni, perché è comodo rendere volatile i flag boolean, mentre l’incremento count ++ richiede la sincronizzazione. Confronteremo quando scegliere synchronized e quando — volatile, e analizzeremo gli errori tipici.

Confronto pratico tra la sincronizzazione classica tramite synchronized e primitive più flessibili del pacchetto java.util.concurrent.locks: ReentrantLock e ReadWriteLock. Vedremo come gestire in modo esplicito i lock ( lock()/ unlock(), tryLock() con timeout), come scalare le letture con ReentrantReadWriteLock, che cos’è la fairness ( fair mode), dove ciascuno strumento è appropriato e quali errori si incontrano più spesso.

In questa lezione analizziamo i principali primitivi di sincronizzazione in Java: come proteggere le sezioni critiche con synchronized e la classe ReentrantLock (metodi lock()/ unlock(), costrutto try- finally), e come limitare il parallelismo tramite Semaphore (metodi acquire()/ release()). Confronteremo mutex e semaforo in una tabella, vedremo casi pratici (banca, server con limite di connessioni) ed errori tipici che portano a deadlock e perdite di prestazioni.

Analisi pratica degli errori frequenti del multithreading in Java: unlock()/ release() dimenticato con ReentrantLock e Semaphore (si risolve con try- finally), scelta del monitor sbagliato per synchronized, deadlock e ordine di acquisizione dei lock, sincronizzazione eccessiva, nonché limiti di applicabilità di volatile e sostituzione con AtomicInteger. Esempi, consigli e analogie comprensibili — in modo che il codice non si blocchi.