Der Einsatzkontext von Java-Software hat sich seit Einführung der Plattform radikal verschoben: während zu Beginn Java-Programme als sichere, portable, ausführbare Inhalte im Kontext von Webseiten, sogenannte ,,Applets``, positioniert waren, ist der Erfolg dieser Plattform auf ein anderes Umfeld zurückzuführen. Allgemein vorteilhafte Eigenschaften der Sprache wie starke Typisierung, automatische Speicherverwaltung, dynamisches Laden von Programmfragmenten, hohe Portabilität und andere haben Java zur Plattform der Wahl für Serversoftware gemacht.
Serverprogramme stellen per se nebenläufige Software dar, denn sie müssen mehrere Client-Programme gleichzeitig bedienen können. Für Server der oberen Leistungsklasse sind daher mehrere hundert nebenläufige Threads nicht ungewöhnlich. Gleichzeitig ist die effiziente Nutzung leistungsfähiger Hardware von eminenter Wichtigkeit: die verwendete Hardwareplattform stellen immer häufiger Multiprozessorsysteme mit bis zu 64 Prozessoren und gemeinsamen Speicher dar [Lenoski and Weber, 1995].
Obwohl die Java-Synchronisierungskonstrukte vom Mechanismus her keine Neuerung darstellen, so erfordern zwei Umstände, daß der Implementierung dieser Konstrukte besondere Aufmerksamkeit gewidmet werden muß:
Hieraus ergeben sich folgende Konsequenzen: ein Java-Programm erzeugt eine enorme Anzahl von Monitoren, von denen -- mit Ausnahme einiger Bibliotheksobjekte -- nur ein kleiner Anteil tatsächlich zur Synchronisierung verwendet wird. [Agesen et al., 1999] und [Onodera and Kawachiya, 1999] nennen übereinstimmend eine Rate von 8-12% in einer Reihe von Benchmarks. [Dieckmann and Hölzle, 1998] messen eine durchschnittliche Objektgröße von 20 Bytes für eine Reihe von Java-Anwendungen. Würde für jedes Objekt nur ein Wort zur Synchronisierung reserviert, ergäbe sich bereits ein Anstieg der Heapgröße um 20% für zumeist ungenutzte Monitore. Es folgt, daß der benötigte Platz für eine Monitorimplementierung sinnvollerweise nur für die aktuell synchronisierten Objekte bereitgestellt werden darf.
Weiterhin wird die Mehrzahl der synchronisierten Objekte -- vielfach aus Basisbibliotheken -- tatsächlich nur von einem Thread benutzt. [Onodera and Kawachiya, 1999] ermitteln, daß weniger als 2% aller synchronisierten Objekte tatsächlich einen Konflikt auflösen. Aufgrund ,,großzügiger`` Synchronisierung werden zudem Monitore häufig rekursiv erworben. Die Optimierung solcher ,,präventiven`` Synchronisierungsoperationen hinsichtlich ihrer Geschwindigkeit verspricht daher einen großen Effizienzgewinn.