In Java la presenza del Garbage Collector (abbreviato GC) ha permesso di sollevare il programmatore dall’onere della gestione di dettaglio della memoria, abbattendo drasticamente gli errori, comuni invece in linguaggi come C++, causati da una gestione errata della de-allocazione degli oggetti. Ciò al contempo ha portato a confidare eccessivamente nelle capacità del Garbage Collector, portando spesso a pensare che questo strumento sia in grado di sollevare completamente il programmatore dalla gestione della memoria.
Ovviamente ciò non è vero e il programmatore deve tener presente che il Garbage Collector opera al massimo delle sue possibilità, ma non è sempre possibile prevenire abusi della memoria. In aggiunta, le scelte progettuali che hanno portato alla realizzazione della JVM definiscono vincoli che, qualora non rispettati, possono generare a loro volta ulteriori problemi.
In generale, un memory leak (perdita di memoria) è il risultato di un consumo non voluto di memoria derivante da una mancata de-allocazione di oggetti, variabili o dati non più necessari. Le conseguenze possono essere diverse, non sempre evidenti né immediate e spesso si manifestano con improvvisi crash dei sistemi coinvolti. Ma anche se non si arriva al crash dell’eseguibile, gli effetti collaterali (consumo anomalo di risorse) possono portare a rendere inutilizzabile l’applicazione afflitta, e con essa i sistemi da cui dipende.
A tutto ciò si aggiunga un ulteriore problema. Una volta che si è concluso che vi è un memory leak, isolarlo può non essere semplice. Le analisi statiche spesso non riescono a identificare riferimenti ridondanti o a evidenziare anomalie. E l’analisi dinamica a sua volta può essere inficiata dalla generazione di risultati anche troppo dettagliati, difficili da interpretare e che non riescono a porre in evidenza la natura del problema.
In questa guida descriveremo come Java gestisce la memoria, come agisce il Garbage Collector e i principali sintomi che ci possono portare a riconoscere un memory leak prima che si manifesti con la classica eccezione OutOfMemoryError. Vedremo che ci sono diversi tipi di problemi che possono affliggere la memoria e che, sebbene accomunati da sintomi simili, cause e soluzioni possono essere diverse. Seguirà un approfondimento sulla JConsole, strumento di diagnostica largamente diffuso che possiamo trovare nella JDK (dalla version 1.5 in poi) utile tra l’altro per un’analisi visuale dell’andamento dell’occupazione della memoria.
Descriveremo quindi un ulteriore strumento di analisi della memoria heap per l'IDE Eclipse, il MAT, Eclipse Memory Analyzer. E’ uno strumento Open Source di analisi dell’heap in grado di essere eseguito come programma standalone o come plugin per l’IDE, un progetto sostenuto da IBM e SAP. Tra gli scopi che si prefigge, la capacità di individuare memory leak e assistere l’utente nel migliorare la gestione della memoria. Mostreremo un esempio programmatico soggetto a memory leak, verificandone l’impatto sull’heap e mostrando infine come il MAT possa portarci a isolare dove si trovi il problema.