---

1 GC调优概述

1.1 调优指标

1.1.1 吞吐量

1.1.2 延迟

使用GCeasy来进行分析

1.1.3 内存使用量

2 GC调优方法

2.1 发现问题

2.1.1 jstat工具

jstat -gc 3785 1000 10

2.1.2 visualvm插件

2.1.3 Prometheus+Grafana

2.1.4 GC Viewer

生成GC日志

-XX:+PrintGCDetails -Xloggc:test1.log

生成

java -jar gcviewer-1.36.jar test1.log

2.1.5 GCeasy

https://gceasy.ycrash.cn/gc-dashboard.jsp

给的相当详细

2.2 常见GC模式

2.2.1 正常情况

2.2.2 缓存对象过多

2.2.3 内存泄漏

2.2.4 持续FullGC

2.2.5 元空间不足导致FullGC

2.3 解决GC问题的手段

2.3.1 优化基础JVM参数

2.3.1.1 -Xmx -Xms 堆参数

2.3.1.2 -XX:MaxMetaspaceSize -XX:MetaspaceSize 元空间参数

所以我们启动程序之后基本都会触发1到2次的由元空间不足引起的FullGC，这是因为-XX:MetaspaceSize触发FullGC最开始的大小可能只有20M，所以会触发1到2次的FullGC，因为是在启动的时候触发的，所以并不会对用户的使用产生影响。

2.3.1.3 -Xss 虚拟机栈参数

2.3.1.4 不建议设置参数

2.3.1.5 模板

2.3.2 更换垃圾回收器

第二点减少对象的产生，就涉及内存调优，这个在以前已经讲过了，不再赘述

private Cache cache = Caffeine.newBuilder().weakKeys().softValues().build();

软引用+弱引用最大程度保证缓存不会溢出

先测试jdk8自带ps+po

-Xms4g -Xmx4g -Xss256k -XX:MaxMetaspaceSize=512m  -XX:+DisableExplicitGC -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=D:/test.hprof  -verbose:gc -XX:+PrintGCDetails -XX:+PrintGCTimeStamps

启动测试脚本

50并发下最大的响应时间是280ms，最后总结，并发越高，fullgc时间越长，因为创建对象速度快，可能刚刚释放，又要创建又要fullgc

再测试parnew+cms

-Xms4g -Xmx4g -Xss256k -XX:MaxMetaspaceSize=512m  -XX:+DisableExplicitGC -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=D:/test.hprof  -verbose:gc -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+UseParNewGC -XX:+UseConcMarkSweepGC

50并发下最大的响应时间是220ms，其实都差不多

最后测试g1，在jdk17上

平均不到100ms，差距还是非常明显的。

2.4 实战

分析出有很多缓存对象

如果想要生成内存快照时不做fullgc，则需要通过jmap来保存，去掉live即可

jmap -dump:format=b,file=/home/jvm/dump/jvm-optimize-jmap.hprof 29317

但是mat分析时还是会自动把能回收的对象排除在外，所以我们需要

找到了482M的对象，本应该是被回收的，但是这些数组已经不在gcroot的引用链上了，所以用回溯找是没法找到的

2.4.1 总结