07.JVM调优工具详解及调优实战

已于 2024-06-20 16:21:17 修改
阅读量186 收藏
点赞数
分类专栏： 图灵学习 # 一：性能调优专题 文章标签： jvm java 开发语言
于 2022-12-03 22:38:17 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/weixin_43761434/article/details/128163019
版权

文章目录

前置启动程序

在这里插入图片描述

启动web应用程序

java -jar microservice-eureka-server.jar

在这里插入图片描述

  • 启动一个web应用程序，用jps查看其进程id，接着用各种jdk自带命令优化应用

一：Jmap

1：通过jps命令找到刚刚启动的jar包的进程id

在这里插入图片描述

2：通过jmap命令可以查看次进程的实例个数以及占用内存的大小

jmap -histo 20252

在这里插入图片描述

  • 为了方便查看 我们还可以输出未txt未见 制定输出文件地址

3：f:(进入f盘目录)

jmap -histo 20252 > ./log.txt


在这里插入图片描述

4：log文件如下

在这里插入图片描述

  • 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[][]

5：jmap -heap 进程id查看堆信息

jmap -heap 20252

在这里插入图片描述

6：通过jmap ‐dump指令生成堆dump(快照信息)输出到目录

jmap ‐dump:format=b,file=eureka.hprof 16944
  • 生成的文件可以放到（可视化工具中）jvisualvm工具中去打开查看文件中的详细信息
  • 和jmap打印出来的东西差不多

在这里插入图片描述
在这里插入图片描述

二：假如当前内存溢出了，我们怎么人去快速排查出是哪里的代码出了问题

1：设置内存溢出自动导出dump文件(内存很大的时候，可能会导不出来)

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

2：代码示例

package com.zgs;

import java.util.ArrayList;
import java.util.List;
import java.util.UUID;

/**
 * @author: guisong.zhang
 * @date: 2024/6/4 15:53:35
 * @description 内存溢出生成dump文件
 **/
public class OOMTest {
    public static List<Object> list = new ArrayList<>();

    // JVM设置
    // -Xms5M -Xmx5M -XX:+PrintGCDetails -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=D:\study\资料\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());
        }
    }
}

3：启动配置

在这里插入图片描述

4：将生成的dump文件导入导入jvisualvm工具即可查看

在这里插入图片描述

三：Jstack

  • 用于生成当前JVM的所有线程快照，可以查看堆栈信息，线程快照是虚拟机每一条线程正在执行的方法,目的是定位线程出现长时间停顿的原因。

比如出现了死锁，如何快速定位是哪里出了问题

1：死锁代码如下

package com.zgs;


/**
 * @author: guisong.zhang
 * @date: 2024/6/19 15:26:41
 * @description 死锁测试
 **/
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) {
                System.out.println("thread1 获取lock1");
                try {
                    Thread.sleep(5000);
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
                synchronized (lock2) {
                    System.out.println("thread1 获取lock2");
                }
            }
        }, "thread1").start();

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

        System.out.println("main线程执行完毕");
    }
}

2：使用jstack 命令，结果如下

jstack 16612

在这里插入图片描述

  • 能直观的看到死锁发生在哪里。

3：也可以使用jvisualvm也可以直接检测到死锁

在这里插入图片描述

4：dump文件如下

在这里插入图片描述

四：远程连接jvisualvm

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

java -Dcom.sun.management.jmxremote.port=8888 -Djava.rmi.server.hostname=192.168.65.60 -Dcom.sun.management.jmxremote.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

2：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.management.jmxremote.ssl=false ‐Dcom.sun.management.jmxremote.authenticate=false"

3：连接时确认下端口是否通畅，可以临时关闭下防火墙

  • systemctl stop firewalld #临时关闭防火墙

五：线上出现cpu占用过高，如何排查

1：jstack找出占用cpu最高的线程堆栈信息

package com.zgs;


/**
 * @author: guisong.zhang
 * @date: 2024/5/22 11:25:14
 * @description 测试CPU占用内存过高
 **/
public class Math {
    public static final int initData = 666;
    public static User user = new User();

    public int compute() {  //一个方法对应一块栈帧内存区域
        int a = 1;
        int b = 2;
        int c = (a + b) * 10;
        return c;
    }

    public static void main(String[] args) {
        Math math = new Math();
        while (true){
            math.compute();
        }
    }
}
  • 使用top命令查询到cpu占用高的进程id pid
  • 然后使用命令top -p pid ，显示此java进程的内存情况，pid是你的java进程号，比如19663

在这里插入图片描述

  • 按H，获取此进程中每个线程的内存情况

在这里插入图片描述

  • 找到内存和cpu占用最高的线程tid，比如19664
  • 转为十六进制得到 0x4cd0，此为线程id的十六进制表示
  • 执行 jstack 19663|grep -A 10 4cd0，得到线程堆栈信息中 4cd0
  • 这个线程所在行的后面10行，从堆栈中可以发现导致cpu飙高的调用方法

在这里插入图片描述

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

六：jinfo

1：查看jvm启动参数

jinfo -flags 3312

在这里插入图片描述

2：可以查看系统的java属性

jinfo -sysprops 3312

在这里插入图片描述

七：jstat-----重要

  • jstat命令可以查看堆内存各部分的使用量，以及加载类的数量。命令的格式如下：
  • jstat [-命令选项] [vmid] [间隔时间(毫秒)] [查询次数]

1：垃圾回收统计

jstat - gc 3312

在这里插入图片描述

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

2：堆内存统计

 jstat -gccapacity 3312

在这里插入图片描述

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

3：新生代垃圾回收统计

stat -gcnew 3312

在这里插入图片描述

  • S0C：第一个幸存区的大小
  • S1C：第二个幸存区的大小
  • S0U：第一个幸存区的使用大小
  • S1U：第二个幸存区的使用大小
  • TT:对象在新生代存活的次数
  • MTT:对象在新生代存活的最大次数
  • DSS:期望的幸存区大小
  • EC：伊甸园区的大小
  • EU：伊甸园区的使用大小
  • YGC：年轻代垃圾回收次数
  • YGCT：年轻代垃圾回收消耗时间

4：新生代内存统计

jstat -gcnewcapacity 3312

在这里插入图片描述

  • NGCMN：新生代最小容量
  • NGCMX：新生代最大容量
  • NGC：当前新生代容量
  • S0CMX：最大幸存1区大小
  • S0C：当前幸存1区大小
  • S1CMX：最大幸存2区大小
  • S1C：当前幸存2区大小
  • ECMX：最大伊甸园区大小
  • EC：当前伊甸园区大小
  • YGC：年轻代垃圾回收次数
  • FGC：老年代回收次数

5：老年代垃圾回收统计

jstat -gcold 3312

在这里插入图片描述

  • MC：方法区大小
  • MU：方法区使用大小
  • CCSC:压缩类空间大小
  • CCSU:压缩类空间使用大小
  • OC：老年代大小
  • OU：老年代使用大小
  • YGC：年轻代垃圾回收次数
  • FGC：老年代垃圾回收次数
  • FGCT：老年代垃圾回收消耗时间
  • GCT：垃圾回收消耗总时间

6：老年代内存统计

jstat -gcoldcapacity 3312

在这里插入图片描述

  • OGCMN：老年代最小容量
  • OGCMX：老年代最大容量
  • OGC：当前老年代大小
  • OC：老年代大小
  • YGC：年轻代垃圾回收次数
  • FGC：老年代垃圾回收次数
  • FGCT：老年代垃圾回收消耗时间
  • GCT：垃圾回收消耗总时间

7：元数据空间统计

 jstat -gcmetacapacity 3312

在这里插入图片描述

  • MCMN:最小元数据容量
  • MCMX：最大元数据容量
  • MC：当前元数据空间大小
  • CCSMN：最小压缩类空间大小
  • CCSMX：最大压缩类空间大小
  • CCSC：当前压缩类空间大小
  • YGC：年轻代垃圾回收次数
  • FGC：老年代垃圾回收次数
  • FGCT：老年代垃圾回收消耗时间
  • GCT：垃圾回收消耗总时间

8：查看堆中各个区域已使用空间占其总空间的百分比

 jstat -gcutil  3312

在这里插入图片描述

  • S0：幸存1区当前使用比例
  • S1：幸存2区当前使用比例
  • E：伊甸园区使用比例
  • O：老年代使用比例
  • M：元数据区使用比例
  • CCS：压缩使用比例
  • YGC：年轻代垃圾回收次数
  • FGC：老年代垃圾回收次数
  • FGCT：老年代垃圾回收消耗时间
  • GCT：垃圾回收消耗总时间

9:动态查看垃圾回收状态

jstat -gc 3312 1000 10
  • 每秒执行一次，执行十次。便于我们动态的查看jvm内存使用情况，排查问题。
    在这里插入图片描述

八：jvm调优实例

1：JVM运行情况预估

  • 用 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 计算得出。

优化思路

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

2：系统频繁Full GC导致系统卡顿是怎么回事

演示代码示例git地址

  • 机器配置：2核4G
  • JVM内存大小：2G
  • 系统运行时间：7天
  • 期间发生的Full GC次数和耗时：500多次，200多秒
  • 期间发生的Young GC次数和耗时：1万多次，500多秒
  • 大致算下来每天会发生70多次Full GC，平均每小时3次，每次Full GC在400毫秒左右； 每天会发生1000多次YoungGC，每分钟会发生1次，每次Young GC在50毫秒左右。

最开始JVM参数设置如下：

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

在这里插入图片描述

  • 大家可以结合对象挪动到老年代那些规则推理下我们这个程序可能存在的一些问题；经过分析感觉可能会由于对象动态年龄判断机制导致fullgc较为频繁
  • 模拟了一个示例程序(见课程对应工程代码：jvm-full-gc)，打印了jstat的结果如下：
jstat -gc 14196 2000 10000

在这里插入图片描述

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

  • 第一次优化JVM参数设置如下：

-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还多的原因有哪些？

  • 元空间不够导致的多余full gc。
  • 显示调用System.gc()造成多余的fullgc，这种一般线上尽量通过­XX:+DisableExplicitGC参数禁用，如果加上了这个JVM启动参数，那么代码中调用System.gc()没有任何效果 。
  • 老年代空间分配担保机制。
  • 最快速度分析完这些我们推测的原因以及优化后，我们发现young gc和fullgc依然很频繁了，而且看到有大量的对象频繁的被挪动到老年代。

借助jmap命令大概看下是什么对象。

jmap -histo 25012
  • 可以发现里面生成了大量的user对象
    在这里插入图片描述
  • 这个可能是问题所在，但不确定，还必须找到对应的代码确认，如何去找对应的代码了？
  • 1、代码里全文搜索生成User对象的地方(适合只有少数几处地方的情况)
  • 2、如果生成User对象的地方太多，无法定位具体代码，我们可以同时分析下占用cpu较高的线程，一般有大量对象不断产生，对应的方法代码肯定会被频繁调用，占用的cpu必然较高

用jstack或jvisualvm来定位cpu使用较高的代码。

 jvisualvm

在这里插入图片描述
在这里插入图片描述

  • 图二就可以定位到具体的代码

定位代码结果如下

package jvm;

import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RestController;

import java.util.ArrayList;

@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,"zgs"));
        }
        return users;
    }
}
  • 同时，java的代码也是需要优化的，一次查询出500M的对象出来，明显不合适，要根据之前说的各种原则尽量优化到合适的值，尽量消除这种朝生夕死的对象导致的fullgc，
  • 我们将处理的一次条数设置为100看看效果

在这里插入图片描述

  • 通过jstat -gc 26928 2000 10000查看，可以发现很少fullgc了
jstat -gc 26928 2000 10000

在这里插入图片描述

九：内存泄露到底是怎么回事

  • 再给大家讲一种情况，一般电商架构可能会使用多级缓存架构，就是redis加上JVM级缓存，大多数同学可能为了图方便对于JVM级缓存就简单使用一个hashmap，
  • 于是不断往里面放缓存数据，但是很少考虑这个map的容量问题，结果这个缓存map越来越大，一直占用着老年代的很多空间，时间长了就会导致full gc非常频繁，这就是一种内存泄漏，
  • 对于一些老旧数据没有及时清理导致一直占用着宝贵的内存资源，时间长了除了导致full gc，还有可能导致OOM。
  • 这种情况完全可以考虑采用一些成熟的JVM级缓存框架来解决，比如ehcache等自带一些LRU数据淘汰算法的框架来作为JVM级的缓存。
一路向北·重庆分伦
关注
  • 0
    点赞
  • 踩
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
专栏目录
JVM内存模型和性能调优：JVM调优工具详解及调优实战：jstat – 第38篇
01-09
在众多的JVM调优工具中，`jstat`（Java Virtual Machine Statistics Monitoring Tool）是一个非常实用的命令行工具，尤其适用于实时监控和分析JVM的状态。 一、`jstat` 命令详解 `jstat`命令允许开发者查看JVM的...
JVM调优工具详解及调优实战
最新发布
qq_27740127的博客
07-12 375
增加如下配置行JAVA_OPTS。
JVM-调优工具详解及调优实战
小胡子
03-23 457
JVM-调优工具详解及调优实战
jvm调优工具详解及调优实战
qq_14946371的博客
03-21 421
还不会jvm调优？快进来看看吧。详解如何利用调优工具进行调优，线上内存溢出，cpu飙高，系统卡顿如何解决？
jstack 命令查看JAVA线程堆栈
青山师
08-06 2万+
JAVA堆栈信息实际生产中，可能由于开发以及测试未能全面覆盖的代码质量、性能问题，而引致线程挂起甚至崩溃。可能就需要查看堆栈信息来排查问题了。jps -lvmjps -lvm 用于查看当前机器上运行的java进程。C:\Users\Administrator&gt;jps -lvm 7348 -Dosgi.requiredJavaVersion=1.8 -Dosgi.instance.area.defa
JVM调优-JVM调优实践一
Trouvailless的博客
08-08 761
前面已经分享了很多关于jvm的知识，具体的详情都可以查看上几篇的文章。从jvm的调优原理，垃圾查找算法，垃圾回收算法，再到jvm调优工具，调优参数等。需要掌握的jvm知识，已经是循序渐进，一步一步的深入学习。那在掌握这些内容的时候，是不是有种想去实践的冲动呢？好了，今天我们就来进行一次jvm调优实践之旅吧！！！JVM实践调优主要步骤分析GC日志堆内存与元空间优化线程堆栈优化堆内存内部优化：新生代和老年代比例垃圾回收器优化。...
JVM调优攻略.pdf
07-27
JVM调优攻略.pdf！
JVM调优篇.pdf
09-12
JVM类加载机制详解 JVM类加载机制是Java虚拟机中的一种机制，它负责加载Java类文件到内存中，以便执行Java程序。类加载机制分为五个阶段：加载、验证、准备、解析和初始化。 加载 加载是类加载过程中的一个阶段，...
06-VIP-JVM调优实战及常量池详解(1)1
08-03
Java虚拟机（JVM）调优是提升Java应用程序性能的关键环节。在JVM中，字符串对象的创建尤其值得关注，因为它们频繁出现且消耗大量的时间和内存。JVM为优化性能和节省内存，对字符串实例化采取了一种特殊策略，即字符...
jvm调优.zip & hotspot源码解读
01-17
5. JVM调优工具详解： 工具如JVisualVM、JConsole、JProfiler等提供了丰富的监控和分析功能，帮助我们了解JVM运行状态，定位性能瓶颈。通过调整JVM参数，如-Xms、-Xmx设置堆大小，-XX:NewRatio调整新生代和老年代...
JVM优化案例实战-手动模拟Young GC
AS011x的博客
09-19 247
看我们之前的代码，Eden区总的4MB空间，之前已经有3个垃圾对象，最后需要分配2MB的空间，就会发生内存不够，因此分配失败，此时就会触发一次Young GC，ParNew表示使用的是年轻代的ParNew 垃圾回收器来进行垃圾回收，后面的3596K->420K表示，回收之前的新生代大小为3.5MB，回收之后为420K约等于0.5MB，相当于本次回收大概回收了3MB的垃圾对象。执行代码后，会在目录下生成gc.log日志文件，我们可以根据这个文件查看GC回收的具体细节，这是我们做JVM调优的基础。
JAVA系列之JVM内存调优
sloveb123的博客
10-27 3775
如果将此值设置为一个较大值，则年轻代对象会在Survivor区进行多次复制，这样可以增加对象再年轻代的存活时间，增加在年轻代即被回收的概率。堆内存是由年轻代和老年代构成，JDK1.8以后，永久代被元空间取代，使用直接内存，不占用堆内存。**-XX:+UseAdaptiveSizePolicy：**设置此选项后，并行收集器会自动选择年轻代区大小和相应的Survivor区比例，以达到目标系统规定的最低相应时间或者收集频率等，此值建议使用并行收集器时，一直打开。**-Xss128k：**设置每个线程的堆栈大小。
jvm如何调优
weixin_57763462的博客
05-11 739
一、JVM内存模型及垃圾收集算法 1.根据Java虚拟机规范，JVM将内存划分为： New（年轻代） Tenured（年老代） 永久代（Perm） 其中New和Tenured属于堆内存，堆内存会从JVM启动参数（-Xmx:3G）指定的内存中分配，Perm不属于堆内存，有虚拟机直接分配，但可以通过-XX:PermSize -XX:MaxPermSize 等参数调整其大小。 年轻代（New）：年轻代用来存放JVM刚分配的Java对象 年老代（Tenured...
jvm最全详解-05-JVM调优工具详解及调优实战
wangzhipeng47的博客
07-29 596
jvm最全详解-05-JVM调优工具详解及调优实战 前置启动程序 事先启动一个web应用程序，用jps查看其进程id，接着用各种jdk自带命令优化应用 Jmap 此命令可以用来查看内存信息，实例个数以及占用内存大小 jmap -histo 14660 #查看历史生成的实例 jmap -histo:live 14660 #查看当前存活的实例，执行过程中可能会触发一次full gc 打开log.txt，文件内容如下： num：序号 instances：实例数量 b..
6、JVM调优工具详解及调优实战
u011107814的专栏
07-02 201
前置启动程序 事先启动一个web应用程序，用jps查看其进程id，接着用各种jdk自带命令优化应用 Jmap 此命令可以用来查看内存信息，实例个数以及占用内存大小 jmap -histo 14660 #查看历史生成的实例 jmap -histo:live 14660 #查看当前存活的实例，执行过程中可能会触发一次full gc 打开log.txt，文件内容如下： num：序号 instances：实例数量 bytes：占用空间大小 class name：类名称，[C ..
JVM调优工具详解
qq_49281137的博客
11-19 3254
学习了JVM的一些调优工具为大家分享一下，现在把学习笔记总结记录一下，如果记录有些错误，还望指出。 文章目录前言jdk自带工具一、Jmap1.1 jps1.2 jmap -histo1.3 jmap -heap1.4 jmap -dump二、Jstack三、Jinfo四、Jstat垃圾回收统计JVM运行情况预估年轻代对象增长的速率Young GC的触发频率和每次耗时每次Young GC后有多少对象存活和进入老年代Full GC的触发频率和每次耗时内存泄露到底是怎么回事五、ArthasArthas使用git
JVM内存模型和性能调优：JVM调优工具详解及调优实战：Jmap - 第36篇
热门推荐
悟纤学院
04-28 2万+
此命令可以用来查看内存信息。 一、实例个数以及占用内存大小 命令：jmap -histo 91289 > /data/tmp/log.txt 其中91289是进程ID，使用jps进行查看。 打开log.txt，文件内容如下（HeapTest）： num：序号 instances：实例数量 bytes：占用空间大小 class name：类名称，[C is a ch...
JVM内存模型和性能调优：JVM调优工具详解及调优实战：jstat调优小实战- 第40篇
悟纤学院
05-07 2万+
一、准备工作 准备一个工程jvm-full-gc，核心代码： @RestController public class IndexController { @RequestMapping("/user/process") public String processUserData() throws InterruptedException { ...
七 JVM调优工具详解及调优实战
东风麦芽糖
09-12 535
JVM内存溢出自动导出dump 内存泄露到底是怎么回事 系统频繁Full GC导致系统卡顿 jstat命令 Jinfo命令 Jstack命令 远程连接jvisualvm 如何禁用System.gc() 如何阻止内存泄露
JVM调优与内存管理详解：从基础到实战
这部分包括对JVM调优的一些基本概念，如不同阶段的垃圾回收算法（如基本垃圾回收算法和新一代垃圾回收算法），以及遇到的问题和解决方案。作者还列举了典型配置实例，以便读者了解如何根据具体应用调整JVM参数。此外...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值