JVM实战（20）——jstat实战（1）

本文介绍: 本章和下一章，我们将通过之前讲过的两个案例，看看如何在生产环境下使用jstat对JVM运行情况进行分析。我们先来回顾下商户BI系统。本章，我们通过jstat命令分析了BI系统中新生代对象的GC情况。通过jstat命令，我们清晰的看到虽然系统每隔十几秒就会进行一次Young GC，但是Young GC耗时很小，而且没有存活对象进入老年代，所以系统运行的效率还是挺高的。

作者简介：大家好，我是smart哥，前中兴通讯、美团架构师，现某互联网公司CTO

联系qq：184480602，加我进群，大家一起学习，一起进步，一起对抗互联网寒冬

学习必须往深处挖，挖的越深，基础越扎实！

一、简介

本章和下一章，我们将通过之前讲过的两个案例，看看如何在生产环境下使用jstat对JVM运行情况进行分析。我们先来回顾下商户BI系统。

1.1 案例背景

假设生产环境有一个商户BI系统，用于商户日常经营数据的分析和报表输出，其大致运行逻辑如下：

商户会在业务平台上进行运营，产生各种各样的业务数据；
Hadoop、Spark等会对这些业务数据进行计算，然后放入MySQL、HBase之类的存储中；
最后，我们的BI系统会把各种存储好的数据暴露给前端，允许前端基于各种搜索条件筛选和展示。

系统刚上线时，商户数量只有几万家，生产机器配置是4核8G，新生代分配1.5G，Eden区有1G：

1.2 内存使用模型估算

每个商户的主页，前端每隔几秒钟就会发送一个请求给BI系统，用于生成一种实时报表。每台机器差不多每秒抗500个请求，由于报表需要的数据量比较大，一般每个请求需要加载约100KB的数据到内存中，每秒500个请求总共就是50MB数据，每次Young GC过后存活对象也就几十MB：

根据上述内存使用模型的估算，每秒需加载50MB数据到Eden区，那3分钟左右就会将Eden区占满，触发Young GC。在1G的内存空间中进行Young GC的效率是很高的，基本上10ms左右就可以搞定，所以BI系统 每运行几分钟就会出现10ms左右的卡顿 ，但是对终端用户和系统运行基本没有影响：

二、代码示例

我们通过一段代码来模拟下上述情况，先来看下JVM参数配置。

2.1 JVM内存参数

-XX:NewSize=104857600 -XX:MaxNewSize=104857600 -XX:InitialHeapSize=209715200 -XX:MaxHeapSize=209715200 -XX:SurvivorRatio=8 -XX:MaxTenuringThreshold=15 -XX:PretenureSizeThreshold=3145728 -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -Xloggc:gc.log

上述，我们把Java堆内存设置为200MB，其中年轻代100MB，Eden占80MB，Survivor各占10MB，老年代100MB。

2.2 程序源码

    public class Demo1 {
        public static void main(String[] args) throws InterruptedException {
            Thread.sleep(30000);     // main线程休眠30s，以便jstat命令通过PID观察
            while (true) {
                loadData();
            }
        }
        private static void loadData() throws InterruptedException {
            byte[] data = null;
            for (int i = 0; i < 50; i++) {
                data = new byte[100 * 1024];    // 100KB
            }
            data = null;
            Thread.sleep(1000);         // 模拟上述操作全部发生在1s内
        }
    }

上述程序代码中，while(true)用来模拟每秒50次请求，每次请求加载100KB数据，也就是每秒5MB数据。