ITflow.de

Eingentlich ist das Vergleichen eines Stringinhalts ziemlich simpel.
Dennoch wird es gerade bei der Überprüfung auf ” “, also auf keinen Inhalt aber existierendes Objekt, oft falsch gemacht!

if(string == “”){

}

if(string.equals(“”)){

}

if(“”.equals(string)){

}

Folgendes wäre beim Inhalt falsch, da diese Abfrage sich auf die Existenz eines Objekts bezieht:

if(string == null){

}

if(string.equals(null)){

}

Warum wir das schreiben? Man findet im Web viele Lösungsvorschläge, aber keine Übersicht über das ganze.

Es kursieren Gerüchte, Java sei nicht richtig Mulitcore-fähig.Dies ist jedoch seit Java 1.5 grundlegend widerlegt. Jedenfalls haben wir ein bisschen herumprobiert und festgestellt, dass die Thread Technik und das Memory Model ziemlich ausgereift sind.
Allerdings ist das ganze Thema nicht ganz einfach, da man wesentlich mehr Aspekte beachten muss als bei der sequentiellen Programmierung.

Threads  sind dazu da, dass Aufgaben parallel abgearbeitet werden können und somit die JVM nicht durch einen Task, der gerade ausgeführt wird, blockiert ist. Man will also erreichen, dass ein Thread über seine Laufzeit maximal ausgelastet ist.
Was ist nun aber wenn ein Thread auf das Ergebniss eines anderen Threads warten muss?
Dann sinkt die ‘Thread-Auslastung’ während der Wartezeit quasi auf null.
Hiermit sind wir schon bei dem zentralen Problem des Parallelprocessing, nämlich der Synchronisation zwischen Threads.
Wenn man von dem idealen Parallelprocessing ausgeht, dürfte keine Synchronisation zwischen den Threads vorhanden sein, weil diese kostet immer Zeit, und damit auch Performance. Da aber bei vielen MultiThread Programmen ein Mindestmaß an Synchronisation vorhanden sein sollte, ist das Java Memory Model von Nöten. (Falls man wirklich keine Synchronisation haben möchte, gibt es z.b.  java.util.concurrent.atomic). Hier sind ein paar Stichworte zum Java Memory Model. Folgendes ist zu beachten:

Sichtbarkeit, Final und static Fields, die Sicherheit während der Initialisierung, was darf wer und wann, usw….

Das oben gezeigte Schema illustriert ein Modell, bei welchem das locale Thread Ergebnis, sofort wenn es fest steht, einen Push auf das Globale Object ausführt.
Dabei ist es von Bedeutung, dass während der Zeit, in der das Object bearbeitet wird, kein anderer Thread etwas an dem Object verändert bzw. schon das neue Object bekommt, d.h. das Object muss blockiert werden und die anderen Threads müssen warten.
Ab Java 1.5 gibt es hierfür unter anderem volatile und syncronise

public class Kunden{

public static volatile ArrayList list;

public Kunden(){

list = new ArrayList();

}

public syncronised void addKunde(Kunde kunde){

list.add(kunde);

}

public syncronised void removeKunde(Kunde kunde){

list.remove(kunde);

}

public syncronised Kunde getLatest(){

list.get(list.size()-1);

}

}

In diesem Beispiel gibt die Methode getLatest() immer den wirklich letzten Kunde zurück, auch wenn gerade ein neuer Kunde hinzugefügt wurde. Denn syncronised blockiert das Object, solange die Methoden add/removeKunde/getLatest damit arbeiten und führt einen Flush auf alle Objecte aus damit diese tatsächlich den aktuellen Stand im Speicher haben, wenn die Methode ausgeführt ist.
Da die Softwareunterstützung für Multicore Prozessorarchitektur immernoch nicht richtig in Fahrt ist, bzw. erst langsam im kommen ist, wird sich jeder Programmierer irgendwann einmal damit beschäftigen müssen. Jedenfalls ist dieses Thema sehr spannend, da es teilweise sehr komplex  ist und man dadurch vor ganz neue Herrausforderungen gestellt wird.