Java-vermeiden von race-Bedingung OHNE synchronized/lock

Zur Vermeidung von race-Bedingung, können wir synchronisieren die schreib-und Zugriffs-Methoden auf die gemeinsamen Variablen, sperren Sie diese Variablen in anderen threads.

Meine Frage ist, ob es andere (bessere) Möglichkeiten zur Vermeidung von race-condition? Sperre machen das Programm zu langsam.

Was ich gefunden habe sind:

  • mit Atomarer Klassen, wenn es nur eine shared-variable.
  • mit einem unveränderlichen container für multi-shared-Variablen und erklären, dass diese container-Objekt mit volatile. (Ich fand diese Methode aus dem Buch "Java Concurrency in Practice")

Ich bin mir nicht sicher, ob Sie schneller als syncnronized Weg, gibt es andere, bessere Methoden?

Dank

Das sind beide gute alternativen. Es gibt viele alternativen, die verwendet werden können. Die Anwendbarkeit der einzelnen hängt von Ihren Umständen, und was genau Sie versuchen zu erreichen. Können Sie uns ein wenig mehr Details?

InformationsquelleAutor cn1h | 2011-12-01

  1. 3

    Atomics sind zwar effizienter als die klassische Schlösser, die aufgrund Ihrer nicht-blockierende Verhalten, d.h. ein thread warten, um Zugriff auf den Speicher Ort nicht der Kontext gewechselt werden, das spart eine Menge Zeit.

    Wahrscheinlich der beste Anhaltspunkt, wenn Synchronisation benötigt wird, ist zu sehen, wie können Sie reduzieren den kritischen Abschnitt Größe wie viel wie möglich. Allgemeine Ideen sind:

    1. Read-write-locks anstatt voll sperren, wenn nur ein Teil des threads schreiben müssen.
    2. Finden Wege zur Umstrukturierung von code, um eine Verringerung der Größe der kritischen Abschnitte.
    3. Atomics verwenden, wenn die Aktualisierung einer einzelnen Variablen.
    4. Beachten Sie, dass einige algorithmen und Daten Strukturen, die traditionell müssen Schlösser lock-free-Versionen (Sie sind komplizierter, jedoch).
    "3. Verwenden atomics, wenn die Aktualisierung einer einzelnen Variablen." Wenn es mehr Variablen, aber Sie sind unabhängig (nerver verwendet werden, in gleicher Funktion), kann ich atomics?
    Ja, natürlich. Aber Sie brauchen, um den atomics für jeden von Ihnen.

    InformationsquelleAutor Tudor

  2. 6

    Vermeiden Zustand. Machen Sie Ihre Anwendung als staatenlos, wie es möglich ist. Jeder thread (Abfolge von Aktionen), sollte einen Kontext, in dem Anfang und verwenden diesem Zusammenhang übergeben werden, von Methode zu Methode als Parameter.

    Wenn diese Technik nicht alle Ihre Probleme lösen verwenden event-driven-Mechanismus. Wenn Ihr code hat, um etwas zu teilen mit anderen Komponenten löst Ereignis (Nachricht), um eine Art von bus (Thema, Warteschlange, was auch immer). Komponenten können Listener registrieren, auf Ereignisse zu lauschen und reagieren entsprechend. In diesem Fall gibt es keine race conditions (außer einfügen von Ereignisse in die Warteschlange). Wenn Sie mit ready-to-use-queue und nicht mit der Programmierung selbst, es sollte effizient genug.

    Werfen Sie auch einen Blick auf die Schauspieler-Modell.

    Ich glaube nicht, dass das ersetzen der Java-internen monitor-Verriegelung mit externen Warteschlangen/selbst angetrieben-die Mechanismen zur Verbesserung der performance. Der Antrag komplett zustandslos ist vielleicht nicht eine option sein, die hier entweder, wie der Fragesteller schon erklärt, dass es hat, Daten zu teilen zwischen den threads. Die Schauspieler-Modell könnte nützlich sein, so weit wie code-Sauberkeit angeht, aber wieder, ich denke, die zusätzlichen Aufwand profitieren nicht in Richtung Leistung.
    Bodnarescu, ich Stimme absolut mit Ihnen. Ich habe wohl ausgedrückt, mich nicht genau. Leistung ist hier nicht das Hauptproblem. Code-übersichtlichkeit, Modularität und managebility sind viel wichtiger. Ich wollte nur sagen, dass die Verwendung von Antriebs-Ansatz nicht die Leistung verringern, wie manche Menschen Angst haben.
    Vereinbart, und wenn ich hinzufügen darf, Scala - Akteure-Modell-Implementierung ist ganz nett. Und da Scala ist ein Schritt Weg von Java für einen Java-Entwickler, das könnte eine option sein.
    über "die Anwendung Staatenlose", wenn ich keine gemeinsamen Daten zwischen threads, aber ich muss etwas gemeinsam zwischen Funktionen in dem gleichen thread, den ich verwenden soll, ThreadLocal Klasse, richtig?

    InformationsquelleAutor AlexR

  3. 2

    Nun, zunächst einmal Atomaren Klassen verwendet sperren (mittels synchronized und volatile keywords) nur so, als würden Sie tun, wenn Sie haben es selber per hand.

    Zweite, Unveränderlichkeit funktioniert großartig für multi-threading, die Sie nicht mehr benötigen, überwachen, sperren und so, aber das ist, weil Sie nur Lesen können Ihre immutables, cand ändern.

    Können Sie nicht loswerden, synchronisiert/volatile-wenn Sie möchten, um Wettlaufsituationen zu vermeiden, die in einer multithreaded Java-Programm (d.h. wenn mehrere threads cand Lesen UND SCHREIBEN der gleichen Daten). Ihre beste Wette ist, wenn Sie wollen eine bessere Leistung zu vermeiden, zumindest einige der eingebauten thread-sichere Klassen, die eine Art allgemeiner, sperren und stellen Sie Ihre eigene Implementierung, die ist mehr gebunden an den Kontext und somit könnte Ihnen ermöglichen, um mehr granullar Synchronisation & lock-Akquisition.

    Schauen Sie sich diese Implementierung des BlockingCache erfolgt durch den Ehcache Jungs;

    http://www.massapi.com/source/ehcache-2.4.3/src/net/sf/ehcache/constructs/blocking/BlockingCache.java.html

    Atomic-Klassen nicht (in der Regel) verwenden, synchronisiert. Ihre Werte sind volatil, das ist richtig. Statt synchronisiert die Sonne.misc.Unsicher-Klasse verwendet wird, das keine CAS-Operationen, die als native code. Also, wenn die Plattform Ihren Betrieb auf unterstützt atomaren CAS-Operationen in assembler, seine sehr wahrscheinlich, dass die anstelle von synchronisieren.

    InformationsquelleAutor Shivan Dragon

  4. 2

    Einer der alternativen ist zu stellen shared Objekte unveränderlich. Check-out dieser Beitrag für mehr details.

    InformationsquelleAutor Santosh

  5. 1

    Können Sie durch ausführen von bis zu 50 Millionen Euro-lock/entsperrt pro Sekunde. Wenn Sie wollen, dass dies effizienter sein, schlage ich vor, mit mehr natürlich Getreide sperren. d.h. die sperren nicht jede kleine Sache, aber sperren haben, die für größere Objekte. Sobald Sie haben viel mehr Schlösser als threads, Sie sind weniger wahrscheinlich, um Konflikte und mehr sperren kann nur hinzufügen overhead.

    InformationsquelleAutor Peter Lawrey

Schreibe einen Kommentar