Frage zu Thread

[nightmare]

Hallo,

sind die beiden Code Teile unten vom Prinzip her gleich oder gibt es Unterschiede?

1.

public void shoot(){
synchronized(this){
...
}
}

2.

public void synchroized shoot{
...
}

 

[eRaaaa]

Es gibt Unterschiede
Synchronized Methods (The Java™ Tutorials > Essential Classes > Concurrency)

/edit: Gehts hier wirklich nur um den Code oder Allgemein?

 

[Murray]

Von den Syntaxfehlern in der zweiten Variante mal abgesehen sind beide Lösungen äquivalent.

 

[nightmare]

ich meine allgemein(d.h. obs sinngemäß dasselbe ist)

 

[dunhillone]

Nein.. wenn du synchronized auf Methodenebene anwendest ist die ganze Methode synchronized. Ansonsten nur der synchronized block.

Dies kann sich stark auf die performance auswirken...

Hier ein beispiel eines singleton:

	private static Object instance = null;
	public static Object getInstance() {
		if(instance == null) {
			synchronized (instance) {
				if(instance == null) {
					instance = new Object();
				}
			}
		}
		return instance;
	}

ist performanter als

	private static Object instance = null;
	public static synchronized  Object getInstance() {
		if(instance == null) {
			instance = new Object();							
		}
		return instance;
	}

 

[mvitz]

Das ist richtig. Aber das Beispiel des TOs deutet ja daraufhin, dass er entweder die Methode synchronized oder der synchronized-Block alles in der Methode umschließt und dann ist es effektiv dasselbe, da eine synchronized-Methode einen Lock auf dem aktuellen Object (also "this") hält, wie in dem zweiten Beispiel.

 

[dunhillone]

Ich würde nicht empfehlen so zu arbeiten.. es macht nur den Code schwerer lesbar.

Der synchronized block hat seine Darseinsberechtigung, beispielsweise um Objekte zu synchronisieren, bei welchen man den Code selber nicht modifizieren kann, die Methodensynchonisation seine eigene.

Aber die Wirkung bleibt in seinem Fall natürlich die selbe.

 

[FArt]

Nein.. wenn du synchronized auf Methodenebene anwendest ist die ganze Methode synchronized. Ansonsten nur der synchronized block.

Dies kann sich stark auf die performance auswirken...

Hier ein beispiel eines singleton:

	private static Object instance = null;
	public static Object getInstance() {
		if(instance == null) {
			synchronized (instance) {
				if(instance == null) {
					instance = new Object();
				}
			}
		}
		return instance;
	}

ist performanter als

	private static Object instance = null;
	public static synchronized  Object getInstance() {
		if(instance == null) {
			instance = new Object();							
		}
		return instance;
	}

Das ist nicht performanter, weil es nicht funktioniert... und zwar nicht nur weil du auf instance (das ja null ist) gar nicht synchronisieren kannst.

Stichwort: double checked locking

 

[dunhillone]

sry.. habs in par sekunden zusammengeschrieben

so müsste es klappen:

public class SingletonClass {
	private static volatile SingletonClass instance = null;
	public static SingletonClass getInstance() {
		if(instance == null) {
			synchronized (SingletonClass.class) {
				if(instance == null) {
					instance = new SingletonClass();
				}
			}
		}
		return instance;
	}
	
	private SingletonClass() {
	}
}

 

[FArt]

sry.. habs in par sekunden zusammengeschrieben

so müsste es klappen:

public class SingletonClass {
	private static volatile SingletonClass instance = null;
	public static SingletonClass getInstance() {
		if(instance == null) {
			synchronized (SingletonClass.class) {
				if(instance == null) {
					instance = new SingletonClass();
				}
			}
		}
		return instance;
	}
	
	private SingletonClass() {
	}
}

Nein. Double checked locking funktioniert grundsätzlich nicht! Die Referenz kann ungleich null sein und trotzdem ist das Objekt noch nicht vollständig instanziiert. Somit würde (unsynchronisiert) eine unfertige Objektinstanz herausgegeben werden.
Entweder Singletons vermeiden, nicht lazy initialisieren, die getInstance-Methode synchronisieren oder über einen Holder gehen (siehe Google).

 

[dunhillone]

Nein. Double checked locking funktioniert grundsätzlich nicht! Die Referenz kann ungleich null sein und trotzdem ist das Objekt noch nicht vollständig instanziiert. Somit würde (unsynchronisiert) eine unfertige Objektinstanz herausgegeben werden.
Entweder Singletons vermeiden, nicht lazy initialisieren, die getInstance-Methode synchronisieren oder über einen Holder gehen (siehe Google).

Hm ich habs jetzt mal ausprobiert und es scheint zu klappen..

Oder warum sollte es nicht gehen?

ackage ch.test.threading;

public class SingletonClass {
	
	public static void main(String[] args) {
		
		Thread t = new Thread(new Runnable() {
			
			@Override
			public void run() {
				for(int i = 0; i < 10; i++)
				SingletonClass.getInstance().doATest("thread 1");
			}
		});
		
		Thread t2 = new Thread(new Runnable() {
			
			@Override
			public void run() {
				for(int i = 0; i < 10; i++)
				SingletonClass.getInstance().doATest("thread 2");
			}
		});
		
		Thread t3 = new Thread(new Runnable() {
			
			@Override
			public void run() {
				for(int i = 0; i < 10; i++)
				SingletonClass.getInstance().doATest("thread 3");
			}
		});
		
		t.start();
		t2.start();
		t3.start();
		
	}
	
	private static volatile SingletonClass instance = null;
	public static SingletonClass getInstance() {
		if(instance == null) {
			synchronized (SingletonClass.class) {
				if(instance == null) {
					instance = new SingletonClass();
				}
			}
		}
		return instance;
	}
	
	private SingletonClass() {
            random = Math.random();
	}
	
	private double random = 0.0;

	
	public void doATest(String thread) {
		System.out.println("thread  " + thread + " : " + random);
	}

}

 

[FArt]

Na ja, die Erklärung habe ich ja schon geliefert, den Hinweis auf Google und die passenden Stichworte "double checked locking" auch... die Zeit, die du in dein Beispiel gesteckt hast, wäre also anders besser investiert gewesen ;-)

double checked locking - Google-Suche

 

[dunhillone]

Mag sein, dass man besser darauf verzichtet, dennoch funktioniert es ab Java 5 einwandfrei...