Warum ist 'Lock (this)' in Multithread -Programmierung gefährlich?

Vermeiden Sie die Verwendung von

: verborgene Gefahren in der Programmierung mit mehreren Threads lock(this) Microsoft -Dokumente werden deutlich empfohlen, um die Verwendung von

nach Belieben zu vermeiden und die Gründe und potenziellen Folgen dahinter zu verstehen.

lock(this) Das Problem der unkontrollierten Sperrung

Der Kern des -Problems ist, dass es unmöglich ist zu steuern, welche anderen Threads dasselbe Objekt sperren können. Dies kann leicht zu toten Schlössern führen.

geht davon aus, dass ein Objekt öffentlich ausgesetzt ist, jeder kann seine Referenz erhalten. Wenn eine dieser Referenzen verwendet wird, um das Objekt zu sperren, weiß der Ersteller des Objekts möglicherweise nichts darüber, was die parallele Ausführung kompliziert und Unfallfehler verursachen kann.

Zerstöre die Einkapselung und reduziere die Klarheit

Verwenden des illegalen Verpackungsprinzips Der Verriegelungsmechanismus ist dem öffentlichen Zugang ausgesetzt. Dies macht es schwierig, die erwartete Verwendung und das Verhalten des Objekts zu verstehen. Im Gegenteil, das Schließen mit privaten Feldern kann eine klarere Trennung von Aufmerksamkeitspunkten liefern und sicherstellen, dass die interne Verriegelung ohne unnötige Implementierungsdetails ausgesetzt ist. Gefahr von Missverständnissen und String

lock(this) Einige Missverständnisse haben versehentlich zur Verwendung von

beigetragen. Ein Missverständnis ist, dass das Verriegelungsobjekt selbst so ist, dass das Objekt nicht wechseln oder Änderungen vermieden wird. Dies ist nicht der Fall. Das an die

Anweisung übergebene Parameterobjekt dient nur dazu, den Schlüssel zu identifizieren, um das Sperrobjekt zu identifizieren. Eine weitere Falle ist, zu versuchen, eine Zeichenfolge als Schlüssel in der Anweisung

zu verwenden. Da die Zeichenfolge unverändert und zwischen Anwendungen geteilt wird, kann dieser Ansatz zu unerwarteten Sperrkonflikten führen. Stattdessen ist es am besten, private Objekte als Schlüssel zu verwenden, um den Sperrmechanismus besser zu steuern.

lock(this) Fallstudie: Die Sicherheit der Thread -Sicherheit in paralleler Behandlung lock

Um das potenzielle Problem zu erklären, betrachten Sie bitte den folgenden C#Code: lock

Erstellen Sie in der Hauptmethode mehrere Threads und jeder Thread versucht, Operationen auf dem -Objekt auszuführen. Methode, um zu versuchen, die Sperre des Objekts von

das Objekt zu verwenden. Die Methoden und versuchen jedoch auch, das Objekt direkt oder indirekt zu sperren und den

als Schlüssel zu verwenden. Dies führt zu unerwarteten Konflikten und toten Schlössern, da der Code versucht, Operationen darauf auszuführen, wenn das Objekt eines anderen Threads gesperrt wird. (Es wird davon ausgegangen Kurz gesagt, verwenden Sie

, um die Sicherheit der Threads zu zerstören und potenzielle Sackgassen zu erstellen. Unter Verwendung privater Feldverpackungsmechanismen und der Verwendung privater Objekte als Schlüssel in der

<code class="language-csharp">public class Person
{
    public int Age { get; set; }
    public string Name { get; set; }

    public void LockThis()
    {
        lock (this)
        {
            System.Threading.Thread.Sleep(10000);
        }
    }
}</code>

-Anweisung kann eine robustere und zuverlässigere Methode der Thread -Synchronisation bereitgestellt werden.

Das obige ist der detaillierte Inhalt vonWarum ist 'Lock (this)' in Multithread -Programmierung gefährlich?. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!