Les méthodes de cache Java 8 font-elles référence et quand devriez-vous envisager de les mettre en cache ?

Méthode de mise en cache de référence dans Java 8 : un examen détaillé

Introduction

Lorsque vous travaillez avec Les références aux méthodes de Java 8, une question se pose concernant les avantages potentiels de la mise en cache. Cet article explore les implications de la mise en cache des références de méthodes et fournit des conseils sur les cas où cela peut être avantageux.

Distinguer l'exécution d'un site d'appel et d'une référence de méthode

Il est crucial de différencier entre les exécutions fréquentes du même site d'appel avec des lambdas sans état ou avec état et les utilisations fréquentes de références de méthode à la même méthode par différents sites d'appel.

Exemple d'analyse

Considérez les exemples suivants :

Runnable r1 = null;
for (int i = 0; i <p>Ici, le même site d'appel est exécuté deux fois, produisant un lambda sans état, et l'implémentation affichera "shared".</p><pre class="brush:php;toolbar:false">Runnable r1 = null;
for (int i = 0; i <p>Avec cet exemple, le même site d'appel est exécuté deux fois, produisant un lambda contenant une référence à une instance du Runtime, et l'implémentation affichera "non partagé" mais "classe partagée".</p><pre class="brush:php;toolbar:false">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");

En revanche, le dernier exemple inclut deux sites d'appel distincts produisant une référence de méthode équivalente, mais à partir de Java 8.0.05, elle affichera "non partagé" et "classe non partagée".

JVM Comportement

La machine virtuelle Java (JVM) joue un rôle important dans la gestion des références de méthodes. Il utilise une instruction d'invocation dynamique, qui fait référence à une méthode d'amorçage JRE dans LambdaMetafactory. Le compilateur fournit les arguments nécessaires pour générer la classe d'implémentation lambda.

La JVM a la flexibilité de mémoriser et de réutiliser l'instance CallSite formée lors du premier appel. Pour les lambdas sans état et les sites d'appel uniques, la JVM crée généralement un ConstantCallSite comprenant un MethodHandle vers un objet constant.

D'autre part, pour les lambdas avec des paramètres (par exemple, this::func), la JVM peut mettez-les en cache, mais cela implique une surcharge supplémentaire liée au maintien d'une carte entre les paramètres et les instances lambda. Actuellement, la JVM ne met pas en cache ces lambdas. Ce comportement s'applique de la même manière aux références de méthode à la même méthode cible créées par différents sites d'appel.

Considérations sur la mise en cache

Sur la base des points susmentionnés, les références de méthode de mise en cache peuvent donner des résultats différents, mais pas nécessairement de meilleures performances. L'impact sur les performances doit être mesuré avant de mettre en œuvre des mécanismes de mise en cache. Il existe des cas spécifiques où la mise en cache peut être bénéfique :

• Lorsque plusieurs sites d'appel font référence à la même méthode
• Lorsque le lambda est créé dans le constructeur/classe initialiser
• Lorsque le site d'utilisation sera exécuté simultanément par plusieurs threads
• Lorsque les performances inférieures de la première invocation lambda sont un préoccupation

Conclusion

La mise en cache des références de méthode peut être une technique d'optimisation dans certains scénarios. Cependant, la décision de mettre en cache doit être basée sur une analyse minutieuse du code et des exigences de performances spécifiques. La gestion des références de méthode par la JVM fournit une base solide pour optimiser l'utilisation de lambda et des références de méthode dans Java 8.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!