Chapitre 25 Paramètres d'exécution JVM

JVM expliquée par Song Hongkang de Shang Silicon Valley: lien bilibili

Insérez la description de l'image ici

1 type d'option de paramètre JVM

1.1 Type 1: options de paramètres standard

Caractéristiques: relativement stable, fondamentalement inchangé dans les versions ultérieures, à commencer par-
Diverses options: exécutez java ou java -help pour voir toutes les options standard
Charge interne supplémentaire: -serveur et -client

Hotspot JVM a deux modes, respectivement serveur et client, définis par les modes -server et -client
- Sur les systèmes Windows 32 bits, la JVM de type client est utilisée par défaut. Pour utiliser le mode Serveur, la machine doit avoir au moins 2 CPU et 2 Go ou plus de mémoire physique. Le mode client convient aux applications de bureau avec une petite mémoire et le ramasse-miettes série est utilisé par défaut.
- Sur les ordinateurs 64 bits, seule la JVM en mode serveur est prise en charge. Elle est utilisée pour les applications nécessitant une grande mémoire. Le garbage collector parallèle est utilisé par défaut.
À propos du site officiel du serveur et du client: URL

1.2 Tapez deux: paramètre -X

Caractéristiques: Paramètres non standardisés, la fonction est relativement stable. Mais le fonctionnaire a déclaré que les versions ultérieures pourraient être modifiées, à commencer par -X
Diverses options: exécutez la commande java -X pour voir toutes les options X
Options liées au mode de compilation JIT de JVM

-Xint désactive JIT, tous les bytecodes sont interprétés et exécutés, ce mode est le plus lent

-Xcomp Tous les bytecodes sont compilés en codes locaux la première fois qu'ils sont utilisés, puis exécutés

-Le mode mixte Xmixed, le mode par défaut, permet à JIT de compiler sélectivement du code en code local en fonction de la situation d'exécution du programme
spécial

-Xms -Xmx -Xss appartient au paramètre XX
- -Xms <size> définit la taille initiale du tas Java, qui équivaut à -XX: InitialHeapSize
- -Xmx <size> définit la taille maximale du tas Java, qui équivaut à -XX: MaxHeapSize
- -Xss <size> définit la taille de la pile de thread Java, qui est équivalente à -XX: ThreadStackSize

1.3 Tapez trois: paramètre -XX

Caractéristiques: Paramètres non standardisés, les options de paramètres les plus utilisées , ces options sont expérimentales et instables. Commencez par -XX
Rôle: utilisé pour développer et déboguer JVM

Catégorie :

Insérez la description de l'image ici

Exemple:

# Boolean类型格式
-XX:+UseParallelGC			# 选择垃圾收集器为并行收集器
-XX:+UseG1GC				# 表示启用G1收集器
-XX:+UseAdaptiveSizePolicy	# 自动选择年轻代区大小和响相应的Survivor区比例

# 非Boolean类型格式(key-value类型)
# 子类型1：数值型格式 -XX:<option>=<number>
# number表示数值，可带上单位：(兆：'m','M'),(KB：'k', 'K'), (GB：'g','G')
-XX:NewSize=1024m			# 表示设置新生代初始大小为1024兆
-XX:MaxGCPauseMills=500		# 表示设置GC停顿时间：500毫秒
-XX:GCTimeRatio=19			# 表示设置吞吐量
-XX:NewRatio=2				# 表示老年代和新生代的比例为2
# 子类型1：非数值型格式 -XX:<option>=<string>
-XX:HeapDumpPath=/usr/local/heapdump.hprof		# 用于指定heap转存文件的存储路径

En particulier:
```
-XX:+PrintFlagsFinal
```
- Afficher les noms et les valeurs par défaut de tous les paramètres
- Les paramètres de Diagnosticc et Experiment ne sont pas inclus par défaut
- Peut coopérer -XX:+UnlockDiagnosticVMOptionset -XX:UnlockExperimentVMOptionsutiliser

2 Ajouter des options de paramètres JVM

éclipse

…

IDÉE

Insérez la description de l'image ici

Exécutez le package jar

java -Xms50m -Xmx50m -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -jar demo.jar

Exécutez le package war via Tomcat

Sous le système Linux, vous pouvez ajouter la configuration suivante dans tomcat / bin / catalina.sh:JAVA_OPTS="-Xms512M -Xmx1024M"
Ajoutez une configuration similaire à la suivante dans catalina.bat sous le système Windows:set "JAVA_OPTS=-Xms512M -Xmx1024M"

Pendant que le programme est en cours d’exécution

Utilisez pour jinfo -flag <name>=<value> <pid>définir des paramètres de type non booléen
Utilisez pour jinfo -flag [+|-]<name> <pid>définir les paramètres de type booléen

3 Options de paramètres JVM couramment utilisées

Site officiel des paramètres de commande

3.1 XX options et valeurs des paramètres d'impression

Insérez la description de l'image ici

3.2 Paramètres de taille de mémoire tels que le tas, la pile, la zone de méthode, etc.

Insérez la description de l'image ici

Remarque: Bien que les paramètres par défaut -XX:SurvivorRatio=8ne soient pas définis explicitement, en fait Eden: S0: S1 = 6: 1: 1 (par défaut, il -XX:+UseAdaptivePolicyest activé, même si l'option est désactivée, mais le paramètre explicite n'est pas défini -XX:SurvivorRatio=8, le le rapport réel est toujours Il est de 6: 1: 1). Tant qu'il est explicitement défini -XX:SurvivorRatio=8, Eden: S0: S1 = 8: 1: 1.

3.3 Options liées à OutofMemory

Insérez la description de l'image ici

Fonctionnement et maintenance d'OnOutOfMemoryError

Prenons l'exemple du Server.jar déployé dans le répertoire / opt / Server du système Linux

(1) Ajouter des paramètres jvm dans le script de démarrage run.sh

-XX:OnOutOfMemoryError=/opt/Server/restart.sh

(2) script restart.sh

environnement linux

#!/bin/bash
pid=$(pf -ef | grep Server.jar | awk '{
       
       if($8=="java"){
      
      print $2}}')
kill -9 $pid
cd /opt/Server/;sh run.sh

environnement Windows

echo off
wmic process where Name='java.exe' delete
cd D:\Server
start run.bat

3.4 Options liées au ramasse-miettes

La relation entre 7 ramasse-miettes classiques et la génération d'ordures
Combinaison de ramasse-miettes
- La figure a été mise à jour vers JKD14
  - Si les lignes pointillées de la figure sont considérées comme des lignes pleines, il s'agit de la combinaison de ramasse-miettes avant JDK8 (sans JDK8)
  - La ligne entre CMS et MSC signifie qu'en cas de défaillance du CMS, démarrez MSC (MSC équivaut à une solution de sauvegarde)
  - La combinaison des deux lignes pointillées rouges a été abandonnée dans JDK8 (JEP 173), et les deux lignes pointillées rouges ont été supprimées dans JDK9 (JEP 214).
  - Dans JDK14, la combinaison de la ligne pointillée verte (JEP 366) est obsolète .
  - Dans JDK14, le ramasse-miettes CMS (JEP 363) dans la zone en pointillé cyan est supprimé .
- Le garbage collector par défaut dans JDK8 est: Parallel Scavenge GC + Parallel Old GC
- Pourquoi Parallel Scanvenge GC ne peut-il pas être utilisé avec CMS?
  - Le framework utilisé au bas de Parallel Scanvenge GC est différent et incompatible avec les autres.
cartographie mentale

Insérez la description de l'image ici

Afficher le ramasse-miettes par défaut

-XX:+PrintCommandLineFlags  # 查看命令行相关参数(包含使用的垃圾收集器)

Utilisez les instructions de la ligne de commande:

jinfo -flag 相关垃圾收集器参数 进程ID

Collecteur série

Le collecteur série sert de ramasse-miettes de nouvelle génération par défaut dans le mode client de HotSpot. Serial Old est le ramasse-miettes par défaut de l'ancienne génération s'exécutant en mode client.

-XX:+UseSerialGC

Précisez que la jeune génération et l'ancienne génération utilisent des collecteurs en série. Cela équivaut à utiliser Serial GC dans la nouvelle génération et Serial Old GC dans l'ancienne génération. La plus grande efficacité de collecte à un seul thread peut être obtenue.

Collectionneur ParNew

-XX:UseParNewGC

Spécifiez manuellement l'utilisation du collecteur ParNew pour effectuer des tâches de récupération de mémoire. Cela signifie que la jeune génération utilise le collecteur parallèle et n'affecte pas l'ancienne génération.

-XX:ParallelGCThreads=N

Limiter le nombre de threads. Par défaut, le nombre de threads avec les mêmes données CPU est activé.

Collecteur parallèle (priorité de débit)

Configuration des paramètres
- -XX: + UseParallelGC spécifie manuellement la nouvelle génération pour utiliser le collecteur parallèle parallèle pour effectuer des tâches de récupération de mémoire.
- -XX: UseParallelOldGC spécifie manuellement l'ancienne génération pour utiliser le collecteur de collection parallèle.
  - Il s'applique respectivement à la nouvelle génération et à l'ancienne génération, et jdk8 est activé par défaut.
  - Parmi les deux paramètres ci-dessus, l'un est activé par défaut et l'autre sera également activé. (Activation mutuelle)
- -XX: ParallelGCThreads définit le nombre de threads du collecteur parallèle de nouvelle génération. En règle générale, il est préférable d'être égal au nombre de processeurs pour éviter que des threads excessifs n'affectent les performances du garbage collection.
  - Par défaut, lorsque le nombre de processeurs est inférieur ou égal à 8, la valeur de ParallelGCThreads est égale au nombre de processeurs.
  - Lorsque le nombre de processeurs est supérieur à 8, la valeur de ParallelGCThreads est égale à 3+ [5 * CPU_count / 8].
- -XX: MaxGCPauseMillis conçoit le temps de pause maximal du ramasse-miettes (c'est-à-dire le temps de STW). L'unité est en millisecondes.
  - Afin de garder le temps de pause dans MaxGCPauseMillis autant que possible, le collecteur ajustera la taille du tas Java ou certains autres paramètres lors de son travail.
  - Pour les utilisateurs, plus le temps de pause est court, meilleure est l'expérience, mais du côté serveur, nous nous concentrons sur une concurrence élevée et un débit global. Ainsi, le côté serveur convient à Parallel pour le contrôle.
  - Utilisez ce paramètre avec prudence.
- -XX: GCTimeRatio Le rapport entre le temps de garbage collection et le temps total (= 1 / (N + 1)). Utilisé pour mesurer la taille du débit.
  - Plage de valeurs (0, 100). La valeur par défaut est 99, ce qui signifie que le temps de garbage collection ne dépasse pas 1%.
  - Il existe une certaine contradiction avec le paramètre précédent -XX: MaxGCPauseMillis. Plus le temps de pause est court, plus il est facile pour le paramètre Ratio de dépasser le ratio réglé.
- -XX: + UseAdaptiveSizePolicy définit le collecteur Parallel Scavenge pour avoir une stratégie d'ajustement adaptative .
  - Dans ce mode, la taille de la jeune génération, le rapport Eden et Survivor et l'âge des objets promus à l'ancienne génération sont automatiquement ajustés pour atteindre un équilibre entre la taille du tas, le débit et le temps de pause.
  - Dans les situations où le réglage manuel est difficile, vous pouvez utiliser directement cette méthode adaptative pour spécifier uniquement le tas maximal, le débit cible (GCTimeRatio) et le temps de pause (MaxGCPauseMillis) de la machine virtuelle, et laisser la machine virtuelle terminer le travail de réglage par elle-même.

Collecteur CMS (faible latence)

Configuration des paramètres
- -XX: UseConcMarkSweepGC spécifie manuellement l'utilisation du collecteur CMS pour effectuer des tâches de récupération de mémoire.
  - Après avoir activé ce paramètre, -XX: + UseParNewGC sera automatiquement activé. Autrement dit, la combinaison de ParNew (pour Young area) + CMS (pour Old area) + Serial Old.
- -XX: CMSInitiatingOccupanyFraction définit le seuil d'utilisation de la mémoire du tas, une fois qu'il atteint le seuil, il commence à recycler.
  - La valeur par défaut de JDK5 et des versions précédentes est 68, c'est-à-dire que lorsque le taux d'utilisation de l'ancienne génération atteint 68%, une récupération CMS sera effectuée. La valeur par défaut de JDK6 et supérieur est de 92% .
  - Si la mémoire augmente lentement, cela peut être défini sur une valeur plus élevée. Un seuil plus élevé peut réduire efficacement la fréquence de démarrage du CMS et la réduction du nombre de recyclage dans l'ancienne génération peut améliorer considérablement les performances de l'application. A l'inverse, si l'utilisation de la mémoire augmente rapidement, ce seuil doit être abaissé pour éviter un déclenchement fréquent de l'ancien collecteur série. Par conséquent, cette option peut réduire efficacement le nombre d'exécutions de Full GC .
- -XX: UseCMSCompactAtFullCollection est utilisé pour spécifier la compression et le tri de la mémoire après l'exécution du GC complet, afin d'éviter la génération de fragmentation de la mémoire. Cependant, comme le processus de compression et de tri de la mémoire ne peut pas être exécuté simultanément, le problème est que le temps de pause devient plus long.
- -XX: CMSFullGCsBeforeCompaction définit le nombre d'exécutions de Full GC pour compresser et organiser l'espace mémoire.
- -XX: ParallelCMSThreads définit le nombre de threads CMS.
  - Le nombre de threads activés par défaut par CMS est (ParallelGCThreads + 3) / 4. ParallelGCThreads est le nombre de threads du collecteur parallèle de nouvelle génération. Lorsque les ressources du processeur sont restreintes, le collecteur CMS est affecté. Les performances de l'application peuvent être dans la phase de ramassage des ordures Ce sera très mauvais.
Paramètres supplémentaires
instructions spéciales

Collecteur G1

réglages des paramètres
- -XX: UseG1GC spécifie manuellement l'utilisation du collecteur G1 pour effectuer des tâches de récupération de mémoire.
- -XX: G1HeapRegionSize définit la taille de chaque région. La valeur est une puissance de 2 et la plage est comprise entre 1 Mo et 32 Mo. L'objectif est de diviser 2 048 régions en fonction de la plus petite taille de tas Java. La région est égale à 1/2000 de la mémoire du tas par défaut.
- -XX: MaxGCPauseMillis définit l'indice de temps de pause GC maximal attendu (JVM fera de son mieux pour y parvenir, mais il n'est pas garanti qu'il soit atteint). La valeur par défaut est de 200 ms.
- -XX: ParallelGCThread définit la valeur du nombre de threads GC dans STW. Réglez à 8 au maximum.
- -XX: ConcGCThreads définit le nombre de threads marqués simultanément. Il est recommandé de définir ce paramètre sur environ 1/4 des threads de garbage collection parallèles (ParallelGCThreads).
- -XX: InitiatingHeapOccupancyPercent définit le seuil d'occupation du tas Java qui déclenche des cycles GC simultanés. Si cette valeur est dépassée, GC est déclenché. La valeur par défaut est 45.
- -XX: G1NewSizePercent, -XX: G1MaxNewSizePercent le pourcentage minimum (par défaut 5%) et le pourcentage maximum (par défaut 60%) de la nouvelle génération de la totalité de la mémoire du tas
- -XX: G1ReservePercent réserve la zone de mémoire pour empêcher l'espace (vers la zone dans Survivor) de déborder
Paramètres de réglage GC mixtes

Comment choisir un garbage collector

La configuration du garbage collector Java est un choix important pour l'optimisation de la JVM. Le choix d'un garbage collector approprié peut grandement améliorer les performances de la JVM.

Donner la priorité à l'ajustement de la taille du tas pour permettre à la JVM de se terminer de manière adaptative
Si la mémoire est inférieure à 100 Mo, utilisez le collecteur série
En cas de programme mono-cœur autonome et sans temps de pause, le collecteur série
S'il s'agit d'un multi-CPU, nécessite un débit élevé et autorise un temps de pause supérieur à 1 seconde, choisissez parallèle ou JVM à choisir vous-même
S'il s'agit d'un multi-CPU, la poursuite du temps de pause, une réponse rapide (par exemple, le délai ne peut pas être ultra-élevé 1 seconde, comme les applications Internet), utilisez un collecteur simultané; la recommandation officielle G1, haute performance. Désormais, les projets Internet utilisent essentiellement G1 .

Enfin, un point clair
- Il n'y a pas de meilleur collecteur et il n'y a pas de collecteur universel; le réglage vise toujours des scénarios et des besoins spécifiques, et il n'y a pas de collecteur une fois pour toutes.

3.5 Options liées au journal GC

Insérez la description de l'image ici

3.6 Autres paramètres

Insérez la description de l'image ici

4 Obtention des paramètres JVM via le code Java

Java fournit le package java.lang.management pour surveiller et gérer la machine virtuelle Java et d'autres composants dans l'environnement d'exécution Java. Il permet la surveillance et la gestion locales et à distance de la machine virtuelle Java en cours d'exécution. Parmi eux, la classe ManagementFactory est assez couramment utilisée. En outre, il existe une classe Runtime qui peut également obtenir de la mémoire, le numéro de cœur du processeur et d'autres données associées.
Grâce à ces API, nous pouvons surveiller l'utilisation de la mémoire de tas de notre serveur d'applications et définir certains seuils pour le traitement des alarmes.

/**
 * 监控我们的应用服务器的堆内存使用情况，设置一些阈值进行报警等处理
 */
public class MemoryMonitor {
    
    
    public static void main(String[] args) {
    
    
        MemoryMXBean memorymbean = ManagementFactory.getMemoryMXBean();
        MemoryUsage usage = memorymbean.getHeapMemoryUsage();
        System.out.println("INIT HEAP: " + usage.getInit() / 1024 / 1024 + "m");
        System.out.println("MAX HEAP: " + usage.getMax() / 1024 / 1024 + "m");
        System.out.println("USE HEAP: " + usage.getUsed() / 1024 / 1024 + "m");
        System.out.println("\nFull Information:");
        System.out.println("Heap Memory Usage: " + memorymbean.getHeapMemoryUsage());
        System.out.println("Non-Heap Memory Usage: " + memorymbean.getNonHeapMemoryUsage());

        System.out.println("=======================通过java来获取相关系统状态============================ ");
        System.out.println("当前堆内存大小totalMemory " + (int) Runtime.getRuntime().totalMemory() / 1024 / 1024 + "m");// 当前堆内存大小
        System.out.println("空闲堆内存大小freeMemory " + (int) Runtime.getRuntime().freeMemory() / 1024 / 1024 + "m");// 空闲堆内存大小
        System.out.println("最大可用总堆内存maxMemory " + Runtime.getRuntime().maxMemory() / 1024 / 1024 + "m");// 最大可用总堆内存大小
    }
}
/*
 INIT HEAP: 256m
 MAX HEAP: 3614m
 USE HEAP: 5m
 
 Full Information:
 Heap Memory Usage: init = 268435456(262144K) used = 5383480(5257K) committed = 257425408(251392K) max = 3790077952(3701248K)
 Non-Heap Memory Usage: init = 2555904(2496K) used = 4789360(4677K) committed = 8060928(7872K) max = -1(-1K)
 =======================通过java来获取相关系统状态============================ 
 当前堆内存大小totalMemory 245m
 空闲堆内存大小freeMemory 240m
 最大可用总堆内存maxMemory 3614m
 */