Uno degli elementi che piace di più ai giovani programmatori e a ai manager anziani riguardo a Java è il Garbage Collector: uno spazzino che arriva a liberare la memoria, che noi programmatori abbiamo allocato in modo automatico, trovando tutto ciò comodissimo.
Invito il lettore a parlare con qualsiasi sistemista che si occupi di monitorare l'occupazione di memoria della macchina e a chiedergli se anche lui (o lei) è d'accordo sulle meraviglie del Garbage Collector (GC).
Il GC è un'arma a doppio taglio, si tratta di un algoritmo complesso, che è una delle prime cause della lentezza di Java, inoltre è un invito per i programmatori per diventare pigri.
Ci sono casi infatti dove la disabitudine dei programmatori Java a occuparsi della memoria, dando fiducia completa al Garbage Collector, portano a dei memory leack.
Si possono individuare 3 casi dove il programmatore Java deve prestare attenzione, per non rendere impossibile il lavoro del GC.
1) Raggiungere l'insufficienza di memoria tramite la ritenzione non intenzionale di oggetti. Se si ritengono dei riferimenti a degli oggetti, per esempio in un vettore o in uno stack dove si desidera rimpicciolire la dimensione della struttura e non si pone a null il valore degli elementi rimasti fuori dal limite abbassato, succede che tali riferimenti impediranno al Garbage Collector di liberare la memoria degli oggetti riferiti.
2) Le cache devono liberare gli elementi più vecchi. E' comune tenere in cache dei riferimenti a degli oggetti in cache e dimenticarsi poi di togliere tali riferimenti, quando questi non sono più usati da tanto tempo. Una buona struttura per realizzare una cache in Java è il WeakHashMap. Nel caso invece dove si scelga una LinkedHashMap, esiste un metodo molto interessante: removeEldestEntry che toglie l'elemento più vecchio, magari si può realizzare un Timer o uno ScheduledThreadPoolExecutor che periodicamente lo chiama per pulire la cache degli elementi più vecchi.
3) I listener sono spesso usati per le applicazioni desktop. Richiedono molta attenzione perché i listener vanno tolti dalla lista dei listener registrati, quando non servono più, perché troppo spesso i listener rimangono e cresce il numero di riferimenti a oggetti, compromettendo l'occupazione efficiente della memoria.
Questi punti si trovano descritti sempre nell'ottimo Effective Java di Joshua Bloch.
Nessun commento:
Posta un commento