Résumé des compétences Java : Comment lire le code source Lambda

Cet article vous apporte des connaissances pertinentes sur java, qui présente principalement des problèmes liés à la façon d'afficher le code source Lambda. L'utilisation d'expressions Lambda peut effectuer de nombreuses optimisations de code, et vous pouvez faire beaucoup avec seulement quelques lignes de code. Jetons un coup d'œil aux éléments ci-dessous, j'espère que cela sera utile à tout le monde.

Étude recommandée : "Tutoriel vidéo Java"

Tout le monde sait que les expressions Lambda sont ajoutées dans Java8. L'utilisation d'expressions Lambda peut effectuer de nombreuses optimisations de code, et vous pouvez faire beaucoup de choses avec seulement quelques-unes. lignes de code. , ce chapitre prend Lambda comme exemple. La première section explique son principe d'exécution sous-jacent et la deuxième section explique les postures couramment utilisées du flux Lambda dans le travail.

1. Démo

Tout d'abord, jetons un coup d'œil à une démo de l'expression Lambda, comme indiqué ci-dessous :

Le code est relativement simple, il suffit de démarrer un nouveau fil de discussion pour imprimer une phrase, mais for () dans l'image -> System.out.println (« lambda est exécuté ») est un code que de nombreux étudiants peuvent trouver déroutant. Comment Java reconnaît-il ce code ?

Si nous changeons l'écriture en classe interne anonyme, elle sera très claire et tout le monde pourra la comprendre, comme indiqué ci-dessous :

Cela signifie-t-il () -> " ) Cette forme de code crée en fait une classe interne ? En fait, il s'agit de l'expression Lambda la plus simple. Nous ne pouvons pas voir le code source et sa structure sous-jacente via IDEA. Nous allons présenter ici plusieurs façons de voir son implémentation sous-jacente.

2. Méthode de jugement d'exception

Nous pouvons lancer activement des exceptions pendant l'exécution du code et imprimer la pile expliquera sa trajectoire d'exécution. Généralement, cette méthode est simple et efficace, et vous pouvez essentiellement voir le code caché dans de nombreux. situations. Essayons, comme indiqué ci-dessous :

Depuis la pile d'exceptions, nous pouvons voir que la JVM a automatiquement créé une classe interne pour la classe actuelle ($ apparaissant plusieurs fois dans la pile d'erreurs indique qu'il existe une classe interne. classe), et la classe interne Lors de l'exécution du code, une exception a été levée, mais le code affiché ici est de source inconnue, nous ne pouvons donc pas le déboguer. Dans des circonstances normales, les exceptions peuvent exposer le chemin d'exécution du code que nous pouvons définir. points d'arrêt et exécutez à nouveau, mais pour les expressions Lambda, grâce à la méthode de jugement d'exception, nous savons seulement qu'il existe une classe interne, mais nous ne pouvons pas voir le code source dans la classe interne.

3. Méthode de commande javap

javap est un outil fourni avec Java qui peut afficher les fichiers de bytecode de classe. Les ordinateurs qui ont installé l'environnement de base Java peuvent exécuter directement la commande javap, comme indiqué ci-dessous :

options de commande. , nous utilisons principalement la commande -v -verbose pour afficher complètement le contenu du fichier de bytecode.

Ensuite, nous utilisons la commande javap pour afficher le fichier Lambda.class. Au cours de l'explication, nous apporterons quelques connaissances sur les fichiers de classe.

Nous trouvons l'emplacement de Lambda.class dans la fenêtre de commande, exécutons la commande : javap -verbose Lambda.class, et ensuite vous verrez une longue liste de choses, celles-ci sont appelées instructions d'assemblage, expliquons-les une par une ( Tous les matériaux de référence proviennent de la spécification Java Virtual Machine et ne seront pas cités un par un) :

Dans les instructions d'assemblage, nous pouvons facilement trouver une longue liste de types commençant par Constant pool. Nous l'appelons le pool constant. Le nom anglais est Run-Time Constant Pool. Nous le comprenons simplement comme un tableau rempli de constantes. Le tableau contient des nombres et du texte clairs au moment de la compilation, des informations de type sur les classes, les méthodes et les champs, etc. Chaque élément du tableau est appelé cpinfo. cpinfo se compose d'un identifiant unique (balise) + nom. Actuellement, il existe un total de types de balises :

Partie publiée de l'image que nous avons analysée :

.

1. Le mot « Pool constant » dans l'image signifie que les informations actuelles sont un pool constant

2. Chaque ligne est un cp_info, et le #1 dans la première colonne représente la position marquée 1 dans la constante ; piscine;

3. La deuxième colonne de chaque ligne est l'identifiant unique (balise) de cp_info Par exemple, Methodref correspond à CONSTANT_Methodref dans le tableau ci-dessus (la valeur dans le tableau ci-dessus correspond à la balise de 10). ), qui représente La ligne actuelle représente les informations de description de la méthode, telles que le nom de la méthode, le type de paramètre d'entrée, le type de paramètre de sortie, etc. La signification spécifique peut être trouvée dans la spécification de la machine virtuelle Java. La capture d'écran de Methodref est la suivante. suit :
   cp_info 的唯一标识 ( tag ) ，比如 Methodref 对应着上表中的 CONSTANT_Methodref（上上图中表格中 value 对应 10 的 tag），代表当前行是表示方法的描述信息的，比如说方法的名称，入参类型，出参数类型等，具体的含义在 Java 虚拟机规范中都可以查询到，Methodref 的截图如下：
   

4. 每行的第三列，如果是具体的值的话，直接显示具体的值，如果是复杂的值的话，会显示 cp_info 的引用，比如说图中标红 2 处，引用两个 13 和 14 位置的 cp_info

5. Dans la troisième colonne de chaque ligne, s'il s'agit d'une valeur spécifique, la valeur spécifique sera affichée directement. S'il s'agit d'une valeur complexe, une référence à cp_info. sera affiché. Par exemple, dans l'image marquée en rouge 2, la référence Il y a deux cp_info aux positions 13 et 14. 13 signifie que le nom de la méthode est init, et 14 signifie que la méthode n'en a pas. valeur de retour. La combinaison du nom et du type de retour de la méthode signifie qu'il s'agit d'un constructeur sans paramètre

La quatrième colonne de chaque ligne est la valeur spécifique ;

1. Pour le type cp_info le plus important, nous expliquerons sa signification :
2. InvokeDynamic représente la méthode d'appel dynamique, que nous expliquerons en détail plus tard
3. Fieldref représente les informations de description du champ, comme le nom ; et le type du champ ;
4. NameAndType est une description du champ et du type de méthode ;
5. MethodHandle, le nom collectif des méthodes d'appel dynamiques. Nous ne savons pas quelle méthode est spécifique au moment de la compilation, mais nous le ferons certainement. savoir quelle méthode est appelée au moment de l'exécution ;

Les types de méthode dynamique MethodType ne connaissent leurs types de méthode que lorsqu'ils sont exécutés dynamiquement.

À partir des 3 endroits marqués en rouge dans l'image ci-dessus, nous avons trouvé Ljava/lang/invoke/MethodHandles$Lookup, java/lang/invoke/LambdaMetafactory.metafactory et des codes similaires comme celui-ci MethodHandles et LambdaMetafactory sont tous deux java.lang. Packages .invoke. Les méthodes importantes suivantes, le package Invoke implémente principalement les fonctions des langages dynamiques. Nous savons que le langage Java est un langage compilé statique, les types de classes, méthodes, champs, etc. et invoquer implémente un langage dynamique, c'est-à-dire que les types de classes, de méthodes et de champs ne sont pas connus lors de la compilation. Ils ne le sont que lors de l'exécution.

Par exemple, cette ligne de code : Runnable runnable = () -> System.out.println("lambda is run"); Lorsque le compilateur compile (), le compilateur ne sait pas ce que fait ce support, il fonctionne lorsqu'il est en cours d'exécution. Ce n'est qu'alors que vous réaliserez que cela représente la méthode Runnable.run(). De nombreuses classes du package Invoke sont conçues pour représenter ces (), que nous appelons des handles de méthode (MethodHandler). Lors de la compilation, le compilateur sait seulement qu'il s'agit d'un handle de méthode et ne sait pas quelle méthode est réellement exécutée. Je ne le sais pas jusqu'au moment, donc la question est, lorsque la JVM s'exécute, comment sait-elle que le handle de la méthode () exécute réellement la méthode Runnable.run() ?

Tout d'abord, jetons un coup d'œil aux instructions d'assemblage de la méthode simple :

Sur l'image ci-dessus, vous pouvez voir le () dans la méthode simple -> System.out.println("lambda est exécuté ") dans le code ( ), est en fait la méthode Runnable.run.

Nous remontons au pool constant n°2, qui est marqué en rouge 1 dans l'image ci-dessus. InvokeDynamic indique qu'il s'agit d'un appel dynamique. L'appel est le cp_info des deux pools constants. .Regardons en bas# 37 représente // run:()Ljava/lang/Runnable, ce qui indique que lorsque la JVM est réellement exécutée, la méthode Runnable.run() doit être appelée dynamiquement. À partir des instructions d'assemblage, nous pouvons voir. that () est en fait Runnable .run(), déboguons ci-dessous pour le prouver.

Nous avons trouvé les mots LambdaMetafactory.metafactory à 3 endroits dans l'image ci-dessus. En interrogeant la documentation officielle, nous avons appris que cette méthode est la clé pour créer un lien vers le code réel lors de l'exécution, nous avons donc défini un point d'arrêt dans la méthode métafactory pour debug Comme indiqué ci-dessous :

le paramètre d'entrée de la méthode métafactory l'appelant représente l'emplacement où l'appel dynamique se produit réellement, invoquéNom représente le nom de la méthode appelante, invoquéType représente les multiples paramètres d'entrée et les paramètres sortants de l'appel, samMethodType représente le paramètres de l'implémenteur spécifique, implMethod représente l'implémenteur réel, instantiatedMethodType est équivalent à implMethod.

Pour résumer le contenu ci-dessus :

1 : À partir de la méthode simple de l'instruction d'assemblage, nous pouvons voir que la méthode Runnable.run sera exécutée

2 : Pendant l'exécution réelle, lorsque la JVM rencontre l'instruction d'invocation dynamique ; de la méthode simple, il appellera dynamiquement la méthode LambdaMetafactory.metafactory et exécutera la méthode Runnable.run spécifique. 🎜🎜Ainsi, l'exécution spécifique de la valeur de l'expression Lambda peut être attribuée à l'instruction JVM Invocationdynamic. C'est précisément grâce à cette instruction que même si vous ne savez pas quoi faire lors de la compilation, vous pouvez trouver le code spécifique à exécuter lors de la compilation. exécution dynamique. 🎜

Jetons ensuite un coup d'œil à la fin du résultat de l'instruction d'assemblage. Nous avons trouvé la classe interne trouvée dans la méthode de jugement d'exception, comme indiqué ci-dessous :

Il y a de nombreuses flèches dans l'image ci-dessus, ainsi que le layer-by. L'expression -layer exprime clairement la classe interne actuelle. Toutes les informations.

4. Résumé

Résumons, l'exécution d'expressions Lambda repose principalement sur l'instruction JVM d'invocationdynamic. Le chemin complet de la classe que nous démontrons est : demo.eight.Lambda.

Sans plus attendre, l'article est terminé, hâte de découvrir la troisième série !

Apprentissage recommandé : "Tutoriel vidéo Java"

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!