volatile bei threadsafe Klassen nötig?

[P@u1]

Hallo zusammen,

ich hab in letzter zeit öfter mal eine ConcurrentLinkedQueue benutzt, diese ist laut doku ( ConcurrentLinkedQueue (Java Platform SE 6) ) threadsafe.
Außerdem habe ich gelernt, dass man Variablen deren Inhalte veränderlich sind als volatile deklarieren soll, um zu verhindern, dass ein thread das objekt in den chache schreibt und änderungen nicht mehr für die anderen threads sichtbar sind.
Muss ich jetzt bei der Deklaration volatile benutzen um zu verhindern, dass das Objekt selbst in den Cache geshrieben wird, oder ist das nicht nötig, weil die Klasse threadsafe ist?

Also dann so:

private volatile ConcurrentLinkedQueue<Double> clq = new ConcurrentLinkedQueue<Double>();

oder kann ich das volatile weglassen, da die Klasse threadsicher ist?
Das wäre dann so:

private ConcurrentLinkedQueue<Double> clq = new ConcurrentLinkedQueue<Double>();

edit: obwohl es private ist greifen natürlich trotzdem mehrere threads drauf zu, z.B. über einen getter oder beim erzeugen wird dann ein attribut eines anderes objekts aufs selbe objekt gesetzt.
Ich muss dann ja auch bei jede referenz darauf volatile deklarieren, oder?

 

[SlaterB]

It's probably fair to say that on the whole, the volatile keyword in Java is poorly documented, poorly understood, and rarely used. To make matters worse, its formal definition actually changed as of Java 5. Essentially, volatile is used to indicate that a variable's value will be modified by different threads.

The volatile keyword in Java

soviel auch zu meinem Kenntnis-Stand, benutze ich nie, daher meine Antwort kritisch betrachten 😉

soweit ich das sehe kümmert sich volatile nur um den Objektzugriff, es geht um die Probleme bei Zuweisung eines neuen Objektes an die Variable clq, wenn das bei dir nie geschieht, insbesondere bei final-Variablen, dann dürfte das Schlüsselwort unnötig sein,

in jedem Fall scheint mir die Funktion unabhängig davon, was mit dem Objekt angestellt wird, ob dieses selber threadsave ist oder nicht

edit:
> dass ein thread das objekt in den chache schreibt
diese Befürchtung von dir kann nur eintreten, wenn ein Thread mit einer nicht mehr aktuellen Map arbeitet, während die nicht-volatile Variable schon auf eine andere Map zeigt,
ist das der Fall, dann gehen tatasächlich Infos verloren,
keine Ahnung inwiefern volatile da hilft,

wenn aber wie gesagt die Map immer dieselbe bleibt dann gibt es keinen Cache für Änderungen, die erst später in die Map übertragen werden oder so, dann haben alle immer dieselbe Map, alles funktioniert ganz normal, ob volatile oder nicht, auch threadsave da die Map ja schon dafür sorgt

 

[Marco13]

Volatile ist "flach", d.h. es bezieht sich nur auf die Referenz, und nicht deren Inhalt. Sofern dem 'clq' also keine neue Instanz zugewiesen wird (wovon ich mal ausgehe) sollte das volatile nicht nötig sein. Hier wird einiges dazu gesagt - ist zwar etwas länger, aber ... vielleicht was für die Mittagspause:
JAX TV: Java-Programmierung im Multicore-Zeitalter

 

[P@u1]

vielen dank für eure beiträge!

Wenn ich das jetzt richtig verstanden habe, würde eine volatile deklaration nur die Referenz selbst betreffen und nicht den Inhalt.
Und der Inhalt ist ja laut Doku sowieso schon threadsafe gestaltet.
Ich habe auch nicht vor die Referenz zu ändern, also werde ich jetzt volatile für den Anwendungsfall, aus dem heraus meine Frage hier entstand, weglassen.