Schaffen Sie weiter, beschleunigen Sie das Wachstum! Dies ist der dritte Tag meiner Teilnahme an der „Nuggets Daily New Plan · June Update Challenge“,Klicken Sie hier, um die Ereignisdetails anzuzeigen

Hallo zusammen, ich bin Wild Man. Dieser Artikel ist der letzte Artikel zur JVM-Leistungsoptimierung und außerdem ein sehr wichtiger praktischer Artikel.

Wie das Sprichwort sagt, nur reden, aber nicht üben, gefälschter Griff

Dieser praktische Artikel bringt alle dazu, gemeinsam zu üben

7. Abstimmung des tatsächlichen Kampfes

7.1 Umgebung

Wir verwenden immer noch den gleichen Fall im Kollektorabschnitt oben, diesmal für eine detaillierte Analyse des Gedächtnisses.
Verwenden Sie das Mainstream-JDK8 im Unternehmen zum Ausführen, andere JDK-Versionsparameter können geringfügig abweichen.
Die mit jdk gelieferten Analysebefehle und -werkzeuge bieten Ihnen erweiterte Informationen
Dabei nutzen wir online übersichtliche und effiziente grafische Analysetools:gceasy.io
GC-Log-Parameter:

 -XX:+PrintGC 输出GC日志
 -XX:+PrintGCDetails 输出GC的详细日志
 -XX:+PrintGCTimeStamps 输出GC的时间戳（以基准时间的形式）
 -XX:+PrintGCDateStamps 输出GC的时间戳（以日期的形式，如 2013-05-04T21:53:59.234+0800）
 -XX:+PrintHeapAtGC 在进行GC的前后打印出堆的信息
 -Xloggc:gc.log   jdk8日志文件的输出
 
 -Xlog:gc*:gc.log  jdk11日志输出方式略有不同
复制代码

7.2 Ausgangszustand

7.2.1 Parameter

 -Xmx32m -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintGCDateStamps -XX:+PrintHeapAtGC -Xloggc:gc.log
复制代码

7.2.2 Ausführungsprotokoll

Nach einer Weile der Ausführung sehen Sie gc.log im Projektverzeichnis

7.2.3 Protokollanalyse

Öffnen Sie die Homepage von gceasy, klicken Sie nach dem Hochladen auf Analysieren, um die Analyseergebnisse anzuzeigen

1) Gesamtspeicherübersicht

Jung und Alt sind alle voll, und sie sind offensichtlich unzureichend, sie müssen vergrößert werden, die Meta steht still und kann reduziert werden.

2) Zeitliche Gesamtsituation

Die Sammelzeit liegt meistens innerhalb von 10 ms, was darauf hinweist, dass die Sammelgeschwindigkeit in Ordnung ist, aber die Anzahl der Recyclingvorgänge offensichtlich zu hoch ist und der Gesamtdurchsatz 94 % beträgt.

3) Der Haufen vor und nach dem Recycling zittert offensichtlich häufig, und das Ganze ist hoch

4) Wenn das GC-Intervall lang ist, tritt eine große Anzahl von FullGCs auf

5) Effiziente Freigabe von Massenspeicher auf FullGC

6) Wiederherstellung und Freigabe

Der Erholungseffekt der jungen Generation und der alten Generation ist durchschnittlich, und die beiden Linien vor und nach der Erholung kreuzen sich sogar, und die Abweichung sollte weit entfernt sein, um anzuzeigen, dass eine signifikante Abnahme des Gedächtnisses vorliegt.

Metaspace ist relativ stabil

7) A&P: Die Situation, in der das Objekt von der jungen Generation zur alten Generation befördert wird

Häufige Beförderungen und generationenübergreifende Wechsel zeigen, dass die junge Generation nicht ausreicht.Wenn sich die alte Generation einmal angesammelt hat, ist es sehr einfach, volle GC zu verursachen.

8) GC-Zeiten und Zeitstatistiken

Es gibt 591 GCs und 45 davon sind FullGCs, was unerträglich ist!

Die gesamte GC-Zeit beträgt 2.820 Sekunden, und FullGC macht fast die Hälfte aus

9) GC-Pausensituation

Die Gesamtzeit und die durchschnittliche Zeit pro GC beträgt 4,77 ms

10) Der Grund, warum GC ausgelöst wird

Die Garbage Collection wird routinemäßig 45 Mal erreicht.

Der Speicherzuweisungsfehler verursacht die Wiederherstellung, die sich auf die normale Geschäftsausführung auswirkt.

7.3 Vorläufige Abstimmung

7.3.1 Parameter

分析上面的情况，明显年轻代老年代内存均严重不足，那么最简单粗暴的方式，我们加大内存

 -Xms256m -Xmx256m -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintGCDateStamps -XX:+PrintHeapAtGC -Xloggc:gc.log
复制代码

7.3.2 二次分析

重复上面的步骤，新开一个浏览器页签，方便对比分析日志，重点关注几个点：

1）总内存够用了，但是年轻代依然被吃爆。年老代闲置。

2）吞吐量上升，耗时特别长的gc分部区间明显减少，甚至消失

3）gc前后的空间曲线对比明显

4）FullGC消失！

5）GC大批量的内存释放发生在了年轻代

6）年轻代的回收前后两条曲线不再交叉，被明显剥离

7）年老代表示情绪稳定

8）年轻到老年代的晋升明显减少

9）FullGC完全消失，总GC次数明显减少到49，总停顿时间从上次的2.8s降低到0.3s

10）晋升的对象明显减少，创建速度提升

11）不再发生内存分配失败造成gc的现象

7.4 二次调优

7.4.1 参数

结合上次调优，我们发现，年轻代依然不够用，年老代闲置，对象还是会频繁从年轻代晋升到年老代。

结合我们的业务场景，大批量对象在请求后会被释放，属于短生命周期。包括我们现实中从数据库请求发送到网页后对象就完成了实名，属于同类场景。

所以，加大年轻代比例！

 -Xms256m -Xmx256m -XX:NewSize=250m -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintGCDateStamps -XX:+PrintHeapAtGC -Xloggc:gc.log
复制代码

7.4.2 日志分析

同样是256的内存，我们再次跑出日志分析看看差异

1）年轻代已基本够用，很少有对象再跑到老年代

2）吞吐量进一步上升

思考一下，那为什么pause的平均时间还变长了呢？？？

答：次数变少了，单次需要收集的对象多了，所以肯定要占时间，我们接着往下看总耗时！

3）堆回收空间变化明显

4）gc次数明显下降到8次，总时间进一步降低到80ms

7.5 小结

机器主要用来跑java服务的话，一般是需要调优的。因为默认堆最大只占物理内存的1/4
jvm的调优没有标准可言，不同业务场景的内存占用和增长情况不同。调整需要根据结果一步步来，直到最优。
调优工具很多，gceasy属于简单直观的ui操作，jvm自带工具大多是命令行且功能较少，在扩展资料里。
parallel是jdk8下的默认收集器，切换不同收集器后的调试与上面过程一致，感兴趣的同学可以逐个尝试。

Nun, der heutige JVM调优实战verwandte Inhalt ist hier, wir sehen uns in der nächsten Ausgabe. Wenn Sie ihn hilfreich finden, liken Sie ihn bitte und markieren Sie ihn. Ihre Anerkennung ist unsere größte Motivation.

Das Folgende ist JVMeine Reihe von Artikeln zum Thema Tuning. Ich hoffe, dass sie für alle hilfreich sein können.

Vergangene Trockenware:

JVM-Tuning-Praxisbohrer, meine Mutter macht sich keine Sorgen mehr um meine Leistungsoptimierung