Was bedeutet der Monitor eines Objekts in Java? Warum dieses Wort verwenden?

Beim Lesen von Artikeln über Java-Threads fällt mir häufig der Ausdruck auf: "Der aktuelle Thread ist der Eigentümer des Monitors dieses Objekts". Ich verstehe die Bedeutung: Der Thread erhält das Recht, das Objekt zu bearbeiten. Aber ich bin verwirrt, warum wir den Ausdruck "der Monitor des Objekts" anstelle von "die Sperre des Objekts" verwenden?

Kurz gesagt, ich kenne die Bedeutung des Wortes "Monitor" nicht. Die Frage kann seltsam und einfach sein. Aber ich wünschte, jeder könnte helfen, es zu lösen. 3ks

aber ich bin verwirrt, warum das Wort "der Monitor des Objekts" anstelle von "die Sperre des Objekts" verwendet wird?

In der Antwort von ulmangt finden Sie Links, die den in diesem Zusammenhang verwendeten Begriff "Monitor" erläutern. Beachten Sie, dass:

"Monitore wurden von Per Brinch Hansen und CAR Hoare erfunden und erstmals in der Concurrent Pascal-Sprache von Brinch Hansen implementiert."

(Quelle: Wikipedia )

Warum den Begriff "Monitor" anstelle von "Sperre" verwenden? Genau genommen bedeuten die Begriffe verschiedene Dinge ... insbesondere, wenn Sie sie so verwenden, wie sie ursprünglich verwendet werden sollten.

• Eine "Sperre" ist etwas mit Grundelementen zum Erfassen und Freigeben, die bestimmte Sperreigenschaften beibehalten. zB ausschließliche Verwendung oder Einzelschreiber / Mehrfachleser.

• Ein "Monitor" ist ein Mechanismus, der sicherstellt, dass immer nur ein Thread einen bestimmten Abschnitt (oder Abschnitte) von Code zu einem bestimmten Zeitpunkt ausführen kann. Dies kann mithilfe einer Sperre implementiert werden (und "Bedingungsvariablen", mit denen Threads auf die Erfüllung der Bedingung warten oder Benachrichtigungen an andere Threads senden können), ist jedoch mehr als nur eine Sperre. In der Tat ist im Java-Fall die von einem Monitor tatsächlich verwendete Sperre nicht direkt zugänglich. (Sie können einfach nicht "Object.lock ()" sagen, um zu verhindern, dass andere Threads es erwerben ... wie bei einer Java- LockInstanz.)

Kurz gesagt, wenn man pedantisch sein sollte, ist "Monitor" tatsächlich ein besserer Begriff als "Sperre", um zu charakterisieren, was Java bietet. In der Praxis werden beide Begriffe jedoch fast synonym verwendet.

Ein Monitor ist einfach ein Begriff für ein Objekt, dessen Methoden in einer Multithread-Umgebung sicher verwendet werden können.

Es gibt einen großartigen Wikipedia-Artikel über Monitore:

http://en.wikipedia.org/wiki/Monitor_(synchronization)

Wenn Sie nach unten scrollen, wird sogar ein Abschnitt explizit über Java angezeigt .

Zitat aus der Java Virtual Machine

Ein Thread in der virtuellen Java-Maschine fordert eine Sperre an, wenn er am Anfang eines Überwachungsbereichs eintrifft. In Java gibt es zwei Arten von Überwachungsregionen: synchronisierte Anweisungen und synchronisierte Methoden.

Monitor

Ein Monitor ist wie ein Gebäude, das einen speziellen Raum enthält, der jeweils nur von einem Thread belegt werden kann. Der Raum enthält normalerweise einige Daten. Ab dem Zeitpunkt, an dem ein Thread diesen Raum betritt, bis zu dem Zeitpunkt, an dem er ihn verlässt, hat er exklusiven Zugriff auf alle Daten im Raum. Das Betreten des Monitorgebäudes wird als "Betreten des Monitors" bezeichnet. Das Betreten des speziellen Raums im Gebäude wird als "Erwerb des Monitors" bezeichnet. Das Besetzen des Raums wird als "Besitzen des Monitors" und das Verlassen des Raums als "Freigeben des Monitors" bezeichnet. Das Verlassen des gesamten Gebäudes wird als "Verlassen des Monitors" bezeichnet.

Ein Monitor ist nicht nur einem Datenbit zugeordnet, sondern auch einem oder mehreren Codebits, die in diesem Buch als Monitorbereiche bezeichnet werden.

Wie bereits erwähnt, bietet die Sprache zwei integrierte Möglichkeiten zum Identifizieren von Überwachungsbereichen in Ihren Programmen: synchronisierte Anweisungen und synchronisierte Methoden. Diese beiden Mechanismen, die den Aspekt des gegenseitigen Ausschlusses der Synchronisation implementieren, werden vom Befehlssatz der Java Virtual Machine unterstützt.

Sperren

Um die gegenseitige Ausschlussfähigkeit von Monitoren zu implementieren, ordnet die virtuelle Java-Maschine jedem Objekt und jeder Klasse eine Sperre (manchmal auch als Mutex bezeichnet) zu. Eine Sperre ist wie ein Privileg, das jeweils nur ein Thread "besitzen" kann.

Ein einzelner Thread darf dasselbe Objekt mehrmals sperren. Für jedes Objekt zählt die Java Virtual Machine, wie oft das Objekt gesperrt wurde. Ein entsperrtes Objekt zählt Null. Wenn ein Thread die Sperre zum ersten Mal erhält, wird die Anzahl erneut auf eins erhöht. Jedes Mal, wenn der Thread eine Sperre für dasselbe Objekt erhält, wird die Anzahl erneut erhöht.

Ein synchronizedBlock um einen objectist sein Monitor, der eine Sperre für das Objekt steuert. Hier ein Beispiel

synchronized (object) {
   while (<condition does not hold>)
      object.wait(timeout);
   ... // Perform action appropriate to condition
}

Obwohl es spät ist, diese Frage zu beantworten, dachte ich, ich sollte nur hinzufügen, falls es nützlich ist.
Hier ist ein synchronisierter Block von Java-Code innerhalb einer nicht synchronisierten Java-Methode

public void add(int value){
synchronized(this){
      this.count += value;
   }
}

Im Beispiel wird "this" verwendet. Dies ist die Instanz, für die die add-Methode aufgerufen wird. Eine synchronisierte Instanzmethode verwendet das Objekt, zu dem sie gehört, als Überwachungsobjekt.
=> Innerhalb eines Java-Codeblocks, der auf demselben Monitorobjekt synchronisiert ist, kann nur ein Thread ausgeführt werden.

Die Java Virtual Machine verwendet Monitore, um Multithreading zu unterstützen. Monitore erreichen dies durch zwei Konzepte: Gegenseitiger Ausschluss beim Ausführen der Threads (hier kommt das Sperren ins Spiel) und Koordination als Mittel der Kommunikation zwischen Threads (hier kommen die Warte- und Benachrichtigungsmethoden des Objekts ins Spiel).

Das Lesen des folgenden Teils aus "Inside JVM" wird diesen Zweifel beseitigen. Wird er hier sehr gut erklärt (Kapitel 20, Thread-Synchronisation)?

https://www.artima.com/insidejvm/ed2/threadsynchP.html