Wie stellen Sie die Aktualisierung BigDecimal innerhalb ConcurrentHashMap thread-sichere

Ich versuche eine Anwendung, die dauert ein paar journal-Einträge und die Summe berechnen.

Ist unten Weg, es zu tun ist thread/concurrency sicher, wenn es mehrere threads Aufruf der addToSum() Methode. Ich möchte sicherstellen, dass jeder Aufruf aktualisiert das total richtig.

Wenn es nicht sicher ist, erklären Sie bitte, was muss ich tun, um thread-Sicherheit gewährleisten.

Muss ich synchronize den get/put-oder gibt es eine bessere Möglichkeit?

private ConcurrentHashMap<String, BigDecimal> sumByAccount;

public void addToSum(String account, BigDecimal amount){
    BigDecimal newSum = sumByAccount.get(account).add(amount);
    sumByAccount.put(account, newSum);
}

Vielen Dank!

Update:

Danke an alle für die Antwort habe ich bereits bekommen, dass der code oben ist nicht thread-safe.

Dank Vint für die Annahme, die AtomicReference als alternative zu synchronize. Ich war mit AtomicInteger zu halten, integer Summen vor, und ich Frage mich, ob es so etwas wie, dass für BigDecimal.

Ist das eine definitive Schlussfolgerung über das pro und Contra von beiden?

InformationsquelleAutor Desmond Zhou | 2011-12-19
  1. 14

    Können Sie verwenden, synchronisiert wie die anderen vorgeschlagen, aber wenn Sie möchten, eine minimal-blocking-Lösung können Sie versuchen AtomicReference als Speicher für die BigDecimal -

    ConcurrentHashMap<String,AtomicReference<BigDecimal>> map;

public void addToSum(String account, BigDecimal amount) {
    AtomicReference<BigDecimal> newSum = map.get(account);
    for (;;) {
       BigDecimal oldVal = newSum.get();
       if (newSum.compareAndSet(oldVal, oldVal.add(amount)))
            return;
    }
}

    Bearbeiten - ich werde erklären mehr:

    Eine AtomicReference verwendet CAS, atomar weist einen einzelnen Verweis. Die Schleife sagt dieser.

    Wenn das aktuelle Feld gespeichert AtomicReference == oldVal [Ihre Position im Speicher, nicht Ihren Wert], dann ersetzen Sie den Wert des Feldes gespeichert in AtomicReference mit oldVal.add(amount). Nun wird jedes mal nach der for-Schleife aufrufen newSum.get() es wird die BigDecimal-Objekt, das Hinzugefügt wurde.

    Möchten Sie eine Schleife verwenden, da es möglich ist, zwei threads versuchen, hinzufügen, um die gleichen AtomicReference. Es kann passieren, dass ein thread erfolgreich ist und ein anderer thread schlägt fehl, wenn das passiert, einfach nochmal versuchen mit den neuen zusätzlichen Wert.

    Mit moderaten thread Behauptung, dies wäre eine schnellere Umsetzung, mit hohem Streit-Sie sind besser mit synchronized

    • Können Sie erklären, wie dies funktioniert?
    • Gute Idee, aber ich glaube, Sie haben etwas zu korrigieren: Sie rufen newSum.get() zweimal in den Zustand überprüfen, aber es könnte sich ändern zwischen den beiden anrufen. Sie sollten vielleicht mit einem do { } while() wo Sie nur rufen get einmal.
    • Danke für die Erklärung. +1.
    • Gemäß der Java Language Spec, "Es wird empfohlen, dass code sich nicht entscheidend auf" die Forderung, dass ", dass die Operanden von Operatoren angezeigt werden ausgewertet, in einem bestimmten evaluation bestellen, nämlich von Links nach rechts." So, obwohl ich glaube, dass dein code ist solide, ich denke, es ist wahrscheinlich besser, etwas so zu schreiben while(true) { BigDecimal oldVal = newSum.get(); BigDecimal newVal = oldVal.add(amount); if(newSum.compareAndSet(oldVal, newVal)) break; }.
    • Sind Sie sicher, dass synchronized ist besser für high-Streit? Ich dachte, dass (ohne besonderen Grund), dass CAS immer besser wurde.
    • Sie haben völlig Recht, vielen Dank lassen Sie mich zu aktualisieren, die jetzt!
    • mit hohem Streit-threads wird oft nicht wegen der vielen Wiederholungen, wo so synchronisieren Sie wird in die Warteschlange/verwalten Sie leichter mit höheren Gesamtdurchsatz.
    • Seit dem Aufruf auf der rechten Seite passiert nach dem Aufruf auf der linken Seite, jede änderung zwischen den beiden anrufen würde dazu führen, die compareAndSet nichts zu tun und zurück false. Also ich glaube, es ist technisch O. K.; aber ich Stimme mit dir trotzdem, dass es besser wäre, rufen Sie get nur einmal, so dass der code leichter zu Grunde geht.
    • Ich naiv (und zugegeben viel zu schnell) zusammen die Lösung, ohne zu berücksichtigen, dass der Verlust von Atomarität, vielen Dank für dein update
    • Sind Sie sicher, dass die Reihenfolge der Operationen ist hier garantiert, da der code nicht vorhanden in einen synchronized block? Ich Stimme mit Ihrer früheren Kommentar über das tun der nur einmal erhalten, da ich nicht sicher bin, dass es ist passiert, bevor die Garantie zwischen newSum.get() und newSum.get().add(), so dass der compiler kann frei sein, neu zu ordnen diesen Anweisungen.
    • Wenn Sie einen Blick auf die AtomicXXX.incrementAndGet Methoden, die Sie verwenden, eine ähnliche Art und es ist garantiert werden, um thread-safe (ohne synchronisiert). Um Ihr anderen Punkt-es ist nicht so sehr eine Bestell - /Speicher-Problem, wie es war mehr ein Atomarität Problem.
    • Ich bin mir nicht sicher, Nein, aber ich glaube schon, da AtomicReference bietet die gleichen Garantien wie volatile und volatile schreiben in einem anderen thread müsste bestellt werden, mit Respekt zu flüchtig liest in diesem thread. Aber dieses Zeug ist verwirrend, und ich wiederhole, dass ich nicht sicher bin. Ich werde eine Nacht darüber schlafen! (Übrigens, es gibt sicherlich ist eine passiert-bevor die Garantie, da das JMM gibt an, dass zwei Aktionen in der gleichen Gewinde haben immer geschieht-vor-auch mit nicht-flüchtige. Es ist nur so, dass einem passiert-bevor die Garantie bedeutet nicht so viel, wie es klingt, wie es heißt.)
    • du hast Recht. Es besteht eine happens-before Beziehung (enthält sowohl compiler-und Speicher-Bestellung) mit Bezug auf AtomicReference.compareAndSet und AtomicReference.get
    • Danke! Ich weiß, synchronisieren funktionieren würde, aber ich habe nicht gesehen, AtomicReference vor, wird auf jeden Fall ein tiefer Blick in diese.
    • Die Auswertung Reihenfolge der Argumente zu compareAndSet wäre kein Problem, da BigDecimal ist unveränderlich, oldVal.add(amount) nicht ändern oldVal.
    • Äh, sorry, aber du kommst ein bisschen spät. Die Bewertung, um Tat-Sache, für die Antwort, war da, als ich gepostet mein Erster Kommentar. Die Antwort hat sich seitdem geändert, um die Bedenken in der Diskussion. (Siehe stackoverflow.com/posts/8567817/revisions.)
    • Oh, sorry, ich habe nicht bemerkt, die älteren Revisionen. Die Diskussion macht viel mehr Sinn, jetzt 🙂
    • Keine Sorge. 🙂

    InformationsquelleAutor John Vint
  2. 4

    Ist nicht sicher, da die threads A und B könnten beide rufen sumByAccount.get(account) zur gleichen Zeit (mehr oder weniger), also weder wird man sehen, das Ergebnis der anderen add(amount). Das ist, was passieren könnte, in dieser Reihenfolge:

    • thread A ruft sumByAccount.get("accountX") und bekommt (zum Beispiel) 10.0.
    • thread B ruft sumByAccount.get("accountX") und bekommt den gleichen Wert, den Faden Einer Tat: 10.0.
    • thread A setzt seine newSum um (sagen wir) 10.0 + 2.0 = 12.0.
    • thread B setzt seinen newSum um (sagen wir) 10.0 + 5.0 = 15.0.
    • thread A ruft sumByAccount.put("accountX", 12.0).
    • thread B ruft sumByAccount.put("accountX", 15.0) zu überschreiben, was Ein thread hat.

    Einen Weg, um dies zu beheben, setzen synchronized auf Ihre addToSum Methode, oder wickeln Sie den Inhalt in synchronized(this) oder synchronized(sumByAccount). Eine andere Weise, da die oben genannten Abfolge der Ereignisse, die passiert nur, wenn zwei threads aktualisieren Sie den gleichen account zur gleichen Zeit, vielleicht, zu synchronisieren, extern, basierend auf irgendeine Art von Account Objekt. Ohne dass der rest der Programm-Logik, ich kann nicht sicher sein.

    InformationsquelleAutor ruakh
  3. 3

    Ihre Lösung ist nicht thread-sicher. Der Grund dafür ist, dass es möglich ist, eine Summe zu übersehen, da der Betrieb zu setzen, ist getrennt von der operation zu bekommen (also den neuen Wert, den Sie setzen in die map könnte vermissen eine Summe, die Hinzugefügt wird, in der gleichen Zeit).

    Ist der sicherste Weg, das zu tun, was Sie wollen zu tun ist, synchronisieren Sie Ihre Methode.

    InformationsquelleAutor Trevor Freeman
  4. 2

    Ja, Sie brauchen, um zu synchronisieren, da Sie sonst zwei threads jeweils den gleichen Wert für den gleichen Schlüssel), sagen und thread 1 add B und thread 2 fügt C an und speichern Sie es zurück. Das Ergebnis jetzt nicht sein A+B+C, aber A+B oder A+C.

    Was Sie tun müssen, ist die Sperre auf etwas, das in den Ergänzungen. Synchronisieren auf get/put wird nicht helfen, es sei denn, Sie tun

    synchronize {
    get
    add
    put
}

    aber wenn Sie das tun, dann werden Sie verhindern, dass threads, die von der Aktualisierung der Werte auch wenn es für die verschiedenen Tasten. Die Sie synchronisieren möchten, auf das Konto. Jedoch, synchronisieren von auf dem string scheint unsicher, wie es könnte zu einem Deadlock führen (Sie weiß nicht, was sonst sperrt den string). Können Sie erstellen Sie ein Konto-Objekt statt und verwenden, die für die sperren?

    InformationsquelleAutor Roger Lindsjö
Schreibe einen Kommentar