Installazione
E’ possibile utilizzare il Memory Analyzer Tool sia in modalità standalone che installandolo su un IDE Eclipse.
L’applicativo standalone è basato su Eclipse RCP (Rich Client Platform), utile per effettuare le analisi senza modificare l’ambiente di sviluppo o per eseguirle nei contesti più disparati. Per essere utilizzato esso richiede la presenza della JVM, dalla 1.6 in poi.
Per l’applicazione standalone, è possibile visitare il sito eclipse, da dove scaricare la versione per il sistema utilizzato.
Per installare su un IDE eclipse, bisognerà recarsi su "Help/Install New Software…/Work with:" e poi premere sul pulsante "Add…" e inserire il seguente URL (versione 1.4):
http://download.eclipse.org/mat/1.4/update-site/
Fatto questo, si potrà dare un nome al collegamento (ad esempio "Mat"), premere su "Ok" e selezionare la voce appena memorizzata. Verranno visualizzate le versioni scaricabili, sia la standalone che il plugin per l’IDE. Selezionato quest'ultimo, potremo selezionare la versione base ("Memory Ananlyzer"), e un’estensione opzionale, Charts. Quest’ultima feature consente di utilizzare BIRT nelle analisi sul consumo di memoria, un progetto Open Source ospitato su Eclipse che fornisce una piattaforma per visualizzazione reports di dati.
Si tratta di una funzionalità opzionale che per essere installata richiede la presenza di BIRT nell’IDE. Nell’immagine seguente si sta procedendo all’installazione senza richiedere l’estensione opzionale che è comunque già presente nella versione standalone di MAT.
A questo punto premendo su "next" si potrà completare l’installazione (verrà richiesto di accettare i termini della licenza e di riavviare l’IDE). Una volta riavviato, tra le prospettive accessibili (pulsante "Open Perspective") troveremo anche la voce "Memory Analysis" che ci confermerà l’avvenuta installazione del plugin.
Primi passi
In primo luogo uno sguardo d’insieme all’editor aperto: nella versione "plugin" troveremo nel menu della barra superiore tutte le voci caratteristiche dell’IDE, oltre che quelle proprie del MAT raffigurate nell’immagine seguente. A parte questo, la versione standalone e il plugin non presentano differenze di rilievo. Di seguito si riporta una vista dello standalone una volta saltata la schermata introduttiva (pulsante "Workbench").
Sulla destra l’area di lavoro ove verranno presentate le schede relative ai dumps e dove verranno presentati i relativi report. Sulla sinistra poniamo l’attenzione sulla scheda "Inspector", il cui scopo è fornire informazioni statistiche e non sulle classi o sugli oggetti correntemente selezionati. Nel caso in cui la scheda non fosse visibile, si potrà andare su "Window > Show view > Inspector"; altra scheda utile è la "Navigation History", se non visibile ci si potrà recare su "Window > Show view > Navigation History".
In questa scheda troviamo l’elenco dei report effettuati, gli istogrammi visualizzati, le query eseguite, in modo da potervi facilmente accedere o rieseguire in seguito.
Il Memory Analyzer lavora su formati binari hprof, possiamo pertanto procedere ad analizzare il dump della memoria heap precedentemente creato tramite JConsole attreverso "File > Open Heap Dump" e selezionare il file dove si è salvato il dump precedentemente effettuato.
Il MAT procederà al parsing del dump selezionato, creando degli oggetti di sistema nella cartella dove è salvato il dump stesso, per poi procedere al calcolo del Dominator Tree. E’ un’operazione che può richiedere anche qualche minuto, se eseguita su dump di grosse dimensioni. Al termine dell’apertura del dump, comparirà una wizard come di seguito, dove ci verrà chiesto se vogliamo avviare la ricerca di leak sospetti, avere un report sui componenti o riaprire un report creato in precedenza. L’analisi dei leak sospetti viene eseguita sulla base degli anti-patterns comunemente utilizzati riguardanti la memoria.
L’immagine mostrata lascia intravedere l’overview ottenuta dal dump. In particolare, poiché nell’IDE non è presente BIRT, non verrà visualizzato il grafo a torta che riassume i principali oggetti che occupano la memoria (secondo il principio del retained size). Nella seguente immagine mostriamo l’overview prodotta dallo standalone nel quale è già incluso di default BIRT.
Il grafico presente nell’overview ci preannuncia quanto descritto dall’analisi dei leaks sospetti. La scheda che si apre in seguito a questa analisi ci fornisce una lista di problemi sospetti. Nel nostro caso ne abbiamo uno, un thread che da solo sta occupando oltre il 99% della memoria. Dalla scheda sul problema sospetto è possibile accedere ad ulteriori informazioni (link See stacktrace), come visibile nell’immagine seguente.
Nell’immagine precedente si notano due menu aperti. Dalla prima otteniamo il percorso fino al punto di accumulo, mentre nella seconda osserviamo la percentuale di risorse di memoria allocate. Dall’analisi effettuata possiamo semplicemente arrivare a concludere che vi è un accumulo di oggetti di tipo memoryleak.data.ElencoPersone nell’ArrayList "elenchiPersone", lista contenuta negli oggetti istanze della classe memoryleak.test.ElaborazioneElencoPersone. Il problema è evidente, un accumulo intensivo di oggetti in una lista. Inoltre, tramite le informazioni ottenibili nella scheda "Inspector" è possibile, partendo dai percorsi più brevi e risalendo fino ai punti di accumulazione, individuare un oggetto e ispezionarne i valori degli attributi, o risalire la catena dei riferimenti.
Identificato dov’è l’accumulo, non dovrebbe essere complicato stabilirne le cause e definire un piano d’azione.
Come anticipato, è un caso elementare e sapevamo in partenza dove si annidava l’errore. Ma i sistemi coinvolti nell’analisi possono essere notevolmente complessi e i punti d’accumulo è facile che sfuggano all’ispezione diretta del codice, in modo particolare se posizionati in aree di utilizzo poco frequente o dalla finalità non evidente. Automatizzare la ricerca dei punti d’accumulo può permettere di risolvere simili problemi in tempi rapidi, evitando o riducendo la necessità di monitorare l’applicazione per lunghi tempi e con tester creati appositamente.
La ricerca per anti-patterns infatti è in grado di individuare non solo gli accumuli già in atto, ma anche le potenziali fonti di problemi. Integrando pertanto l’utilizzo dello strumento nella fase di sviluppo, sarà possibile ridurre l’esposizione delle applicazioni realizzate ai memory leak.
Possiamo rieseguire l’analisi (o eseguirla la prima volta se si è aperto il dump saltandola) dalla scheda Overview, lanciabile dalla sezione "reports". Notiamo infine che le analisi eseguite possono essere esportate dall’editor mediante il pulsante "Export", scegliendo tra i formati HTML, CSV e TXT.