Thema der Woche: Double-checked locking

Lies http://www.ibm.com/developerworks/java/library/j-dcl.html und erkläre, wo es genau bei

public static Singleton getInstance()
{
  if (instance == null)
  {
    synchronized(Singleton.class) {  //1
      if (instance == null)          //2
        instance = new Singleton();  //3
    }
  }
  return instance;

}

zu einem Problem bei nebenläufigen Threads kommen kann. Warum funktioniert es auch bei 2 synch. Blöcken nicht? Was hat das dem Memory-Modell zu tun?

Hinweis: Es geht nicht darum, ein Singleton korrekt zu implementieren, sondern das Java Memory Modell zu verstehen und Probleme aufzudecken, die sich aus der Nebenläufigkeit ergeben.

Ähnliche Beiträge

3 Gedanken zu “Thema der Woche: Double-checked locking

  1. Seit Java 5 ist das »Double-checked locking« einfach nicht mehr die beste Möglichkeit, ein sicheres Singelton zu realisieren – am sichersten (und mit dem geringsten Schreibaufwand) ist der Weg über ein Enum. Diese Idee sieht auf den ersten Blick zwar etwas merkwürdig (bzw. zweckentfremdet) aus, ist aber auch lt. »Effectice Java« die beste Möglichkeit.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert