Erste Schritte Java Collections ohne synchronized gleichzeitig modifizieren?

OpaK

Aktives Mitglied
Ich hätte kurz eine Frage:

Java:
LinkedList<Info> copy;
synchronized (dataLock) {
  copy = new LinkedList<>(data.values());
}
// ...

kann hier ab Zeile 5 ganz normal mit copy, also ohne Synchronisation, weitergearbeitet werden, also über Elemente von copy iteriert, gelöscht, hinzugefügt werden - oder wird in Zeile 3 lediglich eine View auf die Daten erstellt, und die gleichzeitige Modifikation muss scheitern bzw. ist UB?
 
oder wird in Zeile 3 lediglich eine View auf die Daten erstellt,
Einfach einmal der Weg, wie dies überprüft werden kann.

Zum einen die Dokumentation: Diese sagt aus, dass da eine List erzeugt wird, die dann die Element des Iterators enthält.
Zum anderen aber auch der Source: Den kann man sich natürlich direkt ansehen:

Java:
    /**
     * Constructs a list containing the elements of the specified
     * collection, in the order they are returned by the collection's
     * iterator.
     *
     * @param  c the collection whose elements are to be placed into this list
     * @throws NullPointerException if the specified collection is null
     */
    @SuppressWarnings("this-escape")
    public LinkedList(Collection<? extends E> c) {
        this();
        addAll(c);
    }

Du hast also in copy eine eigenständige LinkedList, die unabhängig von data ist (außer eben, dass die Elemente aus data.values() da hinzugefügt wurden). Die Bearbeitung von copy ist also unabhängig von ggf. anderen Threads, die data verändern (Und dafür brauchst Du damit keine Synchronisation mehr)
 
Ok, also kann ich dann copy strukturell verändern... (solange die Elemente (Info s) selbst nicht geändert werden, bzw. immutable sind)

Ich war mir nicht ganz sicher, weil eine Anwendung während einer Modifikation innerhalb einer Schleife einfach anhielt. Aber vermutlich war etwas anderes dafür der Auslöser.

Toll, dass es dich noch gibt , Konrad!

Btw.
Zum einen die Dokumentation
In der Doku zu values() stand allerdings etwas von "nur View ..." (also keine flache Kopie), deshalb war ich etwas irritiert.
 
Ok, also kann ich dann copy strukturell verändern... (solange die Elemente (Info s) selbst nicht geändert werden, bzw. immutable sind)
Ja genau - und Du hast die Grenzen ach richtig erkennt (Sprich: copy und data sind nach dem Lauf des Konstruktors zu 100% separat, aber die Referenzen verweisen auf die gleichen Instanzen, so dass bei möglichen Änderungen wieder auf Thread-Sicherheit geachtet werden müsste.
Ich war mir nicht ganz sicher, weil eine Anwendung während einer Modifikation innerhalb einer Schleife einfach anhielt. Aber vermutlich war etwas anderes dafür der Auslöser.
Das ist immer eine blöde Sache. Erklärt auch recht gut Deine Überprüfung, aber das wäre hier aus meiner Sicht auszuschliessen und es müsste einen anderen Auslöser haben.
In der Doku zu values() stand allerdings etwas von "nur View ..." (also keine flache Kopie), deshalb war ich etwas irritiert.
Ja, das ist immer ein Prunkt, der nicht gerade unkritisch ist. Spielt aber für Dich in Deinem Code erst einmal keine Rolle, da Du ja in einem Synchronized Block die Elemente einfach durchgehst - und damit ist es hier eigentlich unkritisch, was values() nun im Detail macht.
 
Das ist immer eine blöde Sache. Erklärt auch recht gut Deine Überprüfung, aber das wäre hier aus meiner Sicht auszuschliessen und es müsste einen anderen Auslöser haben.

Danke. Ja, mein Anwendungsfall ist:

  • es wird in festen Intervallen eine copy von der data-HashMap gezogen und diese wird verändert,
  • diese copy wird anschließend in eine Datenbank geschrieben...
  • währenddessen kann sich aber die data-HashMap "von außerhalb" ändern...
  • wenn die Anwendung neu gestartet wird, zieht sie sich einmal alle Daten aus der Datenbank und baut die Map neu auf,

Man könnte also sagen, die Map sei Producer und die Copy sei Consumer (also ein Cache ...), oder?

Vermutlich ging aber beim Persistieren etwas schief, also beim Schreiben von copy in die DB (denke ich im Nachhinein.)

Btw. Wieso ist das Forum eigentlich so lange "off" gewesen?
 
Ich selbst kann hier jetzt nicht wirklich viel sagen, da die Details fehlen.

Die typischen Pattern, die ich bei Deinen Worten vor Augen habe ist dann teilweise eher etwas wie:
  • Producer / Consumer - hier wären dann Interfaces wie Supplier<T> oder Consumer<T> die eingesetzt werden. Das wäre dann etwas wie: Wenn die data HashMap angepasst wird, dann wird auch ein Consumer aufgerufen um die Änderung direkt aktiv weiter zu geben. Oder umgedreht wäre der Supplier hat, dass jemand aktiv schaut: Gibt es etwas Neues?
  • Wäre dann unter dem Strich eine Art Event System, das da dann entsteht. Es passiert etwas und in dem Zusammenhang wird dann auch direkt etwas getriggert. Das ist ggf. sinnvoll vor allem auf einer höheren Ebene. Das sind dann die Konzepte, die hakt beliebig ausgebaut und skaliert werden können (MessageQueues, Enterprise Event Bus, ... ) Also z.B. auch interessant zwischen Anwendungen / Services ...

Btw. Wieso ist das Forum eigentlich so lange "off" gewesen?
Da liegen uns bisher keine Informationen vor.
 
Na ja, es ist kein echter Consumer... die Daten werden nur in festen Intervallen weggespeichert: das heißt, copy wird persistiert. Währenddessen dürfen zu copy nur keine neuen Daten hinzukommen oder die bestehenden copy-Daten geändert werden, was aber auch nicht der Fall ist. Die DB-Operation (und ein Vorbereitungsschritt) kann aufwändig (also langsam) sein, deshalb arbeite ich hierbei mit einer flachen Kopie.

Ich könnte das noch weiter ausführen, es hätte dann aber nicht mehr viel mit der Frage zu tun, denke ich.

Da liegen uns bisher keine Informationen vor.
Ok, dann wohl Glück im Unglück. 😉 😵 😀 Bei mir ließ sich die Forum-Seite einfach nicht öffnen... dachte erst, ihr hättet den Stecker gezogen.
 
Ok, dann wohl Glück im Unglück. 😉 😵 😀 Bei mir ließ sich die Forum-Seite einfach nicht öffnen... dachte erst, ihr hättet den Stecker gezogen.
Also das Forum war einige Zeit nicht online ... und davor gab es auch schon fast täglich Ausfälle ... Nur eben haben wir vom Betreiber keine Informationen dazu bekommen.
 

Neue Themen


Zurück
Oben