jmap -histo 12719
输出文件
jmap -histo 12719 > ./log.txt
jmap -heap 12719
jmap ‐dump:format=b,file=eureka.hprof 14660
我们可以在启动Java程序的时候,设置在内存溢出的情况下自动进行导出dump文件(相当于黑匣子)
可以用jvisualvm命令工具导入该dump文件分析
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");
}
}
jstack 14660
**还可以用jvisualvm自动检测死锁 **
在启动java程序时候记得开启JMX的端口号配置:
java ‐Dcom.sun.management.jmxremote.port=8888
远程jmx的端口号
‐Djava.rmi.server.hostname=192.168.50.60
远程机器的IP,也就是Linux服务机器的IP‐Dcom.sun.management.jmxremot e.ssl=false
‐Dcom.sun.management.jmxremote.authenticate=false
‐jar microservice‐eureka‐server.jar
然后利用工具连接:
package com.tuling.jvm;
/**
* 运行此代码,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();
}
}
}
1)第一步定位CPU飙升的进程
top -p 19663
键盘 按 H, 获取每个线程的内存情况
2)找到内存和CPU占用最高的线程PID,比如19664(线程号)
3) 转为十六进制得到 0x4cd0,此为线程id的十六进制表示
4) 执行 jstack 19663 (进程号)| grep -A 10 4cd0,得到线程堆栈信息中 4cd0 这个线程所在行的后面10行,从堆栈中可以发现导致cpu飙高的调 用方法
7) jinfo 查看正在运行的Java应用程序的扩展参数
jinfo -flags 14124
查看JVM参数
jinfo -sysprops 14124
查看java系统参数
1)垃圾回收统计
jstat -gc 13213
jstat -gccapacity 13213
jstat -gcnew 13213
jstat -gcnewcapactity 13213
**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 计算得出。
优化思路其实简单来说就是尽量让每次Young GC后的存活对象小于Survivor区域的50%,都留存在年轻代里。尽量别让对象进入老年 代。尽量减少Full GC的频率,避免频繁Full GC对JVM性能的影响。
系统频繁Full GC导致系统卡顿是怎么回事
‐Xms1536M ‐Xmx1536M ‐Xmn512M ‐Xss256K ‐XX:SurvivorRatio=6 ‐XX:MetaspaceSize=256M ‐XX:MaxMetaspaceSize=256M 2 ‐XX:+UseParNewGC ‐XX:+UseConcMarkSweepGC ‐XX:CMSInitiatingOccupancyFraction=75 ‐XX:+UseCMSInitiatingOccupancyOnly
大家可以结合对象挪动到老年代那些规则推理下我们这个程序可能存在的一些问题 经过分析感觉可能会由于对象动态年龄判断机制导致full gc较为频繁
对于对象动态年龄判断机制导致的full gc较为频繁可以先试着优化下JVM参数,把年轻代适当调大点:
‐Xms1536M ‐Xmx1536M ‐Xmn1024M ‐Xss256K ‐XX:SurvivorRatio=6 ‐XX:MetaspaceSize=256M ‐XX:MaxMetaspaceSize=256M 2 ‐XX:+UseParNewGC ‐XX:+UseConcMarkSweepGC ‐XX:CMSInitiatingOccupancyFraction=92 ‐XX:+UseCMSInitiatingOccupancyOnly
**优化完发现没什么变化,full gc的次数比minor gc的次数还多了 **
1、元空间不够导致的多余full gc
2、显示调用System.gc()造成多余的full gc,这种一般线上尽量通过XX:+DisableExplicitGC参数禁用,如果加上了这个JVM启动参数,那 么代码中调用System.gc()没有任何效果
3、老年代空间分配担保机制 最快速度分析完这些我们推测的原因以及优化后,我们发现young gc和full gc依然很频繁了,而且看到有大量的对象频繁的被挪动到老年 代,这种情况我们可以借助jmap命令大概看下是什么对象
查到了有大量User对象产生,这个可能是问题所在,但不确定,还必须找到对应的代码确认,如何去找对应的代码了?
1、代码里全文搜索生成User对象的地方(适合只有少数几处地方的情况)
2、如果生成User对象的地方太多,无法定位具体代码,我们可以同时分析下占用cpu较高的线程,一般有大量对象不断产生,对应的方法 代码肯定会被频繁调用,占用的cpu必然较高 可以用上面讲过的jstack或jvisualvm来定位cpu使用较高的代码,最终定位到的代码如下:
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,"zhuge"));
}
return users;
}
}
同时,java的代码也是需要优化的,一次查询出500M的对象出来,明显不合适,要根据之前说的各种原则尽量优化到合适的值,尽量消 除这种朝生夕死的对象导致的full g
本文由mdnice多平台发布