Comment lire le code source Lambda en Java

1. Démo

Tout d'abord, regardons 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 pour l'image () -> System.out.println (« lambda est exécuté ») Ce type de code est probablement très déroutant pour de nombreux étudiants. Comment Java reconnaît-il ce type de 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 :

Est-ce que cela signifie () -> " ) 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 :

Dans le 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 documents 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, on peut facilement trouver une longue liste de types commençant par Constant pool, que nous appelons le pool constant, et le nom anglais officiel 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 numéro 1 dans la première colonne représente le position de l'indice du pool constant 1 ; cp_info ，第一列的 #1 代表是在常量池下标为 1 的位置 ；

3. 每行的第二列，是 cp_info 的唯一标识 ( tag ) ，比如 Methodref 对应着上表中的 CONSTANT_Methodref（上上图中表格中 value 对应 10 的 tag），代表当前行是表示方法的描述信息的，比如说方法的名称，入参类型，出参数类型等，具体的含义在 Java 虚拟机规范中都可以查询到，Methodref 的截图如下：
   

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

5. 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 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 le virtuel Java spécification de la machine. La capture d'écran de Methodref est la suivante :

   

La troisième colonne de chaque ligne, si elle est spécifique. Si c'est une valeur, la valeur spécifique sera affichée directement. Si c'est une valeur complexe, la référence à cp_info sera affiché. Par exemple, la marque rouge 2 dans l'image fait référence à deux cp_info, 13 signifie que le nom de la méthode est init, 14 signifie que la méthode n'a pas de retour. value, et la combinaison du nom de la méthode et du type de retour est un constructeur sans paramètre ;

🎜🎜🎜La quatrième colonne de chaque ligne est la valeur spécifique . 🎜🎜🎜🎜Pour le type cp_info le plus important, nous expliquons sa signification : 🎜

1. InvokeDynamic représente la méthode d'appel dynamique, que nous expliquerons en détail plus tard

2. Fieldref représente les informations de description du champ, telles que le nom et le type du champ ; le champ et le type de méthode ;

MethodHandle handle de méthode, le nom général des méthodes d'appel dynamiques. Nous ne savons pas quelle méthode est spécifique au moment de la compilation, mais nous saurons certainement quelle méthode est appelée au moment de l'exécution ;
3. MethodType type de méthode dynamique, ce n'est que lors d'une exécution dynamique qu'il saura quel est son type de méthode.

4. À 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 similaire à ce code, MethodHandles et LambdaMetafactory sont tous deux java.lang .invoke Méthodes importantes sous le package, le package Invoke implémente principalement les fonctions des langages dynamiques. On sait que le langage Java est un langage compilé statique. Lors de la compilation, les types de classes, méthodes, champs, etc. Invoquer implémente un langage dynamique, ce qui signifie que vous ne savez pas quels types de classes, de méthodes et de champs sont lors de la compilation, ils ne savent que lorsqu'ils sont exécutés.
   Par exemple, cette ligne de code : Runnable runnable = () -> System.out.println("lambda is run"); Lorsque le compilateur compile (), le compilateur ne sait pas à quoi sert ce support, seulement 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() ?
5. 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 pendant 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, et l'interne actuelle. la classe est exprimée clairement couche par couche toutes les informations.

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!