Bien qu'il n'ait pas été optimisé. Cependant, je pense que cela doit être pris en charge en fonction des besoins réels de l'entreprise et de ses capacités commerciales pour l'optimiser.

Regardez la taille du tas et le qps de l'application Java, mais au départ, en regardant le gc complet toutes les 20 minutes, cela ne semble pas normal

L'optimisation JVM peut être discutée pendant des heures. Ici, je vais vous donner quelques avis simples sans entrer dans les détails systématiques.

Premièrement : votre problème est que le GC complet est fréquent. Vérifiez si la mémoire totale et les paramètres de l'ancienne génération sont trop petits.
Cela dépend principalement des paramètres -Xmx et -Xmn. S'il est trop petit, gc se produira inévitablement fréquemment.

Deuxième : Ajoutez les paramètres suivants
-verbose.gc -XX:+PrintGC -XX:+PrintGCTimeStamps -XX:+PrintGCDateStamps -XX:+PrintHeapAtGC -XX:+PrintTenuringDistribution -XX : +PrintGCApplicationStoppedTime -XX:+PrintTenuringDistribution -Xloggc:/data/log/xxx/xxx-gc.log -XX:+PrintGCDetails
Vérifiez à chaque fois gc, combien d'espace reste dans l'ancienne génération, d'une manière générale, l'espace dans l'ancienne génération, le régler à 2 à 2,5 fois la mémoire après gc est une valeur plus raisonnable.
En même temps, vous pouvez voir à travers ce journal si un grand nombre d'objets entrent dans l'ancienne génération sans suffisamment de gc dans la nouvelle génération. Si des objets pouvant être recyclés via la nouvelle génération entrent dans l'ancienne génération, des gc complets se produiront inévitablement fréquemment

Troisième : motif de vidage de la mémoire du code
jmap -dump:live,format=b,file=xx.bin [pid]
Puis passez MAT (http://www.eclipse .org/mat/) pour voir quelle grande mémoire n'a pas été libérée