JVM调优工具详情

最新推荐文章于 2022-04-06 08:20:15 发布

Robin_812656252

最新推荐文章于 2022-04-06 08:20:15 发布

阅读量503

点赞数

文章标签： java

本文链接：https://blog.youkuaiyun.com/Robin_812656252/article/details/121267660

版权

本文介绍了Java性能监控工具jmap、jstack、jinfo、jstat等的使用，以及如何通过它们分析内存状况、查找死锁、评估JVM性能。同时，讨论了内存泄露的原因和预防策略，强调了合理管理JVM内存的重要性。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

jmap

用来查看内存信息、实例个数以及占用的内存大小。

jmap -histo <process_id>

num：序号

instances：实例数量

bytes：占用空间大小

class name：类名称，C = char[], S = short[], I = int[]

jmap -heap <process_id>

查看堆信息

jmap -dump:format=b,file=<filename> <process_id>

dump堆内存，可以在启动时添加参数，当出现OOM时保存堆内存快照：

1. -XX:+HeapDumpOnOutOfMemoryError

2. -XX:HeapDumpPath=./

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

jstack

用jstack加进程id查找死锁。

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) {
                    e.printStackTrace();
                }

                synchronized (lock2) {
                    System.out.println("Thread1 end");
                }
            }
        }).start();

        new Thread(() -> {
            synchronized (lock2) {
                try {
                    System.out.println("Thread2 begin.");
                    Thread.sleep(5000);
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }

                synchronized (lock1) {
                    System.out.println("Thread2 end.");
                }
            }
        }).start();
        System.out.println("Main Thread end.");
    }
}

判断死锁

远程连接jvisualvm

java ‐Dcom.sun.management.jmxremote.port=8888 ‐Djava.rmi.server.hostname=192.168.50.60 ‐Dcom.sun.management.jmxremot e.ssl=false ‐Dcom.sun.management.jmxremote.authenticate=false ‐jar microservice‐eureka‐server.jar

PS： -Dcom.sun.management.jmxremote.port 为远程机器的JMX端口 - Djava.rmi.server.hostname 为远程机器IP

Tomcat的JMX配置

在catalina.sh文件里的最后一个JAVA_OPTS的赋值语句下一行增加如下配置行

JAVA_OPTS="$JAVA_OPTS ‐Dcom.sun.management.jmxremote.port=8888 ‐Djava.rmi.server.hostname=192.168.50.60 ‐Dcom.sun.ma nagement.jmxremote.ssl=false ‐Dcom.sun.management.jmxremote.authenticate=false"

jinfo

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

jinfo -flags <process_id>

查看JVM参数

jinfo -sysprops <process_id>

查看Java系统参数

jstat

jstat可以查看堆内存各部分的使用量，以及加载类的数量。

jstat [-命令选项] [vmid] [间隔时间（毫秒）][查询次数]

jstat -gc <process_id>

可以评估程序内存使用及GC压力情况。

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

jstat -gccapacity <process_id>

堆内存统计

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

jstat -gcnew <process_id>

新生代垃圾回收统计

jstat -gcnewcapacity <process_id>

新生代内存统计

老年代（old）、元空间（meta）

JVM运行情况预估

年轻代对象增长的速率

jstat -gc <pid> 1000 10(每隔1秒执行1次命令，共执行10次）观察Eden区大小来估算每秒新增多少新对象，也可以换成1分钟、10分钟。

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

根据上一步，用YGCT/YGC可以算出平均耗时。

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

知道Young GC频率后，执行jstat -gc <pid> <duration> 10，观察每次结果Eden， Surivor和老年代使用的变化情况，Survivor和老年代增长的对象就是每次Young GC后存活的对象，据此推算出老年代对象的增长速率。

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

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

尽量让每次Young GC后存活的对象小于Survivor区域的50%，逗留存在年轻代里，让对象烧进入老年代，减少Full GC的频率，避免频繁Full GC。

内存泄露到底是怎么回事

再给大家讲一种情况，一般电商架构可能会使用多级缓存架构，就是redis加上JVM级缓存，大多数同学可能为了图方便对于JVM级缓存就简单使用一个hashmap，于是不断往里面放缓存数据，但是很少考虑这个map的容量问题，结果这个缓存map越来越大，一直占用着老年代的很多空间，时间长了就会导致full gc非常频繁，这就是一种内存泄漏，对于一些老旧数据没有及时清理导致一直占用着宝贵的内存资源，时间长了除了导致full gc，还有可能导致OOM。这种情况完全可以考虑采用一些成熟的JVM级缓存框架来解决，比如ehcache等自带一些LRU数据淘汰算法的框架来作为JVM级的缓存。