Thread dump in situazioni critiche – parte 8

thread-dump

Le scorse puntate:

Nei precedenti articoli abbiamo trattato dell’esame dell’heap dump in situazioni critiche. Ora ci concentreremo sull’esame del thread dump, esponendo anche un caso concreto di risoluzione di un problema di performance tramite l’utilizzo di questa tecnica effettuato all’interno del Laboratorio di Sme.UP.

Applicazioni multi-thread

La maggior parte delle applicazioni Java sviluppate oggi giorno coinvolgono thread (sottoprocessi) multipli. 

L’utilizzo di thread multipli permette di parallelizzare le attività e quindi di aumentare le performance di un sistema. E’ però necessario che il parallelismo sia correttamente gestito perchè l’accesso alle risorse comuni (ad esempio dati comuni, periferiche di input/output, etc…) deve essere coordinato. Ciò generalmente avviene ponendo un lock (blocco) sulla risorsa utilizzata da un thread, assicurando in questo modo che nessun altro thread possa accedervi finchè il thread bloccante non abbia concluso l’operazione sulla risorsa e rilasciato il blocco. 

Purtroppo il locking delle risorse può generare alcuni scenari spiacevoli, come ad esempio i deadlock e i livelock.

Un deadlock è uno scenario in cui i thread bloccano vicendevolmente le risorse tra loro generando uno stallo.

Un caso può essere quello di un thread X che sta usando e quindi bloccando una risorsa A ed è in attesa della disponibilità di una risorsa B e di un thread Y che sta usando e quindi bloccando la risorsa B ed è in attesa della disponibilità della risorsa A.

simple-deadlock

Clicca sull’immagine per ingrandirla.

simple-deadlock-01

Clicca sull’immagine per ingrandirla.

Il blocco può capitare anche con più di due thread coinvolti. Ad esempio quando il thread X sta usando la risorsa A e richiede la C, il thread Y sta usando la B e richiede la A e il thread Z sta usando la C e richiede la risorsa B. Un caso del genere è formalmente riconducibile al cosiddetto problema dei filosofi a cena, la cui formulazione originale definiva 5 thread (i filosofi) e 5 risorse (le forchette per mangiare). 

problema-filosofi-cena-02

Clicca sull’immagine per ingrandirla.

problema-filosofi-cena

Clicca sull’immagine per ingrandirla.

Un livelock è uno scenario in cui un thread X esegue un’azione A la quale comporta che il thread Y esegua un’azione B la quale comporta che il thread X esegua l’azione A. Questa situazione genera un ciclo infinito. Come nel caso dei deadlock i livelock generano uno stallo nell’applicazione, la quale non progredisce, ma a differenza dei deadlock i thread coinvolti non sono bloccati, ma lavorano senza fine.

livelock

Un’applicazione web Java EE, quale ad esempio Web.UP, è un’applicazione multi-thread. Essa viene infatti rilasciata su un application server. L’application server è un software che fornisce l’infrastruttura e le funzionalità di supporto per l’esecuzione di applicazioni in contesto distribuito. Al suo interno vengono gestiti numerosi thread, di controllo, di amministrazione e di gestione delle richieste e delle risposte http da e verso i client delle applicazioni web su di esso rilasciate (ad esempio i browser degli utenti).

L’application server consigliato per distribuire Web.UP è Payara, un application server open source derivato da Glassfish. Al suo interno gestisce un pool (insieme) di thread http, deputati all’esecuzione concorrente del codice dell’applicazione web.


Chiara Zambelli

Chiara Zambelli
Responsabile CI/CD – Gruppo Sme.UP
My LinkedIn Profile


Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *