Methodenreferenz-Caching in Java 8: Eine detaillierte Untersuchung
Einführung
Beim Arbeiten mit Angesichts der Methodenreferenzen von Java 8 stellt sich die Frage nach den potenziellen Vorteilen des Caching. In diesem Artikel werden die Auswirkungen von Caching-Methodenreferenzen untersucht und Hinweise gegeben, wann dies von Vorteil sein kann.
Unterscheidung von Call-Site- und Methodenreferenzausführung
Es ist wichtig, zu unterscheiden zwischen häufigen Ausführungen derselben Aufrufstelle mit zustandslosen oder zustandsbehafteten Lambdas und häufigen Verwendungen von Methodenreferenzen auf dieselbe Methode durch unterschiedliche Call-Sites.
Beispielanalyse
Betrachten Sie die folgenden Beispiele:
Runnable r1 = null; for (int i = 0; i < 2; i++) { Runnable r2 = System::gc; if (r1 == null) { r1 = r2; } else { System.out.println(r1 == r2 ? "shared" : "unshared"); } }
Hier wird dieselbe Call-Site zweimal ausgeführt, was zu einem Ergebnis führt ein zustandsloses Lambda, und die Implementierung gibt „shared“ aus.
Runnable r1 = null; for (int i = 0; i < 2; i++) { Runnable r2 = Runtime.getRuntime()::gc; if (r1 == null) { r1 = r2; } else { System.out.println(r1 == r2 ? "shared" : "unshared"); System.out.println(r1.getClass() == r2.getClass() ? "shared class" : "unshared class"); } }
In diesem Beispiel ist die gleiche Call-Site zweimal ausgeführt, wodurch ein Lambda erzeugt wird, das einen Verweis auf eine Runtime-Instanz enthält, und die Implementierung gibt „nicht gemeinsam genutzt“, aber „gemeinsam genutzte Klasse“ aus.
Runnable r1 = System::gc, r2 = System::gc; System.out.println(r1 == r2 ? "shared" : "unshared"); System.out.println(r1.getClass() == r2.getClass() ? "shared class" : "unshared class");
Im Gegensatz dazu enthält das letzte Beispiel zwei separate Aufruf-Sites, die produzieren eine äquivalente Methodenreferenz, aber ab Java 8.0.05 werden „unshared“ und „unshared class“ ausgegeben.
JVM Verhalten
Die Java Virtual Machine (JVM) spielt eine wichtige Rolle bei der Handhabung von Methodenreferenzen. Es verwendet eine invokedynamic-Anweisung, die auf eine JRE-Bootstrap-Methode in LambdaMetafactory verweist. Der Compiler stellt die Argumente bereit, die zum Generieren der Lambda-Implementierungsklasse erforderlich sind.
Die JVM verfügt über die Flexibilität, sich die beim ersten Aufruf gebildete CallSite-Instanz zu merken und wiederzuverwenden. Für zustandslose Lambdas und einzelne Aufrufseiten erstellt die JVM normalerweise eine ConstantCallSite, die ein MethodHandle für ein konstantes Objekt umfasst.
Andererseits kann die JVM für Lambdas mit Parametern (z. B. this::func) möglicherweise Sie werden zwar zwischengespeichert, erfordern jedoch zusätzlichen Aufwand bei der Verwaltung einer Zuordnung zwischen Parametern und den Lambda-Instanzen. Derzeit speichert die JVM solche Lambdas nicht zwischen. Dieses Verhalten gilt in ähnlicher Weise für Methodenverweise auf dieselbe Zielmethode, die von verschiedenen Aufrufseiten erstellt wurden.
Caching-Überlegungen
Basierend auf den oben genannten Punkten können Caching-Methodenverweise zu Ergebnissen führen unterschiedliche Ergebnisse, aber nicht unbedingt bessere Leistung. Die Auswirkungen auf die Leistung sollten gemessen werden, bevor Caching-Mechanismen implementiert werden. Es gibt bestimmte Fälle, in denen Caching von Vorteil sein kann:
Fazit
Caching-Methodenreferenzen können in bestimmten Szenarien eine Optimierungstechnik sein. Die Entscheidung zum Zwischenspeichern sollte jedoch auf einer sorgfältigen Analyse des Codes und spezifischer Leistungsanforderungen basieren. Die Handhabung von Methodenreferenzen durch die JVM bietet eine solide Grundlage für die Optimierung der Verwendung von Lambda und Methodenreferenzen in Java 8.
Das obige ist der detaillierte Inhalt vonSpeichert Java 8 Methodenreferenzen im Cache und wann sollten Sie sie zwischenspeichern?. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!