文章目录
- 1、-Xmx 和 –Xms
- 2、-XX:MaxMetaspaceSize 和 –XX:MetaspaceSize
- 3、-Xss
- 4、不建议改的参数
- 5、其他参数
- 6、选择GC回收器的调试思路
- 7、CMS的并发模式失败现象的解决
- 8、调优案例
GC问题解决方式：
- 优化JVM基础参数，避免频繁Full GC
- 减少对象的产生，以免对象产生速度过快导致频繁Full GC
- 选择适合业务场景的垃圾回收器
- 优化垃圾回收器的参数
1、-Xmx 和 –Xms
-Xmx设置最大堆内存(max)，-Xms设置可用堆内存大（total）
计算理论最大可用堆空间，如服务器内存4G，操作系统自己使用的内存+元空间最大值+其它软件占用1.5G ⇒ 理论最大可用堆空间为2.5g，只是理论值。（减去元空间是因为，Java 8及以后，元空间使用的是直接内存）
最后设置的堆内存大小，应是按照系统最大并发估计，且小于上面的理论值。最后，将-Xms设置的和-Xmx一样大，理由：
- 可用内存一开始就等于最大堆内存，避免堆扩容时频繁向操作系统申请内存，影响程序性能
- 避免扩容时，因其他应用占用了操作系统内存而申请扩容失败
- 服务启动速度更快，初始堆太小（Xms太小），Java应用启动会变慢，因为JVM会被迫频繁垃圾回收，直到堆增长到一个合理的大小
2、-XX:MaxMetaspaceSize 和 –XX:MetaspaceSize
-XX:MaxMetaspaceSize ：最大元空间。默认值比较大，万一元空间内存泄漏，会影响到操作系统（因为元空间用的直接内存）
–XX:MetaspaceSize：到这个值后，触发Full GC，后续什么值再触发，JVM自行计算。
3、-Xss
指定每个栈的大小，不指定取默认值，默认值取决于操作系统。如Linux x86 64bit 默认是1MB。如果没有方法的递归调用，可调小栈大小
//合理值为256k – 1m之间
-Xss256k
4、不建议改的参数
以下参数，调整可能会让某一个接口得益，但同时也会影响其他接口，不建议修改。
1）-Xmn：年轻代的大小
年轻代的大小，默认为整个堆的1/3。可根据系统峰值计算年轻代大小，以尽量让对象只存在年轻代，不进入老年代（这样后面Young GC一下就行），但计算这个值的影响因素太多，不建议改。且G1垃圾回收器会动态调整年轻代的大小，更不建议改。
2）‐XX:SurvivorRatio 伊甸园区和幸存者区的大小比例，默认值为8。
3）‐XX:MaxTenuringThreshold 最大晋升阈值
对象晋升有两个情况：
- （GC一次，对象年龄+1）年龄 > 此值，进入老年代
- 动态年龄判断机制：按年龄从小到大将对象空间加起来， > survivor区域的50%，就把大于等于该年龄的对象晋升到老年代
5、其他参数
-XX:+DisableExplicitGC
作用：禁止在代码中调用System.gc()
-XX:+HeapDumpOnOutOfMemoryError
作用：OOM时，生成hprof内存快照文件
-XX:HeapDumpPath=<path>
作用：指定内存快照文件的生成路径
-XX:+PrintGCDetails -XX:+PrintGCDateStamps -Xloggc:文件路径
作用：JDK8及之前，打印GC日志
-Xlog:gc*:file=文件路径
作用：JDK9及以后，打印GC日志
JVM参数模板总结：
-Xms1g
-Xmx1g
-Xss256k
-XX:MaxMetaspaceSize=512m
-XX:+DisableExplicitGC
-XX:+HeapDumpOnOutOfMemoryError
-XX:HeapDumpPath=/opt/logs/my-service.hprof
# <=JDK8
-XX:+PrintGCDetails
-XX:+PrintGCDateStamps
# >=JDK9
-Xloggc:文件路径
6、选择GC回收器的调试思路
用以下代码模拟系统的业务代码进行压测：
import com.github.benmanes.caffeine.cache.Cache;
import com.github.benmanes.caffeine.cache.Caffeine;
import lombok.SneakyThrows;
import org.apache.commons.lang3.RandomStringUtils;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RestController;
import java.time.Duration;
import java.util.ArrayList;
import java.util.List;
import java.util.Random;
@RestController
@RequestMapping("/fullgc")
public class DemoController {
private Cache cache = Caffeine.newBuilder().weakKeys().softValues().build();
private List<Object> objs = new ArrayList<>();
private static final int _1MB = 1024 * 1024;
//FULLGC测试结果：
//ps + po 50并发 260ms 100并发 474ms 200并发 930ms
//cms -XX:+UseParNewGC -XX:+UseConcMarkSweepGC 50并发 157ms 200并发 833ms
//g1 JDK11 并发200 248
@GetMapping("/1")
public void test() throws InterruptedException {
cache.put(RandomStringUtils.randomAlphabetic(8),new byte[10 * _1MB]);
}
}
创建一个具有弱引用键（value不存在了，可被GC回收）和软引用值的缓存对象（内存不足时，可GC回收），接口往里面放10M的数据，如此，不会OOM，且会较多触发FULL GC。用Jmeter并发/1接口的同时，再调用一次接口/2，用这个接口模拟有突发大对象产生时，对系统响应时间的影响：
@GetMapping("/2")
public void test() throws InterruptedException {
ArrayList<Object> objects = new ArrayList<>();
for (int i = 0; i < 1024; i++) {
objects.add(new byte[3 * _1MB]);
}
}
步骤：
- Jmeter脚本压测，添加RT响应时间组件
- 选择不同的垃圾回收器组合，测试50、100、200并发下，FULL GC对RT的时间的影响
统一JVM参数设置：
-Xms8g -Xmx8g -Xss256k -XX:MaxMetaspaceSize=512m -XX:+DisableExplicitGC -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=D:/test.hprof -verbose:gc -XX:+PrintGCDetails -XX:+PrintGCTimeStamps
测试的垃圾回收器组合：
- ps + po
- cms
- JDK11的默认回收器g1
测试场景：
- 高并发（/1接口)
- 大对象产生（/2接口)
观察RT的结果：查看最大值，即接口的最大响应时间。峰值的出现，即FULL GC对接口响应时间的影响
7、CMS的并发模式失败现象的解决
CMS的垃圾清理线程和用户线程并行
如果并行清理的过程中，老年代的空间，不足以容纳新晋升到老年代的对象，就发生并发模式失败：
出现并发模式失败时，会导致JVM使用Serial Old单线程进行FULLGC回收老年代，这样会产生较长时间的停顿，从而影响接口响应时间。解决思路：
- 减少对象的产生以及晋升
- 增加堆内存大小
-XX:CMSInitiatingOccupancyFraction=值
关于垃圾回收器的参数CMSInitiatingOccupancyFraction，当老年代大小达到其值，会自动进行CMS老年代垃圾回收。JDK8中，该值为-1，计算公式：
((100 - MinHeapFreeRatio) + (double)(CMSTriggerRatio * MinHeapFreeRatio) / 100.0)
最后，这个参数想生效，必须先开启：
-XX:+UseCMSInitiatingOccupancyOnly
调小这个值，比如从默认的90%调到60%，早些进行老年代的回收，就不会出现并发模式失败，也就不会有后面的Serial Old单线程回收老年代。
8、调优案例
案例背景：
- 系统的接口在平时响应较快，但高峰期会出现调用时间较长的现象，现需要优化性能
分析的方向：
- GC问题：查看是否出现连续的Full GC或者单次GC时间过长
- 内存问题
步骤：
- 生成GC报告，GcEasy分析
- GC有问题，就调整参数或者换垃圾回收器
- 内存有问题就jmap或Arthas将堆内存快照保存
- MAT或者heaphero在线分析内存
- 修复
关于heaphero：https://heaphero.io/
调优案例：https://www.bilibili.com/video/BV1r94y1b7eS?p=68&vd_source=d86e858b4dfd8944a691759448d35279
