Idee: Konzentration der kritischen Anweisungen in eine einzige Programmzeile.
etwa: dos.writeInt( dis.readInt()+1 ).

Kritik: Zwar eine naheliegende Idee, aber keine Problemlösung.
Selbst diese vermeintlich atomare Anweisung zerfällt zunächst in eine Fülle von Java-Anweisungen, welche die API-Methoden writeInt (Quellcode) bzw. readInt (Quellcode) bilden.
Darüberhinaus sind selbst diese konstituierenden Java-Anweisungen der API keineswegs atomar, sondern werden ihrerseits die Bytecodeanweisungen der JVM gebildet (Bytecode: readInt, writeInt).
Schlußendlich werden die Bytecode-Instruktionen selbst nicht direkt durch die physische Hardware ausgeführt, sondern durch die virtuelle Maschine in native Anweisungen übersetzt.

Dieser (naive) Ansatz kann daher nicht zur Synchronisation eingesetzt werden!

Idee: Sicherung des kritischen Bereichs durch Sperroperation.
(Vorgriff: Die Implementierung orientiert sich an der Idee der Semaphore.)

Analyse: Trotz der guten Absicht bleibt das Problem bestehen.
Genaugenommen wurde es lediglich verlagert ...
Konnte zuvor der Thread zwischen Lese- und Schreibzugriff auf die Datei unterbrochen werden, so kann dies nun zwischen Anforderung und Erteilung der Sperre geschehen.
Überdies verbraucht die gewählte Implementierung ab Zeile 65 unnötig Rechenzeit durch den aktiven Wartevorgang ( busy waiting ).

Zur Implementierung ist eine unteilbare Hardwareoperation notwendig.
Kap. 7.2.1.2 des IA-32 Intel® Architecture Software Developer's Manuals empfiehlt zur Implementierung auf einem IA-32 Prozessor hierfür die Instruktion CMPXCHG.

Eigenschaften:

• Das Schlüsselwort synchronized gestattet es kritische Abschnitte auf Hochsprachenebene deklarativ zu kennzeichnen.
• Es können sowohl Programmblöcke als auch komplette Methoden als synchronized gekennzeichnet werden.
• Die gesamte Synchronisationlogik wird durch die Java Virtual Machine bereitgestellt.
• Die Durchführung der Synchronisation hat negative Auswirkungen auf die Laufzeit.

Idee: Durch Anbringung des Schlüsselwortes in der Signatur einer Methode wird die virtuelle Maschine veranlaßt ein so gekennzeichnete Methode nicht nebenläufig auszuführen. Alle Aufrufe werden strikt serialisiert und ggf. verzögert bis die Methode zum alleinigen Zugriff zur Verfügung steht.

Anwendungsbeispiel: Die Veränderung im Quellcode betrifft ausschließlich Zeile 37. Dort wird die Methode addOne zusätzlich mit dem Schlüsselwort synchronized versehen.

Weiteres Anwendungsbeispiel: Im vorherigen Beispiel war die Synchronisation auf eine Methode angewandt worden, die auf einem (existierenden) Objekt ausgeführt wurde.
Prinzipiell kann derselbe Mechanismus auch für statische Methoden zur Anwendung gebracht werden.
Hierbei wird die Sperrinformation nicht durch das Objekt, welches die zu sperrende Methode enthält verwaltet, sondern durch die beherbergende Klasse selbst.

Zum Beispiel: Der Code simuliert einen Hotelmanager bei der Arbeit. Eine über Kommandozeile übergebene Anzahl gleichzeitig eintreffender Gäste (Threads) möchte das letzte verfügbare Einzelzimmer (statische Methode visit) besuchen.

Kritik am synchronized-Ansatz:

positiv

1. Einfache Durchführbarkeit
2. Deklarativ

negativ

1. Sperrgranularität fixiert auf Methodengröße
2. Auswirkungen auf Laufzeit
3. Inflexibilität hinsichtlich Anzahl der nebenläufigen Zugriffe (immer auf 1 fixiert)

Idee: Behebung des negativen Aspekts (1) unter Beibehaltung der Vorteile (1) und (2).

Lösung: Das bereits bekannte Schlüsselwort synchronized kann innerhalb von Methodenrümpfen zur Bildung synchronisierter Anweisungsblöcke eingesetzt werden.
Hierbei können nebenläufige Zugriffe auf den Block bezüglich eines beliebigen Objekts serialisiert werden.

Anwendungsbeispiel: In Zeile 46 wird durch das Schlüsselwort synchronized ein entsprechender Block geöffnet.
Aufgrund der Restriktion Zugriffe nur hinsichtlich von Objekten serialisieren zu können muß die bisherige Implementierung modifiziert werden.
So muß die als kritische Ressource anzusehende Variable value zwingend als Objekt repräsentiert werden.
Hierzu wird ab Zeile 89 die Klasse myInteger definiert, die als Prototyp einen int-Wert kapselt. Die Zählerzugriffe werden daher entsprechend umgesetzt.

Äquivalenz der beiden Varianten: Die Wirkung einer synchronized-Methode entspricht einem synchronized-Block, der den gesamten Methodenrumpf umfaßt und bezüglich dem this-Objekt zugriffsserialisiert wird.

Die Formulierungen:

public synchronized void foo()
    {
        //...
    } //foo()

und

public void foo()
    {
        synchronized(this)
        {
            //...
        } //synchronized
    } //foo()

sind daher gleichwertig.

Wirkung der Synchronisationsprimitive synchronized : Die Zugriffsserialisierung mit synchronized erfolgt immer auf Klassen- (für statische Methoden) bzw. auf Objektebene (für Instanzmethoden), trotz der methoden- oder blockspezifischen Schlüsselwortverwendung.
Insbesondere bei Klassen mit umfangreichem Methodenangebot kann dies signifikant negative Auswirkungen auf die Laufzeit haben.

Anwendungsbeispiel: Das Beispiel definiert zwei statische Methoden (visitRoom in Zeile 27 und eat in Zeile 43).
Beide werden durch nebenläufig ausgeführte Threads unabhängig voneinander aufgerufen.

Beobachtung: Trotz des unabhängigen nebenläufigen Aufrufs der beide Methoden werden zu keinem Beobachtungszeitpunkt die Rümpfe beider Methoden ausgeführt.

Folgerungen:

1. Als synchronized deklarierte Methoden werden immer klassenbasiert sychronisiert, auch wenn sie auf einem Objekt aufgerufen werden.
2. Die mit synchronized einhergehenden Sperren werden klassenbasiert (für statische Methoden) und objektbasiert (für Instanzmethoden) verwaltet.
   So können lediglich je eine statische und ein Instanzmethode einer Klasse nebenläufig ausgeführt werden.

Aussage (2) wird durch das folgende Beispiel illustriert.
Nur weil visitRoom und eat in unterschiedlichen Kontexten synchronisiert werden ist es möglich diese nebenläufig auszuführen.

Explizites Setzen einer klassenbasierten Sperre: durch die Angabe des Klassenobjektes ( Klassenname.class) als Argument des synchronized-Blocks kann expliziter Zugriff auf die klassenbasierte Sperre erlangt werden.
Das nachfolgende Beispiel zeigt diesen Zugriff in Zeile Zeile 49. Die gewählte Konstellation gestattet die nebenläufige Ausführung der beiden Methoden visitRoom und eat, was an der Ausgabekonstellation thread named Thread-X entered room -- thread named Thread-1 is eating abzulesen ist.

Folge in der Praxis: Oftmals wird entweder die Klassensperre zur einfachen Gewinnung einer zweiten Sperre für ein Objekt mißbraucht oder künstliche Serviceobjekte erzeugt, die später als Argumente für synchronized-Blöcke dienen, nur um Zugriff auf ihre Klassensperren zu erlangen.

Anwndungsbeispiel aus der Java-API:

1. Seit JDK v1.2 steht die Klasse Vector (Quellcode ansehen) (JavaDoc) in einer hinsichtlich nebenläufiger Zugriffe abgesicherten Implementierung zur Verfügung.
2. Für die Klasse HashMap wird hingegen, wie für alle Klassen des Collection Frameworks, die Zugriffsserialisierung dem Anwender überlassen (Quellcode ansehen) (JavaDoc) .

Zusammenfassung: Die verschiedenen Ausprägungen des Schlüsselwortes synchronized können eingesetzt werden um wirkungsvoll die gleichzeitige Abarbeitung von Anweisungsfolgen durch mehr als genau einen Thread zu verhindern.
Auf diesem Wege läßt sich die konsistente Datenbereitstellung auf dem Wege strikter Serialisierung der Aufrufer eines kritischen Abschnitts realisieren.
Die Synchronisation ist dabei als wechselseitiger Ausschluß realisiert.

Der Einsatz des Schlüsselwortes synchronized bietet zwar einen leistungsfähigen Mechanismus zur Realisierung des wechselseitigen Ausschlusses an kritischen Abschnitten an. Jedoch treten bei der Realisierung praktischer Probleme zwei entscheidende Einschränkungen zu Tage.

1. Der wechselseitige Ausschluß läßt den Eintritt nur genau eines Threads in einen kritischen Bereich zu.
2. Die Realisierung der Warteschlangenverwaltung muß durch den Programmierer erfolgen.
3. Der Einsatz von synchronized bedingt häufig aktives Warten und damit keinen effizienten Umgang mit Ressource CPU.

Anschauungsbeispiel: Das Hotel der vorangegangenen Beispiele wird auf reale Gegebenheiten adaptiert. Nun sollten zehn gleichzeitig bewohnbare Zimmer sowie ein Speisesaal mit 20 Plätzen zur Verfügung stehen.
Gäste denen kein Zimmer oder Sitzplatz zur Verfügung steht, warten geduldig bis dies der Fall ist.

Mit den bishererfügbaren Synchronisationsprimitiven ist dieses Ziel kaum sinnvoll zu erreichen ...

• Einführung einer zusätzlichen Methode zur Anfrage nach knappen Ressourcen.
• Die Implementierung der Anfrage nach den knappen Ressourcen ist strukturell identisch.
• Mehrere synchronized-Routinen behindern sich gegenseitig.
• Die Umsetzung der Warteschlange ist aufwendig.
• Mehrere kritische Abschnitte existieren verteilt im Programm.

Das bekannte Konzept der Semaphore räumt mit zwei Restriktionen des wechselseitigen Ausschlusses durch synchronized aus:

1. Der Limitierung der Sperren auf jeweils eine Klassen- und eine Objektsperre.
2. Der Limitierung der gleichzeitigen Zugriffe auf genau einen, sofern dies gewünscht ist.

Implementierung durch eine eigenständige Java-Klasse:

Eine einfache Erweiterung des klassischen Semaphormechanismus stellt der Übergang von der skalaren Sperrvariablen s zu einem strukturierten Sperrobjekt dar:

Das Beispiel verwaltet den wechselseitigen Ausschluß beim Zugriff auf ein int-Feld. Die Methode changeValues vereinigt die Eigenschaften der klassischen p-Operation und v-Operation in sich.
Hierdurch wird jedoch die korrekte Behandlung der Sperrvariablenstände zurück zum Anwendungsprogrammierer verlagert!

Anwendungsbeispiel:

Im Beispiel werden zur Synchronisation die bekannten Primitive verwendet. Zur Realisierung der Warteschlangen werden zwei neue Methoden eingesetzt wait() und notify.

Die Methode wait() veranlaßt einen Thread auf ein Signal einer anderen Ausführungseinheit zu warten.
Signalisiert ein Thread durch notify() das Eintreten eines gewissen Zustandes, so wird der durch Aufruf von wait blockierte Thread geweckt und fährt in seiner Berechnung fort.
notify stellt somit eine einfache Möglichkeit der Inter-Threadkommunikation dar.

wait und notify sind selbst kritische Operationen und müssen daher in synchronized-Abschnitte oder -Methoden eingebettet werde.

Es ist leicht einzusehen, daß der Zugriff auf die Sperrvariable s in den Zeilen 13, 25 und 25 selbst einen kritischen Abschnitt darstellt und daher synchronisiert werden muß.
Der Rückgriff auf das bekannte Schlüsselwort synchronized löst das sich ergebende Synchronisationsproblem jedoch strenggenommen nicht, sondern verlagert es in die Hochsprachenebene und delegiert somit die korrekte Durchführung der Synchronisation an Übersetzer und Laufzeitsystem.

Probleme beim Einsatz von wait und notify: Der Aufruf des Methodenpaars wait-notify ist selbst laufzeitkritisch hinsichtlich der Reihenfolge der Aufrufe. In nebenläufigen Ausführungsumgebungen können Bedingungen eintreten, in denen ein Thread sein notify vor dem (eigentlich) zugehörigen wait des zu verzögernden Threads aufruft.

Der Aufruf java MissedNotify 0 50 liefert:

sleeping 'til notification ...
Trying to awake ...
notified and awaked

java MissedNotify 100 50 hingegen sorgt dafür, daß notify vor wait erreicht wird:

Trying to awake ...
sleeping 'til notification ...
An InterruptedException caught
null
java.lang.InterruptedException
        at java.lang.Object.wait(Native Method)
        at java.lang.Object.wait(Object.java:426)
        at Sleeper.goToSleep(MissedNotify.java:64)
        at Sleeper.run(MissedNotify.java:41)
        at java.lang.Thread.run(Thread.java:536)

Als Lösung bietet es sich an, den Aufruf von wait in eine while-Schleife zu kleiden, die prüft, ob die Bedingung für den Eintritt in den Wartezustand vorliegt.
Im Beispiel ist dies durch die Variable sleeping in LockObj umgesetzt.
Der bedingte Aufruf von while findet sich ab Zeile 64.

Innerhalb der Java-Laufzeitumgebung werden Monitore als Hochsprachensynchronisationsprimitive eingesetzt. (siehe C. A. R. Hoare: Monitors: An Operating System Structuring Concept, Communications of the ACM, Vol. 17, No. 10, Oct. 1974, pp. 549--557).
Diese werden durch die beiden Bytecodeinstruktionen monitorenter und monitorexit direkt von der virtuellen Maschine unterstützt.

Abbildung skizziert das Verhalten der virtuellen Maschine bei einer monitorbasierten Synchronisation mittels wait und notify.

Thread-2 is sleeping
Thread-1 is sleeping
Thread-1 requests resource #0
Thread-2 requests resource #0
Thread-1 locks resource #0
Thread-1 requests resource #1
Thread-1 locks resource #1
Thread-1 released resource #1
Thread-1 released resource #0
Thread-2 locks resource #0
Thread-2 requests resource #1
Thread-2 locks resource #1
Thread-2 released resource #1
Thread-2 released resource #0
[Programmende]

Thread-1 is sleeping
Thread-2 is sleeping
Thread-2 requests resource #0
Thread-1 requests resource #1
Thread-2 locks resource #0
Thread-1 locks resource #1
Thread-2 requests resource #1
Thread-1 requests resource #0
[Programmstillstand, keine weiteren Ausgaben]

(Thread-2) accounts[4] --40.66333304967762--> accounts[2] started
(Thread-8) accounts[3] --366.4855767109112--> accounts[1] started
(Thread-6) accounts[1] --502.98046127613713--> accounts[4] started
(Thread-10) accounts[4] --184.08552879039075--> accounts[0] started
(Thread-4) accounts[2] --292.5794829489161--> accounts[3] started
(Thread-1) accounts[0] --714.5208007641102--> accounts[4] started
(Thread-7) accounts[0] --170.7740899847421--> accounts[1] started
(Thread-9) accounts[2] --720.4974239388226--> accounts[3] started
(Thread-5) accounts[0] --44.318640244877415--> accounts[2] started
(Thread-3) accounts[1] --390.3961760904666--> accounts[0] started
(Thread-2) account[4] locked
(Thread-8) account[3] locked
(Thread-6) account[1] locked
(Thread-4) account[2] locked
(Thread-1) account[0] locked
[Programmstillstand, keine weiteren Ausgaben]

...
Thread-41 entered add of number c1
Thread-41 entered getRealPart of number c1
Thread-41 entered getRealPart of number c2
Thread-41 calculated real part of number c1
Thread-41 entered getImaginaryPartof number c1
Thread-41 entered getImaginaryPartof number c2
Thread-41 left add of number c1
(Thread-41) 1+i2 + 2+i1 = 3+i3
Thread-144 entered add of number c2
Thread-144 entered getRealPart of number c2
Thread-144 entered getRealPart of number c1
Thread-144 calculated real part of number c2
Thread-144 entered getImaginaryPartof number c2
Thread-144 entered getImaginaryPartof number c1
Thread-144 left add of number c2
(Thread-144) 2+i1 + 1+i2 = 3+i3
Thread-132 entered add of number c2
Thread-132 entered getRealPart of number c2
Thread-129 entered add of number c1
Thread-129 entered getRealPart of number c1
[Programmstillstand, keine weiteren Ausgaben]

Philosopher #1 is thinking
Philosopher #3 is thinking
Philosopher #2 is thinking
Philosopher #2 received left fork
Philosopher #1 received left fork
Philosopher #3 received left fork
[Programmstillstand, keine weiteren Ausgaben]

Thread-1 is sleeping
Thread-2 is sleeping
Thread-1 requests resources [0,1]
Thread-2 requests resources [1,0]
Thread-1 locks resources [0,1]
Thread-2 locks resources [1,0]
Thread-1 requests resources [1,0]
Thread-2 requests resources [0,1]
[Programmstillstand, keine weiteren Ausgaben]

$java PriorityExample 10000000
Thread with priority 10 took 110ms
Thread with priority 8 took 109ms
Thread with priority 5 took 313ms
Thread with priority 9 took 344ms
Thread with priority 6 took 110ms
Thread with priority 7 took 109ms
Thread with priority 3 took 500ms
Thread with priority 4 took 188ms
Thread with priority 1 took 141ms
Thread with priority 2 took 140ms

$java PriorityExample 5000000000
Thread with priority 10 took 56219ms
Thread with priority 9 took 86578ms
Thread with priority 8 took 117844ms
Thread with priority 6 took 162438ms
Thread with priority 7 took 177562ms
Thread with priority 5 took 220375ms
Thread with priority 4 took 245391ms
Thread with priority 3 took 274703ms
Thread with priority 1 took 317985ms
Thread with priority 2 took 340781ms

$java DaemonDemo 100 10
Daemon's counter state: 1
Daemon's counter state: 2
Daemon's counter state: 3
Daemon's counter state: 4
Daemon's counter state: 5
Daemon's counter state: 6
Daemon's counter state: 7
Daemon's counter state: 8
Normal's counter state: 1
Normal's counter state: 2
Normal's counter state: 3
Normal's counter state: 4
Normal's counter state: 5
Normal's counter state: 6
Normal's counter state: 7
Normal's counter state: 8
Normal's counter state: 9
Normal's counter state: 10
Daemon's counter state: 9
Daemon's counter state: 10
Daemon's counter state: 11
Daemon's counter state: 12
Daemon's counter state: 13
Daemon's counter state: 14
Daemon's counter state: 15
Daemon's counter state: 16
Daemon's counter state: 17