案例背景：
实际开发中有很多类似的这样的应用场景，比如每秒多少个请求，每次请求分配多少对象等，我们的目的就是通过工具分析我们系统在实际运行过程中是否频繁触发GC以及对象是否频繁进入老年代引发Full GC，哪些对象存在影响性能以及没有及时回收的问题。
我们以一个线上的BI系统来进行讲解，整个的流程运行如下：
针对上诉系统在商家不多的情况下，也就是几分钟卡顿10ms，对于用户端的感受来讲几乎没有影响，但是假设如果我们的商家突然暴增，同时访问量能达到几千，我们的机器可能每秒请求量就会达到几百个比如500，那么这时每秒的数据加载就有50MB，那么针对只有1G的Eden区域多久就会发生一次YongGc呢？自己系统多久会触发一次Full GC呢？
以下代码，我们模拟的就是系统正常运行，每秒钟50个请求，每个请求加载100KB数据的方式不停运行，由于是死循环，我们不停止程序也不会停止：
/**
* @Description: 案例实战-通过jps、jstat、jmap、jhat工具进行联调优化
JVM参数： -XX:NewSize=100m -XX:MaxNewSize=100m -XX:InitialHeapSize=200m -XX:MaxHeapSize=200m -XX:SurvivorRatio=8 -XX:MaxTenuringThreshold=15 -XX:PretenureSizeThreshold=3m -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -Xloggc:gc.log
*
*/
public class JVMTest {
public static void main(String[] args) throws InterruptedException {
Thread.sleep(30000);
while(true){
loadData();
}
}
public static final int _1KB = 1024;
/**
* 模拟每秒50个请求，每次请求分配100kb的数组
* @throws InterruptedException
*/
private static void loadData() throws InterruptedException {
byte[] data = null;
for (int i = 0; i < 50; i++) {
data = new byte[100 * _1KB ];
}
data = null;
Thread.sleep(1000);
}
}
我们给堆内存设置为200M，新生代100M，Eden区占80M，老年代占100M进行模拟GC情况。
步骤分析：
- 在Main方法中首先第一行代码先执行睡眠30S，目的在于方便我们程序启动后，通过jps命令找到我们当前程序进程ID，然后结合jstat来观察程序运行状态
- 接着无限循环开始加载数据，在loadData()方法中每隔1秒向内存中申请分配100*50 = 5MB对象
- 通过jstat命令打印观察数据的变化
数据分析：
- 查找到进程id
跟踪进程id查看内存数据变化：
命令：jstat -gc 19492 1000 1000 表示每隔1秒钟打印1次统计信息，连续打印1000次：
- 通过几十秒的运行后，我们结合上图也能明显观察出内存的一个变化情况
首先我们先看 EU的变化，EU代表的是Eden区内存的使用情况：
最开始EU只使用了6M左右大小，并且持续了一段时间，代表这段时间其实就是我们的睡眠时间
后续开始增长并且每秒都有变化，代表我们的loadData()方法开始执行，每秒增长差不多5M左右大小，跟我们的代码一致
当EU的占用已达到81303KB的时候，再分配5M对象很明显此时就无法分配了，这时就会触发一次 Minor GC！
- 注意：我们发现EU的大小一下降低到了4471KB差不多4M的内存，这也说明了一次Minor GC回收了大部分对象
小结：通过以上程序的运行以及分析我们知道了，该程序每秒对象增速在5MB左右，大概在10几秒左右会触发一次Mionr GC，并且通过 YGCT我们也能知道，一次Minor GC的耗时也就在8ms，速度非常快！一次回收差不多接近80MB对象，如果我们的Eden区是800MB内存，那一次回收预估也就在80ms，对于系统而已几乎没有卡顿
我们继续观察数据，看看每次Mionr GC过后的存活对象有多少？
S1U代表的就是Survivor1区使用的内存大小，我们发现触发Minor GC后 S1U就有值了，大小为:1131KB, 代表从Eden区中存活的对象有1131kb对象内移入了S1区，接近1MB的对象对于10MB的S1区来说还是很轻松的。
- 我们继续观察后续GC存活的对象有多少？
通过后续的数据我们可以发现，第二次GC后剩余存活1387KB，第三次GC过后剩余存活1475KB，增长量几乎在几十KB范围很小，而且后续的GC耗时更短，我们几乎可以断定该系统运行非常良好！几乎不会发生Full GC。
