A cura di Flavio Casadei Della Chiesa
Copyright (c) 2006 Flavio Casadei Della Chiesa. è garantito il permesso di copiare, distribuire e/o modificare questo documento seguendo i termini della Licenza per Documentazione Libera GNU, Versione 1.1 o ogni versione successiva pubblicata dalla Free Software Foundation.
Il Double Checked Locking Idiom è uno dei più subdoli Antipattern della programmazione concorrente in Java. A prima vista sembra un utile strumento per migliorare le performance, tuttavia sotto le regole dell'attuale Java Memory Model questo schema non funziona
public class DoubleCheckedLocking { private static Resource _instance public static Resource getInstance() { if (_instance == null) { synchronized (DoubleCheckedLocking.class) { if (_instance == null) _instance = new Resource(); } } } return _instance; } }
Inizializzare un oggetto comporta la scrittura di alcune variabili (stato dell'oggetto), pubblicare un oggetto riguarda la scrittura di altre variabili (il reference
). Se non si assicura che pubblicare l'oggetto accada prima che un Thread possa leggerne il reference
la scrittura del reference
può essere riordinata con le scritture dello stato dell'oggetto.
In tale caso un Thread può vedere un valore aggiornato per il reference
, ma un valore non aggiornato per alcune delle variabili che compongono lo stato dell'oggetto. Si ottiene quindi il reference
ad un oggetto parzialmente costruito.
Senza utilizzare tecniche troppo elaborate e spesso inutili è possibile risolvere il problema con il seguente codice
public class EagerInstantiation { private static final Resource _instance = new Resource(); public static Resource getResource() { return _instance; // :-) } }