Comment comprendre l'évasion en Java

Dans le système de compilation Java, le processus de transformation d'un fichier de code source Java en une instruction machine exécutable par ordinateur nécessite deux étapes de compilation. La première étape consiste à convertir le fichier .java en fichier .class. La deuxième étape de la compilation est le processus de conversion de .class en instructions machine.

La première section de compilation est la commande javac.

Lors de la deuxième étape de compilation, la JVM interprète le bytecode et le traduit en instructions machine correspondantes, le lit une par une et interprète la traduction une par une. Évidemment, après interprétation et exécution, sa vitesse d'exécution sera inévitablement beaucoup plus lente que celle du programme de bytecode binaire exécutable. C'est la fonction de l'interpréteur JVM traditionnel (Interpreter). Afin de résoudre ce problème d’efficacité, la technologie JIT (compilation juste à temps) a été introduite.

Après l'introduction de la technologie JIT, les programmes Java sont toujours interprétés et exécutés via l'interpréteur. Lorsque la JVM constate qu'une certaine méthode ou un certain bloc de code s'exécute particulièrement fréquemment, elle le considère comme un « Hot Spot Code ». Ensuite, JIT traduira une partie du « code chaud » en code machine lié à la machine locale, l'optimisera, puis mettra en cache le code machine traduit pour la prochaine utilisation.

Puisque j'ai déjà présenté le contenu de la compilation JIT et de la détection des hotspots dans mon analyse approfondie des principes de compilation Java, je n'entrerai pas dans les détails ici. Cet article présente principalement l'optimisation dans JIT. L'un des aspects les plus importants de l'optimisation JIT est l'analyse des évasions.

Analyse d'évasion

Concernant le concept d'analyse d'échappement, vous pouvez vous référer au fait que tous les objets et tableaux n'allouent pas de mémoire sur le tas. Un article, voici une brève revue :

Le comportement de base de l'analyse d'échappement consiste à analyser la portée dynamique de l'objet : lorsqu'un objet est défini dans une méthode, il peut être référencé par une méthode externe, par exemple en étant transmis à d'autres endroits en tant que paramètre d'appel, appelé méthode. s'échapper.

Par exemple, le code suivant :

public static StringBuffer craeteStringBuffer (String s1, String s2) {

StringBuffer sb = new StringBuffer();

sb.append(s1);

sb.append(s2);

Retourner qn;

}

public static String createStringBuffer (String s1, String s2) {

StringBuffer sb = new StringBuffer();

sb.append(s1);

sb.append(s2);

Retourner sb.toString();

}

Le sb dans le premier code s'échappe, mais le sb dans le deuxième code ne s'échappe pas.

Grâce à l'analyse d'échappement, le compilateur peut optimiser le code comme suit :

1. La synchronisation est omise. Si un objet s'avère accessible uniquement à partir d'un seul thread, la synchronisation ne peut pas être prise en compte pour les opérations sur cet objet.

2. Convertissez l'allocation de tas en allocation de pile. Si un objet est alloué dans un sous-programme, de sorte que le pointeur vers l'objet ne s'échappe jamais, l'objet peut être candidat à l'allocation de pile plutôt qu'à l'allocation de tas.

3. Objets séparés ou remplacement scalaire. Certains objets peuvent ne pas avoir besoin d'exister sous la forme d'une structure de mémoire continue pour être accessibles, de sorte qu'une partie (ou la totalité) de l'objet peut ne pas être stockée en mémoire, mais stockée dans les registres du processeur.

Lorsque le code Java est en cours d'exécution, vous pouvez spécifier s'il faut activer l'analyse d'échappement via les paramètres JVM,

-XX:+DoEscapeAnalysis : indique l'activation de l'analyse d'échappement

-XX:-DoEscapeAnalysis : indique que l'analyse d'échappement est lancée par défaut depuis jdk 1.7. Si vous souhaitez la désactiver, vous devez spécifier -XX : -DoEscapeAnalysis

. Synchronisation omise

Lors de la compilation dynamique d'un bloc synchronisé, le compilateur JIT peut utiliser l'analyse d'échappement pour déterminer si l'objet verrou utilisé par le bloc synchronisé n'est accessible que par un seul thread et n'a pas été libéré vers d'autres threads.

S'il est confirmé que l'objet verrou utilisé par le bloc synchronisé n'est accessible que par un seul thread via cette analyse, le compilateur JIT désynchronisera cette partie du code lors de la compilation du bloc synchronisé. Ce processus d'annulation de synchronisation est appelé omission de synchronisation, également appelé élimination de verrouillage.

Tel que le code suivant :

public void f() {

Objet hollis = new Object();

synchronisé (hollis) {

System.out.println(hollis);

}

}

L'objet Hollis est verrouillé dans le code, mais le cycle de vie de l'objet Hollis se trouve uniquement dans la méthode f() et ne sera pas accessible par d'autres threads, il sera donc optimisé lors de la phase de compilation JIT. Optimisé pour :

public void f() {

Objet hollis = new Object();

System.out.println(hollis);

}

Par conséquent, lors de l'utilisation de synchronisé, si le JIT constate qu'il n'y a pas de problème de sécurité des threads après l'analyse d'échappement, il éliminera le verrou.

Remplacement scalaire

Scalaire fait référence à des données qui ne peuvent pas être décomposées en données plus petites. Le type de données primitif en Java est scalaire. En revanche, les données qui peuvent être décomposées sont appelées un agrégat. Un objet en Java est un agrégat car il peut être décomposé en d'autres agrégats et scalaires.

Au stade JIT, s'il s'avère grâce à l'analyse d'échappement qu'un objet ne sera pas accessible par le monde extérieur, alors après l'optimisation JIT, l'objet sera désassemblé en plusieurs variables membres qu'il contient et remplacé. Ce processus est un remplacement scalaire.

public static void main (String[] args) {

allouer();

}

allocation vide statique privée() {

Point point = nouveau Point(1,2);

System.out.println("point.x="+point.x+"; point.y="+point.y);

}

Point de classe{

privé int x;

privé int y ;

}

Dans le code ci-dessus, l'objet point n'échappe pas à la méthode d'allocation et l'objet point peut être désassemblé en scalaires. Ensuite, JIT ne créera pas directement l'objet Point, mais utilisera directement deux scalaires int x et int y pour remplacer l'objet Point.

Le code ci-dessus, après remplacement scalaire, deviendra :

allocation vide statique privée() {

int x = 1;

int y = 2;

System.out.println("point.x="+x+"; point.y="+y);

}

On peut voir qu'après l'analyse d'évasion de la quantité globale Point, il a été constaté qu'elle ne s'échappait pas, elle a donc été remplacée par deux quantités globales. Alors, quels sont les avantages de la substitution scalaire ? Autrement dit, cela peut réduire considérablement l’utilisation de la mémoire tas. Parce qu’une fois qu’il n’est plus nécessaire de créer des objets, il n’est plus nécessaire d’allouer de la mémoire tas.

La substitution scalaire fournit une bonne base d'allocation sur la pile.

Allocation sur pile

Dans la machine virtuelle Java, il est de notoriété publique que la mémoire est allouée aux objets dans le tas Java. Cependant, il existe un cas particulier : si après analyse d'échappement, il s'avère qu'un objet n'a pas de méthode d'échappement, il peut être optimisé pour être alloué sur la pile. Cela élimine le besoin d’allouer de la mémoire sur le tas et élimine le besoin de garbage collection.

Pour une introduction détaillée à l'allocation sur la pile, veuillez vous référer à Tous les objets et tableaux n'allouent pas de mémoire sur le tas. .

Ici, je voudrais mentionner brièvement que dans les machines virtuelles existantes, l'allocation sur la pile n'est pas vraiment implémentée et que les objets et les tableaux n'allouent pas de mémoire sur le tas. Dans notre exemple, l'objet n'est pas alloué sur le tas, il est en réalité implémenté par remplacement scalaire.

L'analyse des évasions n'est pas mature

L'article sur l'analyse des fuites a été publié en 1999, mais il n'a été implémenté qu'avec le JDK 1.6, et cette technologie n'est pas encore très mature.

La raison fondamentale est qu'il n'y a aucune garantie que la consommation de performances de l'analyse d'échappement sera supérieure à sa consommation. Bien que l'analyse d'échappement puisse effectuer une substitution scalaire, une allocation de pile et une élimination de verrous. Cependant, l’analyse des évasions elle-même nécessite également une série d’analyses complexes, ce qui constitue en réalité un processus relativement long.

Un exemple extrême est qu’après analyse d’évasion, on constate qu’aucun objet ne s’échappe. Le processus d’analyse des évasions est alors inutile.

Bien que cette technologie ne soit pas très mature, elle constitue également un moyen très important dans la technologie d'optimisation des compilateurs juste à temps.

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!