Le scorse puntate:
- Introduzione ai performance monitoring tool – parte 1
- Esempio di un APM open source per un’app web Java J2EE: Glowroot – parte 2
- Glowroot – Profilazione e transazioni web – parte 3
- Glowroot Slow traces – parte 4
- Glowroot: monitoring della JVM – parte 5
- Heap dump in situazioni critiche – parte 6
- Un caso reale di memory leak – parte 7
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 smeup.
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.
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).
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.
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
Responsabile CI/CD – smeup
My LinkedIn Profile
Naviga per categoria:
Seleziona una categoria d’interesse dal nostro magazine
