Durch klar definierte und einfache Konstrukte und deren enge Integration in den Sprachstandard ermuntert die Java-Plattform zu einem großzügigen Umgang mit nebenläufigen Konstrukten. Werden beispielsweise im Kontext des Pthread-Standards Programme mit einer Vielzahl von Threads oftmals als Indiz schlechten Softwaredesigns angesehen, so befindet sich diese Klasse von Software ausdrücklich im Zielkreis moderner Java-Implementierungen.
Notwendigerweise muß eine Abstraktion der wenigen konkreten Ausführungseinheiten der Maschine hin zu der Vielzahl oftmals kurzlebiger Threads stattfinden. Dies geschieht am effizientesten durch eine mehrstufige Architektur mit einer ausdrucksstarken Schnittstelle zwischen Betriebssystemkern und Anwendungsprogramm.
Während einige Betriebssysteme eine solche Architektur bereits in Form von Bibliotheken realisieren, gilt dies für mehrere wichtige Plattformen nicht; die fehlende Scheduler-Komponente der Anwendungsschicht sollte hier durch die VM implementiert werden. Eine kommerzielle Java-Implementierung demonstriert eindrucksvoll die Skalierbarkeit dieses Ansatzes in einem thread-lastigen Benchmark5.4.
Die Entwicklung eines VM-eigenen auf Anwendungsebene implementierten Schedulers bringt weitere Vorteile gegenüber der Nutzung generischer Systembibliotheken mit sich. Kontextwechsel nur an dedizierten Punkten zu vollziehen, verringert Unterbrechungen durch Garbage Collection auf ein Minimum. Es bleibt offen, ob diese Vorteile die Komplexität einer eigenen Scheduler-Komponente rechtfertigen. Unter Umständen werden die Thread-Bibliotheken der Betriebssysteme entsprechend erweiterte Schnittstellen aufweisen.
Der Implementierung von Synchronisierungsoperationen gebührt besondere Aufmerksamkeit. Dem bedarfsgesteuerten Einsatz von Synchronisierungsobjekten wie ,,Pthread Mutex`` oder ,,Smalltalk Semaphoren`` steht die Ubiquität von Java Monitoren entgegen. Außerdem entstehen durch Bibliotheksabstraktionen viele unnötige Synchonisierungsoperationen.
Jedes Objekt mit einer vollständigen Monitorimplementierung auszustatten, verbietet sich aus Platzgründen. Eine externe Zuordnung durch Tabellen hat Effizienzprobleme. Eine einfache Monitorimplementierung auf Basis von Systemabstraktionen scheidet daher aus. Vielmehr sind platzeffiziente Kodierungsschemata innerhalb der Objektrepräsentation zu finden. Insbesondere das überwiegende Auftreten konfliktfreier Monitore mit maximal einem Erwerber bietet Raum für Optimierungen. Die bimodale Nutzung des Objektheaders etabliert sich hier als Standard-Algorithmus.
In Hinsicht auf die aufgezeigten Implementierungsoptionen stehen die Java Synchronisierungsoperationen zu Unrecht in der Kritik, ineffizient zu sein. Im Hinblick auf Optimierungen im Rahmen des Speichermodells wird deutlich, wie gefährlich der Versuch ist, an korrekter Synchronisierung ,,vorbeizuprogrammieren``.
Die Nutzung von Systemthreads für Nebenläufigkeit anstatt oder in Kombination mit einem im user space realisierten Scheduler hat eine bedeutsame Konsequenz: sie führt zu Nebenläufigkeit innerhalb des Laufzeitsystems. Folglich sind Dienste wie die Speicherverwaltung thread-sicher zu implementieren; trotzdem darf ein derart stark frequentierter Dienst nicht übermäßig synchronisieren. Auch die sichere Manipulation generierten Maschinencodes durch den Übersetzer ist eine Herausforderung im Kontext von Multiprozessoren und Instruktions-Caches. Diese Umstände stellen einen wichtigen Grund für die Komplexität moderner virtueller Maschinen dar. Angesichts der Tatsache, daß Uniprozessoren weiterhin eine wichtige Plattform für Java-Software darstellen, stellt sich die Frage, ob dort nicht alternative Architekturen wie z.B. die der VisualWorks Smalltalk VM zu erwägen sind.
