Verständnis "synchronized"

[Marcel_Handball]

Hey,

folgende Situation:

class Main{

     static int i;

     public synchronized void foo(){
          i++;
     }
}

Ich arbeite gerade nochmal die Insel durch und hänge mich an einer Formulierung auf.

Bei einem Konflikt (mehrere Threads rufen foo() auf) verhindert synchronized, dass sich mehr als ein Thread gleichzeitig im kritischen Abschnitt, dem Rumpf der Funktion foo(), befinden kann. Dies bezieht sich nur auf mehrere Aufrufe von foo() für dasselbe Objekt. Zwei verschiedene Threads können durchaus parallel die Funktion foo() für unterschiedliche Objekte ausführen.

Wenn nun zwei Threads die Methode auf zwei unterschiedliche Objekte parallel aufrufen können (Objektmethode mit Zugriff auf statische Variable), wie wird dann i behandelt, dass sich beide Objekte teilen?

 

[Spacerat]

So hat "synchronized" hier natürlich keinen Sinn, da es sich so nur auf die Objekt-Instanz bezieht. Es müsste sich auf die gesammte Klasse beziehen. Etwa so:

public void foo()
{
    synchronized (getClass()) {
        i++;
    }
}

 

[Marco13]

Und um die Frage nach dem i zu beantworten: Das ist "Zufall". Es kann also sein, dass i am Anfang 0 ist, und dann zwei Threads diese Methode aufrufen, und i danach trotzdem nicht 2 sondern nur 1 ist.

 

[Wildcard]

In so einem Fall IMO besser noch AtomicInteger als synchronized

 

[fjord]

Bei Variablen die von mehreren Threads genutzt werden ist auch nicht sichergestellt, dass alle dieselbe Version der Variablen sehen. Das Schlüsselwort mit dem man das sicherstellen kann ist volatile. Dabei muss man aber immernoch beachten, dass i++ keine atomare Operation ist. Bei ungünstigem Sheduling kann es also passieren, dass ein Inkrement verloren geht.
Ich würde dir da also auch wie Wildcard zu AtomicInteger raten.