JVM调优工具

启动测试java进程得到进程号pid

jmap

查看各种类实例个数和占用内存大小、内存信息

1、查看实例信息

jmap -histo pid(进程id)

1 2	`jmap -histo 26260 > ./log.txt #查看历史生成的实例 jmap -histo:live 26260 > ./log.txt #查看当前存活的实例，执行过程中可能会触发一次full gc`

num：序号
instances：实例数量
bytes：占用空间大小
class name：类名称，[C is a char[]，[S is a short[]，[I is a int[]，[B is a byte[]，[[I is a int[][]

2、查看堆信息

1	`jmap -heap 26260`

3、获取堆内存dump

1	`jmap -dump:format=b,file=mss.hprof 26260`

启动java程序时也可以设置内存溢出自动导出dump文件(内存很大的时候，可能会导不出来)

-XX:+HeapDumpOnOutOfMemoryError
-XX:HeapDumpPath=./ （路径）

示例代码：

public class OOMTest {
    public static List<Object> list = new ArrayList<>();
    // JVM设置
    // -Xms10M -Xmx10M -XX:+PrintGCDetails -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=D:\jvm.dump
    public static void main(String[] args) {
        List<Object> list = new ArrayList<>();
        int i = 0;
        int j = 0;
        while (true) {
            list.add(new User(i++, UUID.randomUUID().toString()));
            new User(j--, UUID.randomUUID().toString());
        }
    }
}

可以用jvisualvm命令工具导入该dump文件分析

jstat

查看堆内存各部分的内存使用情况、gc回收情况等

1、GC垃圾回收统计

1	`jstat -gc pid`

S0C：第一个幸存区的大小，单位KB
S1C：第二个幸存区的大小
S0U：第一个幸存区的使用大小
S1U：第二个幸存区的使用大小
EC：伊甸园区的大小
EU：伊甸园区的使用大小
OC：老年代大小
OU：老年代使用大小
MC：方法区大小(元空间)
MU：方法区使用大小
CCSC:压缩类空间大小
CCSU:压缩类空间使用大小
YGC：年轻代垃圾回收次数
YGCT：年轻代垃圾回收消耗时间，单位s
FGC：老年代垃圾回收次数
FGCT：老年代垃圾回收消耗时间，单位s
GCT：垃圾回收消耗总时间，单位s

2、堆内存统计

1	`jstat -gccapacity pid`

NGCMN：新生代最小容量
NGCMX：新生代最大容量
NGC：当前新生代容量
S0C：第一个幸存区大小
S1C：第二个幸存区的大小
EC：伊甸园区的大小
OGCMN：老年代最小容量
OGCMX：老年代最大容量
OGC：当前老年代大小
OC:当前老年代大小
MCMN:最小元数据容量
MCMX：最大元数据容量
MC：当前元数据空间大小
CCSMN：最小压缩类空间大小
CCSMX：最大压缩类空间大小
CCSC：当前压缩类空间大小
YGC：年轻代gc次数
FGC：老年代GC次数

3、新生代垃圾回收统计

S0C：第一个幸存区的大小

S1C：第二个幸存区的大小

S0U：第一个幸存区的使用大小

S1U：第二个幸存区的使用大小

TT:对象在新生代存活的次数

MTT:对象在新生代存活的最大次数

DSS:期望的幸存区大小

EC：伊甸园区的大小

EU：伊甸园区的使用大小

YGC：年轻代垃圾回收次数

YGCT：年轻代垃圾回收消耗时间

4、新生代内存统计

NGCMN：新生代最小容量

NGCMX：新生代最大容量

NGC：当前新生代容量

S0CMX：最大幸存1区大小

S0C：当前幸存1区大小

S1CMX：最大幸存2区大小

S1C：当前幸存2区大小

ECMX：最大伊甸园区大小

EC：当前伊甸园区大小

YGC：年轻代垃圾回收次数FGC：老年代回收次数

5、老年代垃圾回收统计

MC：方法区大小

MU：方法区使用大小

CCSC:压缩类空间大小

CCSU:压缩类空间使用大小

OC：老年代大小

OU：老年代使用大小

YGC：年轻代垃圾回收次数

FGC：老年代垃圾回收次数

FGCT：老年代垃圾回收消耗时间

GCT：垃圾回收消耗总时间

6、老年代内存统计

OGCMN：老年代最小容量

OGCMX：老年代最大容量

OGC：当前老年代大小

OC：老年代大小

YGC：年轻代垃圾回收次数

FGC：老年代垃圾回收次数

FGCT：老年代垃圾回收消耗时间

GCT：垃圾回收消耗总时间

7、元数据空间统计

MCMN:最小元数据容量

MCMX：最大元数据容量

MC：当前元数据空间大小

CCSMN：最小压缩类空间大小

CCSMX：最大压缩类空间大小

CCSC：当前压缩类空间大小

YGC：年轻代垃圾回收次数

FGC：老年代垃圾回收次数

FGCT：老年代垃圾回收消耗时间

GCT：垃圾回收消耗总时间

S0：幸存1区当前使用比例

S1：幸存2区当前使用比例

E：伊甸园区使用比例

O：老年代使用比例

M：元数据区使用比例

CCS：压缩使用比例

YGC：年轻代垃圾回收次数

FGC：老年代垃圾回收次数

FGCT：老年代垃圾回收消耗时间

GCT：垃圾回收消耗总时间

jstack

1、查看死锁线程栈信息

public class DeadLockTest {

    private static Object lock1 = new Object();
    private static Object lock2 = new Object();

    public static void main(String[] args) {
        new Thread(() -> {
            synchronized (lock1) {
                try {
                    System.out.println("thread1 begin");
                    Thread.sleep(5000);
                } catch (InterruptedException e) {
                }
                synchronized (lock2) {
                    System.out.println("thread1 end");
                }
            }
        }).start();

        new Thread(() -> {
            synchronized (lock2) {
                try {
                    System.out.println("thread2 begin");
                    Thread.sleep(5000);
                } catch (InterruptedException e) {
                }
                synchronized (lock1) {
                    System.out.println("thread2 end");
                }
            }
        }).start();

        System.out.println("main thread end");
    }
}

“Thread-1” 线程名

prio=5 优先级=5

tid=0x000000001fa9e000 线程id

nid=0x2d64 线程对应的本地线程标识nid

java.lang.Thread.State: BLOCKED 线程状态

还可以用jvisualvm自动检测死锁

2、找出占用cpu最高的栈信息

1，使用命令top -p ，显示你的java进程的内存情况，pid是你的java进程号，比如4977

2，按H，获取每个线程的内存情况

3，找到内存和cpu占用最高的线程tid，比如19664

4，转为十六进制得到 0x4cd0，此为线程id的十六进制表示

5，执行 jstack 19663|grep -A 10 4cd0，得到线程堆栈信息中 4cd0 这个线程所在行的后面10行，从堆栈中可以发现导致cpu飙高的调用方法

6，查看对应的堆栈信息找出可能存在问题的代码

jvisualvm(远程连接（少用）)

启动普通的jar程序JMX端口配置：

java -Dcom.sun.management.jmxremote.port=8899 -Dcom.sun.management.jmxremote.ssl=false -

Dcom.sun.management.jmxremote.authenticate=false -jar foo.jar

tomcat的JMX配置

JAVA_OPTS=-Dcom.sun.management.jmxremote.port=8899 -Dcom.sun.management.jmxremote.ssl=false -

Dcom.sun.management.jmxremote.authenticate=false

jvisualvm远程连接服务需要在远程服务器上配置host(连接ip 主机名)，并且要关闭防火墙

jinfo

查看正在运行的Java应用程序的扩展参数

1、查看jvm的参数

1	`jinfo -flags pid`

2、查看java系统参数

1	`jinfo -sysprops pid`

JVM运行情况预估

如何获取GC重要评判参数

用 jstat gc -pid 命令可以计算出如下一些关键数据，有了这些数据就可以采用之前介绍过的优化思路，先给自己的系统设置一些初始性的JVM参数，比如堆内存大小，年轻代大小，Eden和Survivor的比例，老年代的大小，大对象的阈值，大龄对象进入老年代的阈值等。

年轻代对象增长的速率

可以执行命令 jstat -gc pid 1000 10 (每隔1秒执行1次命令，共执行10次)，通过观察EU(eden区的使用)来估算每秒eden大概新增多少对象，如果系统负载不高，可以把频率1秒换成1分钟，甚至10分钟来观察整体情况。注意，一般系统可能有高峰期和日常期，所以需要在不同的时间分别估算不同情况下对象增长速率。

Young GC的触发频率和每次耗时

知道年轻代对象增长速率我们就能推根据eden区的大小推算出Young GC大概多久触发一次，Young GC的平均耗时可以通过 YGCT/YGC 公式算出，根据结果我们大概就能知道系统大概多久会因为Young GC的执行而卡顿多久。

每次Young GC后有多少对象存活和进入老年代

这个因为之前已经大概知道Young GC的频率，假设是每5分钟一次，那么可以执行命令 jstat -gc pid 300000 10 ，观察每次结果eden，survivor和老年代使用的变化情况，在每次gc后eden区使用一般会大幅减少，survivor和老年代都有可能增长，这些增长的对象就是每次Young GC后存活的对象，同时还可以看出每次Young GC后进去老年代大概多少对象，从而可以推算出老年代对象增长速率。

Full GC的触发频率和每次耗时

知道了老年代对象的增长速率就可以推算出Full GC的触发频率了，Full GC的每次耗时可以用公式 FGCT/FGC 计算得出。

优化思路

其实简单来说就是尽量让每次Young GC后的存活对象小于Survivor区域的50%，都留存在年轻代里。尽量别让对象进入老年代。尽量减少Full GC的频率，避免频繁Full GC对JVM性能的影响。

举例

系统频繁Full GC导致系统卡顿

机器配置：2核4G
JVM内存大小：2G
系统运行时间：7天
期间发生的Full GC次数和耗时：500多次，200多秒
期间发生的Young GC次数和耗时：1万多次，500多秒

1、大致算下来每天会发生70多次Full GC，平均每小时3次，每次Full GC在400毫秒左右；

2、每天会发生1000多次Young GC，每分钟会发生1次，每次Young GC在50毫秒左右。

-Xms1536M -Xmx1536M -Xmn512M -Xss256K -XX:SurvivorRatio=6  -XX:MetaspaceSize=256M -XX:MaxMetaspaceSize=256M  -XX:+UseParNewGC  -XX:+UseConcMarkSweepGC  -XX:CMSInitiatingOccupancyFraction=75 -XX:+UseCMSInitiatingOccupancyOnly

结合对象挪动到老年代那些规则推理下我们这个程序可能存在的一些问题经过分析感觉可能会由于对象动态年龄判断机制导致full gc较为频繁

模拟程序如下

服务器

@RestController
public class IndexController {

    @RequestMapping("/user/process")
    public String processUserData() throws InterruptedException {
        ArrayList<User> users = queryUsers();

        for (User user: users) {
            //TODO 业务处理
            System.out.println("user:" + user.toString());
        }
        return "end";
    }

    /**
     * 模拟批量查询用户场景
     * @return
     */
    private ArrayList<User> queryUsers() {
        ArrayList<User> users = new ArrayList<>();
        for (int i = 0; i < 5000; i++) {
            users.add(new User(i,"zhuge"));
        }
        return users;
    }
}

客户端

@RunWith(SpringRunner.class)
@SpringBootTest(classes={Application.class})// 指定启动类
public class ApplicationTests {

   @Bean
   public RestTemplate restTemplate() {
      return new RestTemplate();
   }

   @Autowired
   private RestTemplate restTemplate;

   @Test
   public void test() throws Exception {
      for (int i = 0; i < 10000; i++) {
         String result = restTemplate.getForObject("http://localhost:8080/user/process", String.class);
         Thread.sleep(1000);
      }
   }

}

1	`jstat -gc 13456 2000 10000`

对于对象动态年龄判断机制导致的full gc较为频繁可以先试着优化下JVM参数，把年轻代适当调大点：

1
2

-Xms1536M -Xmx1536M -Xmn1024M -Xss256K -XX:SurvivorRatio=6  -XX:MetaspaceSize=256M -XX:MaxMetaspaceSize=256M 
-XX:+UseParNewGC  -XX:+UseConcMarkSweepGC  -XX:CMSInitiatingOccupancyFraction=92 -XX:+UseCMSInitiatingOccupancyOnly

优化完发现没什么变化，full gc的次数比minor gc的次数还多了

我们可以推测下full gc比minor gc还多的原因有哪些？

1、元空间不够导致的多余full gc

2、显示调用System.gc()造成多余的full gc，这种一般线上尽量通过-XX:+DisableExplicitGC参数禁用，如果加上了这个JVM启动参数，那么代码中调用System.gc()没有任何效果

3、老年代空间分配担保机制

4、YoungGC后，老年代空间不足92%

最快速度分析完这些我们推测的原因以及优化后，我们发现young gc和full gc依然很频繁了，而且看到有大量的对象频繁的被挪动到老年代，这种情况我们可以借助jmap命令大概看下是什么对象

查到了有大量User对象产生，这个可能是问题所在，但不确定，还必须找到对应的代码确认，如何去找对应的代码了？

1、代码里全文搜索生成User对象的地方(适合只有少数几处地方的情况)

2、如果生成User对象的地方太多，无法定位具体代码，我们可以同时分析下占用cpu较高的线程，一般有大量对象不断产生，对应的方法代码肯定会被频繁调用，占用的cpu必然较高

可以用上面讲过的jstack或jvisualvm来定位cpu使用较高的代码，最终定位到的代码如下：

/**
 * 模拟批量查询用户场景
 * @return
 */
private ArrayList<User> queryUsers() {
    ArrayList<User> users = new ArrayList<>();
    for (int i = 0; i < 5000; i++) {
        users.add(new User(i,"zhuge"));
    }
    return users;
}

一次查询出500M的对象出来，明显不合适，要根据之前说的各种原则尽量优化到合适的值，尽量消除这种朝生夕死的对象导致的full gc

这是把5000 -> 500后的GC情况，FullGC明显锐减

其他JVM调优工具：

阿里的arthas

火焰图

是什么

火焰图（Flame Graph）是一种用于可视化性能分析的图表，最初由Brendan Gregg开发。它主要用于分析CPU使用情况和函数调用堆栈。火焰图以图形的形式展示了函数调用的层次结构和时间分布，可以帮助开发人员快速定位应用程序中的性能瓶颈和热点。

在火焰图中，每个矩形代表一个函数，矩形的宽度表示该函数在采样中出现的频率或占用的CPU时间，矩形的高度表示函数的调用深度。火焰图的顶部是正在执行的函数，下方都是父函数，类似栈，从底部向上看层数越高，栈越深。通过观察火焰图的形状和颜色，开发人员可以迅速识别出CPU密集型函数和热点函数，从而进行性能优化和调试。

为什么

1、可视化性能瓶颈和热点

2、协助性能优化

3、协助排查问题

4、监控和调试

怎么用

profiler start：开始搜集样本
profiler getSamples：搜集的样本数，时间越长搜集的样本数越多
profiler list：可搜集的event，默认为CPU
profiler status：搜集时间
profiler stop：搜集暂停，默认搜集为.svg图片文件，需要转换下文件格式和输出路径（profiler stop –format html –file /service/app/logs/xxx.html）
profiler resume 恢复采样

打开html文件

颜色意义

绿色：Java代码
黄色：JVM，C++代码
红色：用户态，C代码
橙色：内核态，C代码

图中x-y轴代表

x轴代表函数在采样中出现的频率或占用的CPU时间（按字母顺序排列）
y轴代表方法的调用栈深度

栈宽含义（CPU时间）

宽度可以理解为CPU采样率的占比，越宽代表当前栈在采样数中占比高，其可能为三种含义
该函数运行时间长
该函数被调用次数多

平顶现象（一定要格外注意）

火焰图中的平顶现象是指在火焰图的顶部出现了一个较宽的平顶区域。这表示在采样期间，该函数或代码段被频繁调用，并且占用了大量的 CPU 时间。

平顶现象可能暗示着以下几种情况：

性能瓶颈：该函数可能是系统中的性能瓶颈，消耗了大量的 CPU 资源，导致其他部分的性能受到影响。
频繁执行：函数可能在短时间内被频繁执行，可能是由于循环、递归或其他频繁的调用模式导致的。
耗时操作：该函数可能执行了一些耗时的操作，例如文件 I/O、网络请求、复杂计算等，导致 CPU 时间被长时间占用。

当在火焰图中观察到平顶现象时，可以进一步分析该函数的代码，确定是否存在性能问题，并考虑采取优化措施，如算法优化、缓存使用、异步处理等，以提高系统的整体性能。

24khandsome's Blog

性能调优14-JVM调优工具介绍

JVM调优工具

jmap

1、查看实例信息

2、查看堆信息

3、获取堆内存dump

jstat

1、GC垃圾回收统计

2、堆内存统计

3、新生代垃圾回收统计

4、新生代内存统计

5、老年代垃圾回收统计

6、老年代内存统计

7、元数据空间统计

jstack

1、查看死锁线程栈信息

2、找出占用cpu最高的栈信息

jvisualvm(远程连接（少用）)

jinfo

1、查看jvm的参数

2、查看java系统参数

JVM运行情况预估

如何获取GC重要评判参数

优化思路

举例

系统频繁Full GC导致系统卡顿

模拟程序如下

其他JVM调优工具：

阿里的arthas

火焰图

是什么

为什么

怎么用

颜色意义

图中x-y轴代表

栈宽含义（CPU时间）

平顶现象（一定要格外注意）