Monitor

In Java ist jedes Objekt ein Monitor.

public synchronized void GeldAbheben() {
    // Hier drin bin ich sicher alleine.
}

Du musst kein lock() oder unlock() schreiben. Das macht die Java Virtual Machine (JVM) für dich.

1. Condition Variables (Wait / Notify)

Was, wenn ich im Gebäude bin, aber auf etwas warten muss (z. B. dass Geld aufs Konto kommt)? Ich will das Gebäude nicht blockieren. Lösung: Condition Variables.

• wait(): Ich gehe in den "Warteraum" und gebe den Schlüssel ab. Jemand anderes kann rein.
• notify(): Jemand anderes ruft: "Hey, Geld ist da!". Ich wache auf und versuche, den Schlüssel wieder zu bekommen.

2. Hoare vs. Mesa Semantik

• Hoare: Wenn ich notify rufe, bekommt der Wartende sofort den Schlüssel (Prio).
• Mesa (Standard): Wenn ich notify rufe, wird der Wartende nur in die Warteschlange gestellt. Er kommt irgendwann später dran. (Effizienter, aber man muss while-Schleifen statt if beim Warten nutzen).

1. Wait Set und The Spurious Wakeup Phantom

Ein gewaltiges Bug-Nest tief an der OS-Scheduler Frontlinie nennt sich Spurious Wakeup (Falsches Aufwachen). Stellen wir uns Thread A im Monitor-Block vor, der via POSIX pthread_cond_wait() auf das IO-Signal (Condition Variable) tief im "Dornröschenschlaf" chillt. Durch Hardware-Interrupts (wie C-Level POSIX System Signale) weckt der Linux Kernel aus Scheduling-Mechanik-Effizienzgründen oft asynchron hunderte von OS-Threads im Wait-Set blind auf – oftmals völlig OHNE dass ein anderer paralleler Monitor den ersehnten notify() Aufruf getätigt hat. Wenn der Java/C-Dev also seinen Check imperativ mit if (empty) wait(); designt, spaziert der Prozess ahnungslos durch das Monitor-Tor heraus in einen leeren Puffer und stürzt sofort ab (NullPointer). Lösung: Die harte Regel des Multi-Threadings: Condition-Variables evaluiert man ZWINGEND in strikten while(empty) { wait(); } Schleifen. Das zwingt den fälschlich erwachten Thread gnadenlos dazu, die Wahrheit am Register erneut zu messen und sich wieder frustriert zurück ins OS-Schlucht zu locken!

2. Java Object Headers & Biased Locking

Der Overhead von Monitoren (JVM synchronized) galt 1999 noch als toxisch für Performance, da jede Synchronisation ins dicke Betriebssystem durchschlug. Die JVM rettete dies durch extrem brillante Garbage Collection-C++ Tricks im Heap. Jedes instanzierte RAM-Objekt (Klasse) hat ein winziges 64-bit Header Meta-Feld ("Mark Word"). Beim ersten Betreten eines noch frischen Monitors wendet die JVM Biased Locking an. Auf Hardware-Level speichert die JVM per winzig-schnellem Compare-And-Swap (CAS) Bitwise-Operator einfach die CPU-Hardware-ID des zugreifenden Threads in den RAM des Objekt-Headers. Kein Mutex-Call ins lahme OS-Ring0 passiert! Sollte Thread A danach tausende Male den gleichen Monitor sequenziell betreten und verlassen (z. B. Schleifen im Vector-Array), kostet ihn diese Security keinen einzigen System-Cycle mehr. Bloß beim aggressiven Parallelzugriff eines fernen Thread B auf dasselbe Target entklinken sich die Flags (Lock Inflation über Thin Lock), und das eiserne, fatale OS-Sperren schlägt greifend ein.

3. Reentrancy Pattern (Wiedereintrittsfähigkeit)

Kann ein Thread in einem Monitor blockieren, weil er selbst das Schloss besitzt? Die Frage von Per-Object vs Per-Method Locking. Wenn in Java Methode A und Methode B am Objekt dasselbe Monitor-Lock fassen, und Synchronized A() in Loop-Logik intern Synchronized B() anruft. Würde der Monitor primitiv sein, läge hier ein fataler "Self-Deadlock" (Der Thread wartet auf sich selbst am Schloss von B). Monitore implementieren rigoros Reentrancy (Wiedereintrittsfähigkeit). Der Monitor speichert intern nicht nur das Locked Flag ein, sondern führt präzise ein Zählregister (counter++) sowie die exakte Thread-ID des aktuellen Besitzers im Call-Stack. Verlässt Code den Block B, schaltet counter--, aber das Schloss (und andere Warteschlangen-Mitglieder) gibt der Monitor tief im Kernel erst vollends feil an die freie Wildbahn, wenn in Funktion A der Master-Zähler auf Null zusammenkracht.